AWSARE.com
Architectually Resilient Environment Discovery Interview
security reliability performance cost optimization operational excellence

Security

SEC 1 How are you protecting access to and use of the AWS root account credentials?
  The AWS root account credentials are similar to root or local admin in other operating systems and should be used very sparingly. The current best practice is to create AWS Identity and Access Management (IAM) users, associate them to an administrator group, and use the IAM user to manage the account. The AWS root account should not have API keys, should have a strong password, and should be associated with a hardware multi-factor authentication (MFA) device. This forces the only use of the root identity to be via the AWS Management Console and does not allow the root account to be used for application programming interface (API) calls. Note that some resellers or regions do not distribute or support the AWS root account credentials.  
Best practices:
  * MFA and Minimal Use of Root The AWS root account credentials are only used for only minimal required activities.

  * No use of Root

SEC 2 How are you defining roles and responsibilities of system users to control human access to the AWS Management Console and API?
  The current best practice is for customers to segregate defined roles and responsibilities of system users by creating user groups. User groups can be defined using several different technologies: Identity and Access Management (IAM) groups, IAM roles for cross-account access, web identities, via Security Assertion Markup Language (SAML) integration (e.g., defining the roles in Active Directory), or by using a third-party solution (e.g., Okta, Ping Identity, or another custom technique) which usually integrates via either SAML or AWS Security Token Service (STS). Using a shared account is strongly discouraged.  
Best practices:
  * Employee Life-Cycle Managed Employee life-cycle policies are defined and enforced.

  * Least Privilege Users, groups, and roles are clearly defined and granted only the minimum privileges needed to accomplish business requirements.

SEC 3 How are you limiting automated access to AWS resources? (e.g., applications, scripts, and/or third-party tools or services)
  Systematic access should be defined in similar ways because user groups are created for people. For Amazon EC2 instances, these groups are called IAM roles for EC2. The current best practice is to use IAM roles for EC2 and an AWS SDK or CLI, which has built-in support for retrieving the IAM roles for EC2 credentials. Traditionally, user credentials are injected into EC2 instances, but hard coding the credential into scripts and source code is actively discouraged.  
Best practices:
  * Static Credentials used for Automated Access.  Stored these securely.

  * Dynamic Authentication for Automated Access. Manage using intance profiles or Amazon STS.

SEC 4 How are you capturing and analyzing logs?
  Capturing logs is critical for investigating everything from performance to security incidents. The current best practice is for the logs to be periodically moved from the source either directly into a log processing system (e.g., CloudWatch Logs, Splunk, Papertrail, etc.) or stored in an Amazon S3 bucket for later processing based on business needs. Common sources of logs are AWS APIs and user-related logs (e.g., AWS CloudTrail), AWS service-specific logs (e.g., Amazon S3, Amazon CloudFront, etc.), operating system-generated logs, and third-party application-specific logs. You can use Amazon CloudWatch Logs to monitor, store, and access your log files from Amazon EC2 instances, AWS CloudTrail, or other sources.  
Best practices:
  * Activity Monitored Appropriately Amazon CloudWatch logs, events, VPC flow logs, ELB logs, S3 bucket logs, etc.

  * AWS Cloud Trail Enabled

  * Monitored Operating System or Application Logs.

SEC 5 How are you enforcing network and host-level boundary protection?
  In on-premises data centers, a DMZ approach separates systems into trusted and untrusted zones using firewalls. On AWS, both stateful and stateless firewalls are used. Stateful firewalls are called security groups, and stateless firewalls are called network Access Control Lists (ACL) that protect the subnets in Amazon Virtual Private Cloud (VPC). The current best practice is to run a system in a VPC, and define the role-based security in security groups (e.g., web tier, app tier, etc.), and define the location-based security in network ACLs (e.g., an Elastic Load Balancing tier in one subnet per Availability Zone, web tier in another subnet per Availability Zone, etc.).  
