Organizations adoption of Cloud Infrastructure as a Service (IaaS) is ubiquitous.
This 4 part blog series aims to outline the key security considerations for organizations looking to adopt devOps and or are already utilizing Infrastructure services from Cloud providers viz. Amazon Web Services (AWS), Azure or Google Cloud Platform.
Depending on the crawl/walk/phase of the adoption different considerations outlined below would apply.
The blog series has been divided into following 4 parts with one part published per week.
Part 1 – Security Consideration #1 – Visibility, Continuous Controls Monitoring and Compliance (Current Blog)
Part 3 – Security Consideration #3 – Infrastructure Identity Governance and Administration
Part 4 – Security Consideration #4 – Privilege Access Management and Keys management
Security Consideration # 1 – Visibility, Continuous Controls Monitoring and Compliance
Gaining visibility and continuously monitor for vulnerabilities and risks in the cloud ecosystem are key to achieve compliance and stay compliant.
1A. Visibility Challenge
Reducing “Blast Radius” is critical for organizations moving to or managing their workloads on Cloud. To realize this, organizations typically have multiple Amazon Web Services(AWS) Accounts, Microsoft Azure Subscriptions or Google Cloud Platform (GCP) accounts. Having visibility across the entire ecosystem requires inspection and integration across all these accounts/subscriptions etc. which could be complex and challenging, especially when it requires correlation of Identities and access across these systems. Gaining visibility translates into two kinds
· Misconfigured/Vulnerable workloads visibility – Gives a visibility on misconfigured or vulnerable workloads such as workloads with unencrypted volumes, open SSH/RDP connections to internet, backups disabled on databases etc. This indicates the Attack Exposure on Critical Assets in the ecosystem.
For ex. EC2 Instances with open SSH/RDP ports exposed to Internet or Unencrypted RDS /RedShift or EBS Volumes
. Access Visibility – Extremely important to gain Access visibility, providing Administrators/Infra owners to gain insights to “Who” has access to “What”. How many High Privileged Users/Roles/Policies exist in their environments? This indicates the Access Exposure on critical assets in the ecosystem
Gaining visibility into both Attack and Access exposure is extremely critical.
Home Grown Solutions/Vendor Solutions/3rd Party Products with native API integrations should provide both. While evaluating/designing for solutions it is imperative to look at both these aspects of Visibility.
1B. Risk Signatures and Security Controls mapped to Compliance Framework
Getting the risks visibility is the first step towards securing infrastructure services and should be followed by mapping the same to Industry specific benchmarks and compliance mandates viz. PCI, HIPAA, FedRamp, SOX, CIS etc.
For eg. All VMs / EC2 instances running on shared tenancy violate the HIPAA regulation which mandates running workloads on dedicated tenancy.
Similarly, PCI compliance mandates data to be encrypted at rest. Security controls providing visibility on instances with unencrypted Disks/ unencrypted EBS (Elastic Block Storage) Volumes/ unencrypted AWS RDS or SQL for Azure provide PCI violations for data at rest category.
1C. Continuous Controls Monitoring and Real time protection of Infra Assets –
Achieving compliance is hard. Staying compliant is harder. With the elasticity of cloud comes the challenge of enforcing organization’s security baseline across the ever changing infrastructure.
Cloud Infra providers do not provide an extensible preventative control framework which would allow organizations to enforce their security baseline standards across Infra objects.
For ex. Stop EC2 instances which have open SSH ports to internet when they are created. Alert immediately when an unencrypted SQL for Azure is created.
Integration with native cloud services (For eg. AWS Config, CloudWatch events) to trap such events and send the same to a preventative controls framework which could be comprised of Rules Engine and Enforcement Policies is the way to achieve real time protection of Infra Assets. This can be a key differentiating factor for organizations looking to achieve compliance with automation and low costs in the long term.
1D. Log Analysis, Behavioral Patterns Analysis and Anomaly Detection
Lastly gaining visibility also requires extensive log analysis from various sources in the cloud ecosystem. Biggest Challenge to do this would be to manage the sheer volume and velocity with which the logs get generated. They are usually in the range of terabytes/petabytes.
Ingesting and sifting logs and then deducing meaningful information out of it requires solid feat of engineering and often adoption of big data technologies (Apache Spark, Elasticsearch etc.). Logs from these sources should be streamed to the big data platform to gain a complete visibility on the API usage on the Infra services. Log types which should certainly be ingested
· Network logs – Help in analyzing traffic flows to cloud’s virtual networks, packet drops, port analysis etc.
· API Logs – Help in analyzing API usage, privileged activity and also useful in creating baseline patterns
· Workload Logs – Logs from the workloads, helpful in determining rogue workloads
· devOps tool logs – Logs from tools like Chef, Puppet, Ansible etc. helps in correlating the exposure across the entire ecosystem
Lastly, the logs from these sources needs to be fed into user entity behavioral platforms (UEBA) to establish baseline user behavior patterns. With the help of machine learning algorithms not only the deviations to user behavior patterns could be obtained signifying anomaly events but it also helps in providing peer and outlier analysis. Integrating with UEBA platforms is key to derive user behavior analytics and identify unknown and insider threats.
Hope you all found this blog useful. Feedback and suggestions are always welcome. The next part will be focused on Securing CI/CD processes for a secure devOps ecosystem.