Changing threat landscape and security measures for cloud native applications

Overview:

This Article is intended for DevOps, Solution architects, and CISOs to help them create threat modelling for evolving application architecture in Cloud. This article provides overview on changing threat vector with mitigation guidelines in various cloud adoption stages.

Changing threat vector in evolving cloud applications:

Customers who has started the journey to cloud has migrated majority of monolithic application in multi–tier application in IaaS or mixed PaaS and IaaS environment. Security is a shared responsibility in cloud and the responsibility changes according to the type of cloud services you utilize for your application.

    

Cloud adoption and application evolution stages:

In Initial cloud adoption phase, application utilizes high amount of IaaS and PaaS services. While manageability for operations team reduces for application PaaS (AWS Beanstalk, Azure App service etc.), Security team sees such type of application’s threat vector similar to IaaS instances and/or on-premises application.

Stage-1: Threat Vector in monolithic application (IaaS)

Application Code in cloud isn’t just written by You. As with all modern web applications, developers use third party, mostly open source, components typically including web frameworks and libraries. These third party components have security vulnerabilities of their own (e.g. Java struts apache common vulnerability that allow attacker to execute code remotely over port 80/443).

Stage-1 threat mitigation measures for monolithic application in cloud

·         Continues vulnerability scanning and patch management on each layers of compute services OS (e.g. EC2, Azure VM, or GCP compute engine) with Intrusion prevention

·         Malicious payload detection with Anti-malware, Machine learning, behavioural analytics, and application control.

·         File system integrity monitoring on Compute service (e.g. EC2, GCP compute engine, Azure VM etc.) OS file system.

·         Whitelist authorized applications in compute instance to block any unauthorized application/script execution.

·         L3 and L4 level security hardening on Cloud security groups (e.g. Azure NSG, AWS SG etc.)

·         L7 application protection with WAF service along with managed WAF rules (e.g. AWS WAF) and Run-time application self-protection (RASP)

·         IAM authentication hardening for management console and API level access of cloud services.

·         Database, application and cloud services secret management (e.g. AWS/Azure access key secret key and other App and DB credential details)

·         Cloud services configuration hardening for data access (e.g. S3 bucket or Azure BLOB access management)

·         Adopt Serverless administration with tools like AWS Systems manager for secured operations practice.

·         Use least privilege policy for IAM role attached to cloud instances to restrict the compromised instance to make API calls to infrastructure.

·         Based on workload threat vector events, automate security operations by applying security controls at cloud services. More details on the same is available here

Stage-2: Threat vector and security consideration for application with micro service architecture:

When cloud journey evolves, application starts becoming loosely coupled and stateless in nature. Application starts integrating with other cloud services like Object storage (e.g. AWS S3, SQS, SNS), Caching services (e.g. AWS Elasticache, Azure Radis), NoSQL databases (e.g. AWS DynamoDB, Azure Cosmos DB etc.). Similar architecture becomes good candidate for micro services framework for application where every modules becomes individual small application entity in container and each service communicates over RESTful API call.  

While Developers follows agile methodology and releases new application update every day, DevOps team uses containers for each micro service for CI/CD. This process makes security team loose visibility in many moving components being used by developers and/or DevOps team inside containers.

   “if you don’t have visibility on threat, you can’t apply security controls on it”. Since containerized micro service application removes visibility for the teams who follows traditional security methods, it’s important to integrate security in DevOps process.  

Stage-2: Threat vector in containerized applications

 

In addition to stage 1 mitigation stage 2 threat mitigation measures for micro-service architecture application in containers are as follows.

·         Write security as a code for automation and integrate security validation process in DevOps CI/CD pipeline.

·         Identify the vulnerability and malware in Docker images from registry before it gets deployed in production.

·         Protect the vulnerability inside container with IPS. More details on the same is available here.

·         Carefully choose base Docker image with security considerations (e.g. Who has created image? how old image is? When it was last updated? What are the packages it contains?).