Best practices:
  * Controlled Network Traffic in VPC For example, use firewalls, security groups, NACLS, a bastion host, etc.

  * Controlled Network Traffic at the Boundary For example use AWS WAF, host based firewalls, security groups, NACLS, etc.

SEC 6 How are you leveraging AWS service level security features?
  AWS services may offer additional security features (e.g., Amazon S3 bucket policies, Amazon SQS, Amazon DynamoDB, KMS key policies, etc.).  
Best practices:
  * Using Additional Features Where Appropriate

SEC 7 How are you protecting the integrity of the operating system on your Amazon EC2 instances?
  Another traditional control is to protect the integrity of the operating system. This is easily done in Amazon EC2 by using traditional host-based techniques (e.g., OSSEC, Tripwire, Trend Micro Deep Security, etc.).  
Best practices:
  * File Integrity File integrity controls are used for EC2 instances.

  * EC2 Intrusion Detection Host-based intrusion detection controls are used for EC2 instances.

  * AWS Marketplace or Partner Solution A solution from the AWS Marketplace or from an APN Partner.

  * Configuration Management Tool Use of a custom Amazon Machine Image (AMI) or configuration management tools (such as Puppet or Chef) that are secured by default.

SEC 8 How are you classifying your data?
  Data classification provides a way to categorize organizational data based on levels of sensitivity. This includes what data types are available, where the data is located, access levels, and protection of the data (e.g. through encryption or access control).  
Best practices:
  * Using Data Classification Schema

  * All data is Treated as Sensitive

SEC 9 How are you encrypting and protecting your data at rest?
  A traditional security control is to encrypt data at rest. AWS supports this using both client-side (e.g., SDK-supported, operating system-supported, Windows Bitlocker, dm-crypt, Trend Micro SafeNet, etc.) and server-side (e.g., Amazon S3). You can also use Server-Side Encryption (SSE) and Amazon Elastic Block Store encrypted volumes.  
Best practices:
  * Not Required Data at rest encryption is not required

  * Encrypting at Rest

SEC 10 How are you managing keys?
  Keys are secrets that should be protected, and an appropriate rotation policy should be defined and used. The best practice is to not hard-code these secrets into management scripts and applications, but it does often occur.  
Best practices:
  * AWS CloudHSM Use AWS CloudHSM.

  * Using AWS Service Controls data at rest can be encrypted using AWS service-specific controls (e.g., Amazon S3 SSE, Amazon EBS encrypted volumes, Amazon Relational Database Service (RDS) Transparent Data Encryption (TDE), etc.).

  * Using Client Side Data at rest is encrypted using client side techniques.

  * AWS Marketplace or Partner Solution A solution from the AWS Marketplace or from an APN Partner. (e.g., SafeNet, TrendMicro, etc.).

SEC 11 How are you encrypting and protecting your data in transit?
  A best practice is to protect data in transit by using encryption. AWS supports using encrypted end-points for the service APIs. Additionally, customers can use various techniques within their Amazon EC2 instances.  
Best practices:
  * Not Required Encryption not required on data in transit.

  * Encrypted Communications TLS or equivalent is used for communication as appropriate.

SEC 12 How do you ensure that you have the appropriate incident response?
  Putting in place the tools and access ahead of a security incident, then routinely practicing incident response will make sure the architecture is updated to accommodate timely investigation and recovery.  
Best practices:
  * Pre-Provisioned Access Infosec has the right access, or means to gain access quickly. This should be pre-provisioned so that an appropriate response can be made to an incident.

  * Pre-Deployed Tools Infosec has the right tools pre-deployed into AWS so that an appropriate response can be made to an incident.

  * Non-Production Game Days Incident response simulations are conducted regularly in the non-production environment, and lessons learned are incorporated into the architecture and operations.

  * Production Game Days Incident response simulations are conducted regularly in the production environment, and lessons learned are incorporated into the architecture and operations.


AWSARE
Source Information provided on this page is from the AWS Well-Architected Framework Document