How fast is fast enough? When it comes to creating and maintaining great customer experiences, organizations don’t have time to wait for traditional security reviews before rolling out or enhancing applications. The first priority is that applications meet customer needs. Application security is critical, but for businesses to maintain competitive advantages, it can’t stand in the way of progress.
The cycle of planned update release schedules is outmoded and impractical. Instead, businesses have embraced agile workflows to be able to fix bugs, incorporate feedback from customers and implement new features on a daily or even hourly basis.
Enterprises are also making fundamental changes in their choice of environments where applications are developed and hosted. They are moving away from monolithic applications housed on-premise to microservice architectures hosted in public clouds. This shift is in response to the need for ecosystems that are flexible and scalable enough to support rapidly changing business requirements. How can security practices keep up?
The Conflicting Concepts of Security and Agility
When speed of delivery is the aim of continuous application deployment models, the demands of traditional security processes can be roadblocks. IT security teams see themselves as gatekeepers, implementing rigorous processes to reduce the risk of application attacks. Mistakes are not good for job security, but the investment in requirements refining, prototype testing, traffic inspection and policy reviews takes precious time.
Application DevOps teams have emerged as the designers and overseers of the agile network ecosystems that enable the automated continuous delivery processes. But these teams have different priorities that conflict with conventional, deliberative security practices. Their charge is to quickly deliver applications that support business needs. Building in time for exhaustive security reviews just isn’t possible. As a result, traditional IT teams may find themselves uninvited from the process.
Distributed Architectures Introduce New Security Challenges
To accelerate development and better utilize resources and budgets, DevOps teams are breaking computing infrastructures down into containers and applications down to microservices running in these containers. This approach provides the flexibility, scalability and efficiencies that they seek by employing a variety of off-the-shelf tools for automation, independent development processes of each microservice, etc.
In the microservice architecture, the operational communication between the different tools used in the application development and delivery environment is done via APIs. This interface is a predefined request–response message system that exposes reliable content and operation negotiation.
API vulnerabilities are hard to detect and do not stand out. Traditional application security assessment tools do not work well with APIs or are simply irrelevant in this case. When planning for API security infrastructure, authentication and authorization must be taken into account, yet these are often not addressed properly.
Microservice architectures meet organizations’ need for speed, but the tradeoff is the introduction of new security challenges.
Gaining Visibility Moving Forward
1. Adopt a risk management mindset that prioritizes business drivers to shape security mitigation policies. A “security at all costs” approach is likely to generate an unacceptable level of false positives and erroneously impact customers’ experiences with the applications. Security should follow the same development timeline as product development.
2. Establish clarity about roles for application security. Clear accountability empowers the right teams to take responsibility for decisions about the acceptable level of risk and strategies to protect applications.
3. Focus on implementing a security solution that provides one consistent point of visibility across all network environments, both public and private. Reliance on solutions offered by public cloud vendors leaves blind spots in the security posture, which attackers can exploit.
4. Select a security solution that fits the ecosystem already in place without requiring adjustments, such as changing how traffic is routed, the submission of SSL certificates or the alteration of IP addresses.
5. Take advantage of the open-source nature of cloud-native applications to aggregate telemetry information about traffic volumes, consumption of applications, performance issues, geographic distribution of users and the nature of data being processed. Use the information to analyze behavior to get better visibility about what is happening across all platforms.
6. Secure the channels through which the applications are being delivered. That means protecting APIs and web and mobile services from attack vectors such as protocol manipulation, data manipulation in servers, and session and credential attacks.
7. Deliver a security posture that is scalable and elastic to adapt to changing business needs. Automate the monitoring and mitigation of attacks everywhere in the ecosystem to support the continuous deployment process for applications.