·         Monitor the integrity of Docker, kubelet and other supportive container service configuration files (These file modifications can allow attacker to provision rouge containers through K8S and Docker API).

·         Real-time malware scanning inside containers root file system and shared mount points.

·         Use thin operating system and lock down the file system for any unauthorized application (Application control on Docker host)

·         L7 application protection with Cloud provider WAF service (e.g. AWS WAF) and Run-time application self-protection(RASP).

·         Secure kubernetes API server, etcd database services and kubernetes cluster authentication.

o   K8S API authentication with RBAC policy

o   Restrict cloud metadata (AWS, GCP, Azure) API access

o   Secure kubelet API access to secure Docker host

o   Encrypt secret at rest

Stage-3: Threat vector and security consideration for serverless application:

Serverless applications are evolving from micro services architecture that can work on asynchronous calls based on event driven functional programming. These events are generated from application API calls or with other cloud services integration. 

The shared responsibility model in serverless application becomes more complex from security compliance because of asynchronous nature of function calls which makes data flow saturated in multiple silos. Threat vector is different in serverless application (than monolithic/micro services applications) that requires to think of security from application design perspective.

                In order to access other cloud services, serverless function need to be configured with identity role and permission provided by cloud provider. Such infrastructure privilege access to function code can become new threat vector if access to function trigger (External APIs) is not harden.

                Serverless functions in each cloud service provider is configured differently. While AWS provides Lambda with basic library and default language support, Azure Function requires different configuration for each language version and libraries from KUDU shell access. Such variant on basic building blocks changes threat vectors for different serverless application in each cloud service provider.

For the private cloud serverless applications and some of the public cloud service providers recently affected by vulnerability in serverless platform Apache OpenWhisk (CVE-2018-11757 and CVE-2018-11756) that can allow attacker to overwrite the source code of a serverless function that is being executed in a container and influence subsequent executions in the same container under certain conditions.

Stage-3: Threat mitigation measures for serverless application architecture.

·         To prevent Denial of Wallet (DoW) attacks in serverless applications, secure perimeter level APIs that triggers serverless functions. You can do this with function execution throttling, API gateway, CDN, WAF and authentication services mentioned bellow.

·         Secure API authentication using authentication services like AWS Cognito, Azure AD and other custom identity providers.

·         Restrict serverless function access by applying least privilege policy to function IAM role (e.g. If function need access to AWS DynamoDB or Azure CosmosDB, it’s better to provide read-only permission to NoSQL DB service)

·         Mandatory code review and static analysis.

·         Encrypt function’s environment variable with key management system (e.g. AWS KMS or Azure Key vault)

·         Leverage tools like AWS SSM parameter store for secrets and configuration management.

·         Automate security analysis as part of CI/CD pipeline (e.g. Code and library vulnerability analysis in serverless framework or zappa deployment process).

·         Throttle API access for individual user to prevent one customer from consuming all back-end system’s capacity.

·         Azure function kudu management portal provides exposure of shell (CMD) access for serverless app. Its recommended to manage vulnerabilities of 3^rd party libraries and external modules.

·         For private cloud implementations of serverless platform, secure the platform (e.g. Apache OpenWhisk) by vulnerability management patching and host level IPS protection for container security.

                Although security is different for each stage of cloud adoption lifecycle and type of application, basic principles for security remains same. Visibility is the key to apply security controls on any threat vector “If you can’t see the threat, then you cannot apply the security controls on it”. Integrity monitoring of file system and log analytics can help to provide visibility on threat vector.

             Vulnerability scanning, applying patch and virtual patch is mandatory steps for all stages.  Intrusion prevention system (IPS/IDS), monitoring possible C&C connection (using web reputation) and firewall can be used to identify and mitigate the threats at initial phase of intrusion kill chain.  Advanced machine learning, behavioral analytics and white listing of approved app (application control). More details on such preventive controls are available here.