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.
·
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 3rd 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.