The 5 Security Pillars Required For All AWS Cloud Deployments

The 5 Security Pillars Required For All AWS Cloud Deployments by Tim Layton @ CloudSecurityLaunchPad.com

In this article today, I share the five security pillars that every AWS cloud deployment should consider and ultimately implement within each layer of your application/system deployment. I also include the core cloud security principles that are aligned to the pillars to help you strengthen your workload security and improve your overall security posture.

IDIDIR CLOUD SECURITY PILLARS

In order to build a strong security posture within your public and hybrid cloud deployments, you should use these five pillars to ensure you have a comprehensive approach to securing your applications and systems in the cloud. I call this the IDISIR Cloud Security Pillars model because if you take the first letter from each of the first four pillars and add IR for the fifth, this makes it easy to recall and share during everyday discussions.

  • Identity and Access Management (IAM) is the core backbone of every cloud deployment. If you get this wrong, everything else is at risk. In all cloud deployments, to include AWS, by its very design, you must have an account and then be granted privileges before you can provision and orchestrate services.
    • If you have an admin type of account because you require this for your job, this doesn’t mean your account is authorized to do anything you want. It also doesn’t mean your deployments do either. For example, let’s say that you deployed an EC2 instance to host your new web-facing application and you are going to read/write/update data in an S3 bucket. The API calls from your EC2 instance to your S3 bucket must be signed and authorized to make those calls. This is not implicit and by using IAM best practices, the application code on the EC2 instance needs access to credentials to make the signed API calls to S3. You would need to use IAM Roles to handle the signed and authenticated API calls from your application to S3.
  • Detection (logging and monitoring) – Logging and monitoring should be designed into the application from the beginning and implemented at every layer from the infrastructure through to the application code. AWS services provide a comprehensive set of logging and monitoring solutions that will help you proactively monitor the overall health and security posture of your deployment. AWS provides enterprise level services such as AWS CloudTrail, Amazon CloudWatch, and Amazon GuardDuty as part of their core detection, logging, and threat monitoring services.
    • CloudTrail enables you to monitor your AWS deployments at the API level, including all API calls made via your AWS Management Console, AWS SDK’s and AWS Command Line tools. This is really important for your overall cybersecurity health. CloudWatch also allows you to identify which accounts and users called AWS APIs for services that supports CloudTrail, the source IP address the calls were made from, in addition to when and where the calls occurred.
    • AWS CloudWatch provides an enterprise-wide reliable, scalable, and flexible monitoring solution that you can start using within minutes. You no longer need to set up, manage, and scale your own monitoring systems and infrastructure. AWS CloudWatch is an important tool for DevOps in particular because it provides you with data and actionable insights to monitor your applications, respond to system-wide performance changes, optimize resource utilization, and get a unified view of operational health.
    • Amazon GuardDuty is a world-class threat detection service that continuously monitors your deployment for malicious activity and unauthorized behavior. You can then expose notifications via Amazon CloudWatch so you can trigger an automated response or notify a human. These are the basic build blocks for security automation in the AWS cloud.
  • Infrastructure Security – When you treat infrastructure as code you need to apply the same rigor and requirements of application code development to infrastructure provisioning or else your security posture will suffer and an undesirable security incident is very likely just around the corner.
    • All configurations should be defined in a declarative way and stored in a source control system such as AWS CodeCommit or similar tool, the same as application code. Your infrastructure provisioning, orchestration, and deployment should also support the use of the infrastructure as code
    • By using AWS CloudFormation as a service, you are enabling developers to create AWS resources in a predictable and reliable manner. Resources are written in text files using JavaScript Object Notation (JSON) or Yet Another Markup Language (YAML) format. Effectively, you author your resources in JSON or YAML with any code editor of choice, check it into a version control system, and then CloudFormation builds the specified services in safe, repeatable manner. 
  • Data Protection – Safeguarding important data is a critical piece of every cloud deployment and this includes protecting sensitive data within your entire cloud infrastructure and complete data lifecycle. Having an enterprise set of policies and guidelines for classifying data is a key and foundational step for data protection.
    • Some basic data protection strategies that should apply to every AWS deployment include:
      • Use multi-factor authentication (MFA) for every admin type of account.
      • Use SSL/TLS to communicate with AWS resources. Use TLS 1.2 or later.
      • Set up API and user activity logging with AWS CloudTrail.
      • Use AWS encryption solutions, along with all default security controls within AWS services.
      • Use advanced managed security services such as Amazon Macie, which assists in discovering and securing personal data that is stored in Amazon S3.
  • Incident Response & Threat Detection – Automating aspects of your incident management process is a foundation security requirement for all cloud deployments. You will enjoy an increase of speed during a real response and this could make a significant difference in the degree of loss experienced. Having a defined and documented incident response (IR) plan for your specific cloud deployment is no small task and requires a significant investment of time and resources if done properly.
    • It’s not all doom and gloom, however, serious IR capabilities need to be accounted for. For example, when a deviation from your baseline does occur (e.g., misconfiguration), this should trigger an event that may lead to an investigation. All of this starts with understanding the basic concepts of security incident response within your AWS environment, as well as the issues you need to consider to prepare, educate, and train your cloud teams before security issues occur.
    • All IR plans should prepare your incident response team to detect and respond to incidents in the cloud by enabling detective capabilities, and ensuring appropriate access to the necessary tools and cloud services. Additionally, prepare the necessary runbooks, both manual and automated, to ensure reliable and consistent responses. Work with other teams to establish expected baseline operations, and use that knowledge to identify deviations from those normal operations.
    • Bottom line, ensure that you have a documented and tested IR plan that is specific to your AWS deployment. Carrying over an IR plan that was used prior to your migration isn’t going to cut it in your cloud deployment because there are too many differences.
    • Continuously monitoring for malicious activity and unauthorized behavior is key to protecting your AWS accounts, workloads, and data stored in S3. Amazon GuardDuty is a native AWS service designed to specifically do all of these tasks. GuardDuty uses machine learning, anomaly detection, and integrated threat intelligence to identify and prioritize potential threats. GuardDuty analyzes tens of billions of events across multiple AWS data sources, such as AWS CloudTrail event logs, Amazon VPC Flow Logs, and DNS logs. By integrating with Amazon CloudWatch Events, GuardDuty alerts are actionable, easy to aggregate across multiple accounts, and straightforward to push into existing event management and workflow systems.

