Cloud adoption has increased exponentially over the years. 94% of enterprises use the cloud already.
There used to be two main camps of cloud users as below:
- Cloud users who were skeptical of security of public cloud in the first place.
- Cloud users who believe that public cloud takes care of all security aspects automatically i.e. public cloud are inherently secure.
While the critical mass of camp #1 users has declined, it seems like camp #2 users have increased in volume. In many conversations with startups and otherwise, we have had discussions wherein the customer believed that their AWS cloud environment is inherently secure and nothing needs to be done from security angle. Nothing could be further from the truth here.
Since inception AWS has talked about Shared Responsibility Model when it comes to Security and Compliance. For Infrastructure as a Service (IaaS) services, customers own security aspects to a greater extent, as compared to Platform as a Service (PaaS) services where customers are mainly responsible for their data. For example if a customer is using Elastic Compute Cloud (EC2) instances, then they are responsible for management of the guest operating system (including patches and security updates), any application or utilities installed on those instances, etc.
- Operational Excellence Pillar
- Security Pillar
- Reliability Pillar
- Performance Efficiency Pillar
- Cost Optimization Pillar
- Identity and Access Management
- Detection
- Infrastructure Protection
- Data Protection
- Incident Response
Given that many AWS customers still run their workloads on AWS using EC2, let us discuss more about Infrastructure Protection. Infrastructure Protection is further broken into 2 parts: Protecting Networks and Protecting Compute. If we consider “Protecting Compute” for EC2 workloads, then customers are strongly advised to perform vulnerability management. Here is an excerpt from AWS documentation:
Frequently scan and patch for vulnerabilities in your code, dependencies, and in your infrastructure to help protect against new threats.
It is important to note that AWS recommends a holistic approach to vulnerabilities across all levels i.e. code, dependencies and infrastructure (i.e. EC2 and containers). Let us look at each of these in more detail below:
- Code – It is recommended to use static code analysis tools to identify common security issues in source code
- Dependencies – One needs to use dependency checking tools to determine whether libraries/packages/modules your code links against are the latest versions, are themselves free of vulnerabilities, and have meet your license compliance requirements.
- Assess your EC2 instances for any known vulnerabilities
- Assess your containers (in ECR or otherwise) for any known vulnerabilities
ThreatWorx can help with all of the above and that too in a completely non-invasive scan-less and agent-less manner. ThreatWorx aids in the following as well:
- Cloud Security Posture Management (CSPM) – CIS Benchmark tests for AWS cloud.
- Dynamic Application Security Testing (DAST) for your web applications – OWASP vulnerabilities, etc.