By Krishna Kumar, MBA, PMP
Senior Cloud Consultant
Customers are often overwhelmed with cloud security controls and assume that security is the sole responsibility of cloud service providers (CSPs) such as Amazon Web Services (AWS), Microsoft Azure, and Google Cloud—but customers have a big responsibility as well. Organizations operating in the cloud inherit security controls from the CSP like physical hardware, physical networking, facility access etc. CSPs use hypervisor software, a low-level operating system that virtualizes the physical hardware and runs guest operating systems like Linux, Windows etc. on top of it.
The security boundary for the CSP stops at the hypervisor level. Customers are responsible for security above the hypervisor that includes the operating system and applications that run on them. Customer responsibilities for security include periodic patching, running virus scans, vulnerabilities scans, penetration testing, and more, along with setting up rules for tracking and preventing cyber threats and vulnerabilities.
At ECS, our team understands the importance of the shared responsibility model for cloud security. As a result, we employ security by design, an approach which builds security into every stage of design, development, and management. Security by design places an emphasis on infrastructure, making the cloud a secure environment capable of handling the largest and most complex computing tasks being undertaken in the public and commercial sectors. The current discussion is focused on incorporating security in the DevOps process.
SecDevOps: The Key To Cloud Security
SecDevOps puts security first in the development process so that vulnerabilities are caught early in the process and mitigated, ensuring a clean build. It merges security, development, and operations into a seamless process to produce a secure, solid product. While SecDevOps is often seen written as DevSecOps, we prefer to put security first (Sec) so organizations can remember to include it at each step and better avoid risk of intrusion. ECS practices SecDevOps based on the idea that “one intrusion is too many.”
Security by design takes place in three stages: first, with planning and preventing access; second, designing system security at every component and level; and finally, remediating with active monitoring. Let’s look at the three stages and see how they contribute to an overall more secure product developed in the cloud.
THREE STAGES OF SECURITY BY DESIGN
SECURITY AT ACCESS
The basic tenet at this stage is to give users access only if they need it. When they no longer need it, we remove access. This helps keep the development and final product secure.
Because ECS recognizes the importance of understanding the shared security model offered by the leading CSPs, we know customers operating in the cloud get an incredible boost by inheriting the security apparatus from the provider. But with that comes responsibility on the part of the users, in this case, developers.
For those services for which the developer is responsible, security by design places high emphasis on infrastructure security with consolidated identities at a single point of entry. This means users can access what they need from a variety of applications without having to go into each account separately, cutting down on the number of points of entry.
- Users are given the least number of privileges based on their roles.
- We enforce strong password policies with multi-factor authentication that expire.
- We use a regular rotation of the access keys.
- We make sure to remove users no longer requiring access.
- We discourage explicit use of access keys preferring roles. For those needing access keys, we force regular key rotation.
- We enable across regions of operation and disable regions not in scope.
- We enable cloud trails across regions of operation and disable regions not in scope.
SECURITY AT SYSTEM
Once we limit access, the next step is to address security throughout development. This takes careful testing at each step to ensure intrusion isn’t possible. Testing should not happen at the end of development. Each piece should be tested as it is created, making security a part of the overall process.
Strong secure version control is a must. For example, if you are using open source code, you must stay current with the most secure version that has the latest vulnerabilities addressed. This means if a breach was discovered in a particular code, for example, you use the latest secure version
ECS designs infrastructure by reducing the threat surface area, provisioning systems within private zones in the cloud which are under the control of the organization and usually behind their firewall. System-level access and ports are further restricted with a network access control list and security groups. Depending on specific requirements, traffic control is further restricted to pass through specific networks to enable sniff, capture and inspect packets. Access is restricted even more through secure scripting and configurations.
Inbound internet access points are protected with scalable native network services such as:
- Elastic load balancers
- DDos attacks with content delivery networks (CDN)
- Web application firewalls (WAF)
- Active/passive or active/active configurations across multiple zones and regions with weighted domain name server (DNS) configurations.
By default, data encryption will be applied on transit and at rest. To secure traffic flow through corporate networks, virtual private network (VPN) tunnels and/or private cloud provider connections like Direct Connect (AWS) or ExpressRoute (Azure) are provisioned. To keep traffic safe within the cloud network, special routes are configured in routing tables to reach the other services using the private network of the cloud provider rather than the internet (e.g. using S3 end points in AWS).
All of these approaches require the developer to keep security at the forefront of the process, reducing the risk of intrusions during and after development.
SECURITY BY ACTIVE MONITORING
ECS implements system security by testing security at every build and failing the build early. If the build fails, we capture the vulnerabilities early, reducing risk away from production.
Using a number of cloud native features like AWS Cloudwatch, SNS notifications, alarms, cloud trail and common cloud scripts, events and metrics are monitored for abnormal behavior and escalated progressively for appropriate attention. Routing scans, code analysis, active patching and disabling vulnerable components are among the best practices we implement to ensure maximum security of the system. Once the product has been released, it must be constantly monitored to ensure it remains secure.
ECS anticipates all systems will fail at some point, which is why we bring in extensive processes and procedures to mitigate situations that may creep into the system for unexpected and unknown reasons.
In short, security should be a part of the product lifecycle, from concept through implementation and operation. Don’t wait until the product is released to discover there’s a vulnerability. Take security through each step and create the most secure product possible.
For more information on ECS’ approach, reach out to an ECS expert.