In part 4 in my latest series showcasing the six pillars of the AWS Well-Architected Framework, we continue to take a look at the Security pillar. As security is such a large topic, we will be covering the security stack across a series of posts. The intent of this blog series is to cover security and security practices at a high level. This is not an in-depth or comprehensive security guide. For comprehensive security guidance, Cevo’s Security Practice has your back.
If you’d like to learn more about the other pillars of the Well-Architected Framework, check out the other blogs in this series via the links below.
What we will be covering
- Threats and Exploits
- Common Services Used for Securing Workloads in AWS
- Importance of Security Classification
Why we are learning this
- To help others navigate and understand how to design and implement secure architecture that aligns to security requirements
- Using the AWS Well-Architected: Security Pillar for guidance to build secure infrastructure
How this will help me
You will:
- Be able to successfully define security requirements
- Have a better understanding of the components used in securing infrastructure
- Have a better understanding of security terms and the services at a high-level
- Be able to build effective solutions aligned to the AWS Well-Architected: Security Pillar
Threats and Exploits
In security there are many different types of threats and exploits and each requires different approaches to achieve. Threats can be internal or external and vary by nature at the software level. Exploits allow for an attacker (or actor) to use for gaining access and/or control to systems.
In software we refer to Common Vulnerabilities and Exploits (CVE’s) that represent known vulnerabilities for exploits by internal or external actors to gain access to or control of assets by using published (hence known) methods. Other threats include “zero day” vulnerabilities in which the threat hasn’t yet been executed and when it does – the behaviour the threat exhibits must rely on anomaly detection as it can’t be patched until after the fact. Other software threats include Malware (embedded threats), Worms (execute using multiple machines), Viruses (spread my machine-to-machine) and Ransomware/Crypto-Locking critical business assets (using encryption to extort individuals/companies for financial gain). GuardDuty Malware Protection can help identify Malware through anomaly detection.
Patching is used to provide additional features and interdependencies between other software components that comprise an application. Most commonly, patching is used to avoid CVE’s however the process is often avoided as it can introduce instability to software. A “fail-forward” culture is really needed to drive an effective patching strategy where problems are dealt with at the time and you “move forward” with the next release. Services such as AWS Systems Manager can be used to audit and also patch resources using automation.
Internal and external actors are treated differently from one another. External actors are generally thwarted using network-layer approaches (using private access networks for private resources) or specific source networks. When using public-facing resources, external actors are reduced by using application layer techniques such as Web Application Firewalls (WAF’s), mutual-trusted certificates using API Gateways, strong encryption using SSL to prevent eaves-dropping and “Man-In-The-Middle” attacks, trusted authentication and MFA. For internal actors, the approach needs to heavily utilise anomaly detection and authentication techniques as they are generally seen by most as “one of us” and therefore “trusted”. Robust scanning and observability is key to identifying and responding to threats.
Threats aren’t always about stealing information or data either. Threats can also be non-malicious such as running over-provisioned resources owing to huge consumption bills or even accidentally being sent information via internal systems like email. While email is a difficult tool to police at scale, resources can be limited through policies and/or using Infrastructure as Code (IaC) through DevSecOps operations and principles and limiting access to source code. These are some methods used to protect information, infrastructure and assets.
Common Services Used for Securing Workloads in AWS
Where possible – consider taking a continuous approach to security compliance. For example, running the CIS Benchmark in your release pipeline for EKS using kube-bench allows you to evaluate CIS Benchmark every time you make a release which you can fail the release pipeline if it does not pass. The following are some generic guidelines that are recommended as good practice above the usual suspects like use MFA and never login using root credentials, not storing AWS keys in repositories etc:
- Implementing enhanced scanning on ECR allows Amazon Inspector to scan all your images against vulnerabilities and exploits continuously.
- Enabling GuardDuty across accounts and leveraging managed services GuardDuty for RDS, GuardDuty for EKS, GuardDuty Malware Protection and GuardDuty for S3 allows for anomaly detection within your account as well as resources prone to anomalies and now supports GuardDuty for RDS Aurora to detect anomalies with database operations on fully managed services.
- Implementing effective monitoring solutions, billing alarms and anomaly detection services allows visibility of events that would otherwise go unnoticed.
- Utilising WAF with specific application signatures
- Utilising Systems Manager – the Systems Manager agent is installed by default on all Amazon Linux 2, the new Amazon Linux 2023 and Windows 2016+ instances by default and all it needs to operate is Internet access or SSM VPC Endpoints and the Instance Role called “AmazonSSMManagedInstanceCore” added to any existing Instance Role Profile (details here). The agent provides metadata back to Systems Manager for inventory management for packages/applications and their associated CVE’s. In addition to the ability to leverage automation and patch management of all your managed instances (even outside of AWS running the Systems Manager agent). The agent and associated instance profile can be set to default using Default Host Management Configuration.
- Using Systems Manager – Fleet Manager for remote access instead of bastion hosts
- Use chained Security-Groups
- Security by default mindset – automating security compliance and monitoring in release pipelines
- Leverage AWS Config rules to enforce and report on compliance
- Utilise AWS Trusted Advisor recommendations to make more informed decisions
- Test and validate access policies using the IAM Policy Simulator
- Evaluate the Network Access Analyzer to understand and evaluate your security posture
- Leverage CodeGuru to evaluate code security posture
- Leverage Write Once, Read Many (WORM) storage where data shouldn’t be manipulated (secured by policy applied at a hierarchical level such as Service Control Policies or Organization Policies)
- Leverage snapshot and backup mechanisms and any version control capabilities to protect data against corruption with point in time recovery capability
- Leverage PaaS solutions where possible over IaaS solutions to reduce risk and management overhead
- Leverage robust Infrastructure as Code (IaC) and DevSecOps practices to automate governance and compliance where possible
- Leverage Security Hub reporting capabilities and recommendations
- Leverage services such as CloudTrail Lake to centralise and consolidate audit trails
- Build a centralised logging account for consolidating CloudWatch and CloudTrail events for complete visibility
Importance of Security Classification
Security classification refers to the treatment and labelling of data and treating that data differently depending on what it is classified as such as Personal Identifiable Information (PII), financial, medical, sensitive, restricted, secret, For Your Eyes Only (FYEO), cryptographic and other material (even geographical related data to citizens). Regulated organisations such as Financial Services Industry (FSI), Insurance, Casinos Liquor and Gambling, Government, Health and Resources sectors all require robust security classification and are regularly audited for compliance to specific regulations. They risk huge financial fines, incarceration and even losing the ability to operate as a business if they fail to adhere to their respective industry standard. This said, many organisations in commercial spaces should be adopting these practices regardless as classification of data promotes good security practices.
Classification of data isn’t always clear and datasets can contain several types of data. In those cases the data with the highest classification should apply to the dataset as it generally has the highest level of controls applied to it. Classification identifies the data and how it is treated, so to drive good security practice, these simple questions can help guide the safeguards in place to protect it:
- What is the data type?
- Who NEEDS access to this data?
- How is the data accessed?
- Does this data need to be accessible to people or systems?
- If system access is required – what else does that system have access to?
- How is access to the data audited (identifying who, what, when and where)?
- Does this data need to be stored in the first place?
Asking these questions and implementing processes to handle these capabilities will foster a healthy security culture across organisations. Security is everyone’s responsibility and security awareness is not enough on its own to be secure. Security must be actively applied and implemented to ensure the safety of data and information. Recent high-profile data breaches have shown in many cases that the data breached had profound consequences to the individuals it exposed and the question needs to be asked – could this have been avoided if appropriate data classification and therefore treatment of that data adequately applied? It’s a sobering question and reminder of the importance of securing access to and treatment of data appropriately.