RESOURCES

SECURITY DESIGN PRINCIPLES (IE-AA-PKP)

In the cloud, there are a number of principles that can help you strengthen your workload security. I created a simple acronym (IE-AA-PKP) to help me recite these principles from memory. Print these off along with the IDIDIR Cloud Security Pillars and use this to frame up your next project or evaluate current deployments to see how well you are doing.

Implement a Strong Identity Foundation: Implement the principle of least privilege and enforce separation of duties with appropriate authorization for each interaction with your AWS resources. Centralize identity management, and aim to eliminate reliance on long-term static credentials.

Enable Traceability: Monitor, alert, and audit actions and changes to your environment in real time. Integrate log and metric collection with systems to automatically investigate and take action.

Apply Security at all Layers: Apply a defense in depth approach with multiple security controls. Apply to all layers (for example, edge of network, VPC, load balancing, every instance and compute service, operating system, application, and code). Don’t overlook this principle. 

Automate Security Best Practices: Automated software-based security mechanisms improve your ability to securely scale more rapidly and cost-effectively. Create secure architectures, including the implementation of controls that are defined and managed as code in version-controlled templates.

Protect Data in Transit and at Rest: Classify your data into sensitivity levels and use mechanisms,such as encryption, tokenization, and access control where appropriate.

Keep people away from data: Use mechanisms and tools to reduce or eliminate the need for direct access or manual processing of data. This reduces the risk of mishandling or modification and human error when handling sensitive data.

Prepare for Security Events: Prepare for an incident by having incident management and investigation policy and processes that align to your organizational requirements. Run incident response simulations and use tools with automation to increase your speed for detection, investigation, and recovery.


Tim Layton specializes in demystifying the complexities and technical jargon associated with cloud computing security and risk management for business stakeholders across the enterprise. Tim is a cloud security thought leader defining actionable and defensible strategies to help enterprise stakeholders make risk-based decisions and prioritize investments in the new digital frontier.

Stay Connected With Tim Layton

LinkedIn: www.Linkedin.com/in/TimLaytonCyber

Website: http://CloudSecurityLaunchPad.com

Get My Free Cloud Security Journal


COMMON CYBERSECURITY RISK TERMS DEFINED

Threat: Any circumstance or event with the potential to adversely impact organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, or the Nation through an information system via unauthorized access, destruction, disclosure, or modification of information, and/or denial of service. (NIST 800–30)

Threat: potential cause of an unwanted incident, which can result in harm to a system or organization. (ISO 27001)

Vulnerability: Weakness in an information system, system security procedures, internal controls, or implementation that could be exploited by a threat source. (NIST 800–30)

Vulnerability: weakness of an asset or control that can be exploited by one or more threats. (ISO 27001)

Likelihood: A weighted factor based on a subjective analysis of the probability that a given threat is capable of exploiting a given vulnerability or a set of vulnerabilities. (NIST 800–30)

Likelihood: chance of something happening. (ISO 27001)

Risk: A measure of the extent to which an entity is threatened by a potential circumstance or event, and typically a function of (i) the adverse impacts that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence. (NIST 800–30)

Risk: effect of uncertainty on objectives. (ISO 27001)

Security Controls: The management, operational, and technical controls (i.e., safeguards or countermeasures) prescribed for an information system to protect the confidentiality, integrity, and availability of the system and its information. (NIST 800–30)

Compensating Security Control: A management, operational, and/or technical control (i.e., safeguard or countermeasure) employed by an organization in lieu of a recommended security control in the low, moderate, or high baselines that provides equivalent or comparable protection for an information system. (NIST 800–30)

Impact Level: The magnitude of harm that can be expected to result from the consequences of unauthorized disclosure of information, unauthorized modification of information, unauthorized destruction of information, or loss of information or information system availability. (NIST 800–30)

Residual Risk: Portion of risk remaining after security measures have been applied. (NIST 800–30)

Security Posture: The security status of an enterprise’s networks, information, and systems based on information assurance resources (e.g., people, hardware, software, policies) and capabilities in place to manage the defense of the enterprise and to react as the situation changes. (NIST 800–30)

Get My Free Cloud Security Journal

Tim Layton

Tim Layton

Get Tim Layton's Free Cloud Security Journal so you can remain current with the latest cloud security trends and updates. Tim is a cloud security thought leader defining actionable and defensible strategies to help organization's make risk-based decisions and prioritize investments.

Recommended Articles

Leave a Reply

Your email address will not be published. Required fields are marked *