AWS Cloud Security Design Principles Checklist
You should look at each of your AWS workloads and run them through this basic security principles checklist to ensure you are not missing the obvious. Remember, just because something is simple and straightforward, does not mean it is executed properly. Did you know the leading cause of death in hospitals is linked to healthcare professionals not following standard operating procedures and policies?
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.
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)
