Cloud-Native Application Security Challenges
Application security has historically taken a back seat to application delivery. Traditional IT security teams view themselves as gatekeepers; they must do their jobs correctly or their organizations face increased risk. They incorporate high security standards into every operation, but achieving these standards takes time, testing and iterations. Development teams fret because this slows application development and often does not ensure comprehensive protection.
When businesses look to optimize and accelerate application development life cycles and deliver their applications in public clouds (typically referred to as cloud-native applications), security becomes a greater challenge. Cloud-native apps usually run in new architectures that provide unprecedented efficiency, flexibility and cost-effectiveness.
Development and operations (DevOps) groups emerged to take an active role in application delivery by selecting the tools and budget to set the development and deployment pace. Automation platforms, powerful orchestration frameworks, open-source tool sets and visibility solutions all play a major role in these environments.
Development, security and operations (DevSecOps) represent the security component of DevOps and seek to fit security due diligence into processes that drive speed, agility and continuous delivery. However, DevSecOps may find it challenging to deliver security to continuous delivery processes if they lack automation, orchestration tools and visibility and have inferior application protection.
[You may also like: Anatomy of a Cloud-Native Data Breach]
Containers, Microservices and Service Meshes
Transitioning from a monolithic architecture to a microservice architecture allows applications to be deployed more frequently. Different microservices can be independently delivered in a more reliable manner. In parallel, container technology emerged, which is a perfect match to microservices. Each microservice is deployed across multiple containers to allow for quick rollout and scalability, improving quality and reducing time to market.
A service mesh is a layer that handles the interservice communication in a microservice architecture. Its purpose is to reduce the complexity associated with a microservice architecture by providing scalability through load balancing, telemetry, traffic routing, health checks, etc.
One of the challenges with the transition to a microservice architecture has to do with the scale of objects provisioned. In the monolithic era, few monolith web instances were load balanced. Today, there are thousands of containers which need to be automatically spawned.
Cloud-Native Application Security Challenges
With all the power that microservice architectures and service mesh infrastructures provide, they do not address application and data security challenges. In addition to the already known application security challenges, which are as relevant now as in the past, the distributed nature of microservice apps introduces latencies, topology changes and challenges with managing many microservices.
The Good Old OWASP Top 10 for Web Applications: The Open Web Application Security Project (OWASP) provides security professionals with an overview of the most critical web application security risks. Injections, broken authentication, cross-site scripting (XSS) and sensitive data exposure are just a few examples of risks that are as relevant for cloud-native apps as they are for monolithic applications.
[You may also like: WAFs Should Do A Lot More Against Current Threats Than Covering OWASP Top 10]
The API Role in Modern Applications: Modern apps make intensive use of APIs across different use cases: internet of things (IoT) applications, machine-to-machine communication, event-driven web applications, automated actions in web frameworks, function-as-a-service (FaaS) apps, mobile apps, etc. All of these use cases refer to north-south communication, which is client-to-app traffic. Most of the APIs serving these use cases are REST APIs with JSON bodies (REST-JSON). A smaller portion of the APIs are simple object access protocol (SOAP) based with XML structured data formats.
As these APIs are running on top of the HTTP protocol, most of the web app security risks are as relevant for APIs as they are for web apps. Additionally, APIs introduce additional security challenges, mostly around authorization and access control, as the APIs may be served independently.
[You may also like: 10 Commandments for Securing Microservices]
The New OWASP Top 10 for APIs: With the growing adoption of APIs, the OWASP organization has produced the API Security Project under which it has published the OWASP API Security Top 10 Release Candidate. Examples of the API security risks referred
to in the project include broken object level authorization, excessive data exposure, lack of resources and rate limiting, and injection, all of which may lead to data theft or service disruption.
