AWS Security Best Practices

AWS Shared Responsibility Model

  • IAM Service
    • Centrally manage users, security credentials such as passwords, access keys, and permission policies that control which AWS services and resources users can access
  • Regions, AZs and Endpoints
    • Network latency and regulatory compliance
  • Facilities
  • Physical security of hardware
  • Network infrastructure
  • Virtualization infrastructure

Infrastructure services

  • EC2, EBS, ASG, VPC
  • Services for building a cloud infrastructure similar to on-premise
  • You control the operating system
  • You configure and operate any identity management system that provides access to the user layer of the virtualization stack

AWS Manages:

  • AWS Global Infrastructure:
    • Regions / Availability Zones / Edge Locations
  • Foundation Services
    • Compute / Storage / Databases / Networking

Customer Security Responsibilities:

  • Customer Data
  • Platform & Application Management
  • Operating System, network & firewall configuration
  • Client-side data encryption & data integrity authentication
  • Server-side encryption (File system and/or data)
  • Network traffic protection (encryption / integrity / identity)
  • Data in transit / Data at rest
  • Opacity layer between services from AWS and your platform, includes:
    • Data encryption
    • Data integrity authentication
    • Software-signing and data-signing
    • Secure time-stamping

Container services

  • RDS, Elastic MapReduce, Elastic Beanstalk
  • You don’t manage the underlying operating system
  • You are responsible for managing platform-level identity and access management separate from IAM

AWS Manages:

  • Platform & Application Management
  • Operating System, network & firewall configuration
  • AWS Global Infrastructure:
    • Regions / Availability Zones / Edge Locations
  • Foundation Services
    • Compute / Storage / Databases / Networking

Customer Security Responsibilities:

  • Customer Data
  • Client-side data encryption & data integrity authentication
  • Network traffic protection (encryption / integrity / identity)
  • Data in transit / Data at rest

Abstracted services

  • High-level storage, database, and messaging services, such as Amazon S3, Glacier, DynamoDB, SQS, SES
  • You access the endpoints of the services using AWS APIs
  • API manages underlying service components or the operating system on which they reside
  • Abstracted services provide multi-tenant platform which isolates your data in secure fashion and provides for powerful integration with IAM

AWS Manages:

  • Server side encryption provided by the platform
  • Network traffic protection provided by the platform
  • Platform & Application Management
  • Operating System, network & firewall configuration
  • AWS Global Infrastructure:
    • Regions / Availability Zones / Edge Locations
  • Foundation Services
    • Compute / Storage / Databases / Networking

Customer Security Responsibilities:

  • Customer Data
  • Client-side data encryption & data integrity authentication

AWS Trusted Advisor

  • Trusted advisor checks for compliance with security recommendations
    • Limited access to common administrative ports (SSH/22, Telnet/23, RDP/3389 and VNC/5500)
    • Limited access to common database ports
    • IAM is configured to help ensure secure access control of AWS resources
    • MFA token is enabled to provide two-factor authentication for the root AWS account

Define and categorize assets on AWS

Asset Categories:

  • Essential elements, such as business information, process, and activities
  • Components that support the essential elements, such as hardware, software, personnel, sites, and partner organizations

Assets can be quantified in financial terms such as:

  • Negligible / Low / Medium / High / Very high

Design your ISMS to protect your assets on AWS

Security requirements differ depending on:

  • Business needs and objectives
  • Processed employed
  • Size and structure of the organization

Approach for building ISMS (Information Security Management System) on AWS: (ISO27001 framework can helpful with ISMS design and implementation)

  • Define scope and boundaries
    • Which regions, AZs, instances, and AWS resources are “in scope”
  • Define an ISMS policy
    • Objectives that set the direction and principles for action regarding information security
    • Legal, contractual, and regulatory requirements
    • Risk management objectives for your organization
    • How you will measure risk
    • How management approves the plan
  • Select a risk assessment methodology
    • Business needs
    • Information security requirements
    • Information technology capabilities and use
    • Legal requirements
    • Regulatory responsibilities
  • Identify risks
    • Assets
    • Threats to those assets
    • Vulnerabilities that could be exploited by those threats
    • Consequences if those vulnerabilities are exploited
  • Analyze and evaluation risks
    • Calculate the business impact, likelihood and probability, and risk levels
  • Address risks
    • Applying security controls, accepting risks, avoiding risk or transferring risks
  • Choose a security control framework
    • ISO 27002
    • NIST SP 800-53
    • COBIT (Control Objectives for Information and related Technology)
    • CSA-CCM (Cloud Security Alliance-Cloud Control Matrix)
  • Get management approval
    • Approvals from management that acknowledge the residual risks
    • Approvals for implementing and operating the ISMS
  • Statement of applicability
    • Which controls you choose and why
    • Which controls are in place
    • Which controls you plan to put in place
    • Which controls you excluded and why

Risk Assessment Methodologies:

  • OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation)
  • ISO 31000:2009 Risk Management
  • ENISA (European Network and Information Security Agency)
  • IRAM (Information Risk Analysis Methodology)
  • NIST (National Institude of Standards & Technology) Special Publication 800-30 rev.1 Risk Management Guide

Manage AWS Accounts, IAM Users, Groups, and Roles

  • AWS account
    • Do not use root accounts for day-to-day interactions with AWS
    • Choose several AWS accounts if required, e.g. account for each major department
    • Create IAM users within each of the AWS accounts for the appropriate people and resources
  • IAM Users
    • IAM users can be a person, service or application that needs access to AWS resources
    • Create individual IAM users for each individual that needs access
    • Create fine grained permissions to resources under AWS, apply them to groups, and assign users to those groups

Strategies for Using Multiple AWS Accounts

  • Centralized Security Management
    • Single AWS account
    • Centralize information security management and minimize overhead
  • Separation of production, development, and testing environments
    • Three AWS accounts
    • Create an AWS account for each environment
  • Multiple autonomous departments
    • Multiple AWS accounts
    • Create separate AWS accounts for each part of the organization
    • Assign permissions and policies under each account
  • Centralized security management with multiple autonomous independent projects
    • Multiple AWS accounts
    • Single AWS account for common resources, e.g. DNS, Active Directory, etc.
    • Create separate AWS accounts per project
    • Assign permissions and policies under each account

Consolidated billing can be used across accounts.

Managing AWS Credentials

Two types of sign-in credentials:

  • Username/Password
    • Usernames for AWS accounts are always email addresses
    • IAM user names allow more flexibility
    • IAM user passwords can be forced to comply with a policy you define
    • Multi-factor authentication (MFA)
      • Can be required on sign-in
      • Can be activated for users to delete S3 objects
  • Access Keys
    • Access key id & secret
    • MFA for API calls

Delegation Using IAM Roles and Temporary Security Credentials

Use Cases:

  • Applications running on Amazon EC2 instances that need to access AWS resources
    • Developers can distribute credentials to each instance and applications can then use those credentials to access resources
    • Distributing long-term credentials is challenging to manage and a potential security risk
    • IAM roles can be assigned to instances as a better alternative
  • Cross account access
    • Users from one account may need to access resources on another account
  • Identity federation
    • Users might have identities outside AWS, e.g. corporate directly
    • Those users may need to work with AWS resources

Solution:

  • IAM roles & Temporary security credentials
    • Defining a set of permissions to access the resources
    • IAM users, mobile and EC2-based applications can programmatically assume a role
    • Assuming a role returns temporary security credentials that the user or application can use for programmatic requests to AWS

Managing OS-level Access to Amazon EC2 Instances

  • AWS sets up initial instance access using SSH / RDP
  • After first authentication, you might include authentication mechanisms X.509, Microsoft AD, local operating system accounts
  • Linux Instances
    • AWS allows using EC2 key pair, or generating your own key pairs
    • AWS does not store the private key
    • cloud-init service appends the key to ~/.ssh/authorized_keys
  • Windows Instances
    • During AMI launch, ec2config service sets a new random Administrator password and encrypts it using EC2 key pair’s public key
    • Password can be retrieved using AWS Console or command line tools, and by providing the corresponding Amazon EC2 private key to decrypt the password

Secure Your Data

Resource Access Authorization

Individual user’s effective permissions is the union of resource policies and the capability permissions granted directly or through group membership.

  • Resource Policies
    • User creates resources and wants to control other users’ access to the created resource
  • Capability Policies
    • Enforces company-wide access policies
    • Can be assigned to a role
    • Can override resource-based policy permissions by explicitly denying them

Storing and Managing Encryption Keys in the Cloud

  • Recommended to store keys in temper-proof storage, such as Hardware Security Modules (HSM)
  • Amazon CloudHSM can be used to store keys
  • Use CloudHSM for:
    • Database encryption
    • Digital Rights Management (DRM)
    • Pubic Key Infrastructure (PKI)
      • Authentication and authorization, document signing, and transaction processing
  • CloudHSM uses Luna SA HSMs from SafeNet
  • Luna SA meets Federal Information Processing Standard (FIPS) 140-2 and Common Criteria EAL4+ standards
  • You are responsible to manage cryptographic domain of CloudHSM
    • Cryptographic domain is a logical and physical security boundary that restricts access to your keys
    • Clients on EC2 instances can be configured to allow applications to use APIs provided by CloudHSM
    • CloudHSM can be multi-AZ with replication for HA and Storage Resilience

Protecting Data at Rest

  • Encrypt data on S3, EBS, RDS, etc.

Concerns related to protecting data at rest

  • Accidental information disclosure
    • Limit number of users accessing confidential data
    • Use IAM policies to limit access to resources
    • Use encryption to protect confidential data
    • Strategies
      • Permissions
      • File, partition, volume or application-level encryption
  • Data integrity compromise
    • Use resource permissions to limit who can modify the data
    • Perform data integrity checks. If you detect data compromise restore the data from backup / previous object version
    • Strategies
      • Permissions
      • Data integrity checks (MAC/HMAC/Digital Signatures/Authenticated Encryption)
      • Backup
      • Versioning (Amazon S3)
  • Accidental deletion
    • For Amazon S3 use MFA to require additional authentication to delete an object
    • On compromise, restore the data from backup from a previous object version
    • Strategies
      • Permissions Backup
      • Versioning (Amazon S3)
      • MFA Delete (Amazon S3)
  • System, infrastructure, hardware or software availability
    • In case if system failure restore your data from backup, or from replicas
    • Will not be an issue for Multi-AZ enabled services
    • Strategy
      • Backup Replication

Protecting Data at Rest on Amazon S3

  • Permissions
    • Bucket-level / Object level permissions
    • IAM policies
  • Versioning
    • Enable versioning to new version from which you can restore compromised objects
  • Replication
    • Replication is enabled with standard AZs
  • Backup
    • Data replication and backup as alternative to traditional backups
    • If required, use application-level technologies to perform backups of S3 bucket
  • Encryption, server-side
    • AED-256 encryption
  • Encryption, client-side
    • Applications are responsible for encrypting / decrypting data on S3
    • You can use any encryption algorithm and data will be stored in encrypted format

Protecting Data at Rest on Amazon EBS

  • Replication
    • 2 copies of EBS volumes are created for redundancy in the same AZ
  • Backup
    • Snapshots capture data stored at a specific point in time
  • Encryption: Microsoft Windows EFS
    • Use EFS (Encrypted File System) on Microsoft Windows Server
    • EFS provides transparent file and folder encryption
    • EFS integrates with Active Directory key management facilities and PKI
    • You can manage your own keys with EFS
  • Encryption: Microsoft / Windows Bitlocker
    • Volume encryption solutions supported from Windows Server 2008 upwards
    • Uses 128-bit / 256-bit encryption
  • Encryption: Linux dm-crypt
    • Transparent data encryption on EBS volumes and swap space
    • Can use Linux Unified Key Setup (LUKS) for key management
  • Encryption: Linux TrueCrypt
    • Third-party tool offering transparent encryption of data at rest on EBS
    • Supports Windows and Linux OSs
  • Encryption and Integrity authentication: SafeNet ProtectV
    • Third-party offering, allows full disk encryption of volumes and pre-boot authentication of AMIs
    • Provides data confidentiality and integrity authentication for data and the underlying OS

Protecting Data at Rest on Amazon RDS

  • Use cryptographic functions
    • MySQL cryptographic functions include encryption, hashing and compression
    • Oracle Transparent Data Encryption is supported on RDS for Oracle Enterprise Edition under the Bring Your Own License (BYOL) model: supports AES and Triple DES
    • Microsoft Transact-SQL data protection functions include encryption, signing and hashing
  • Platform level encryption keys would be managed at application level
  • SQL range queries are no longer applicable to the encrypted data
  • Use one-way hashing functions to obfuscate personal identifiers
    • HMAC-SHA1 converts personal identifier into fixed-length hash value
    • Personal identifier hashes are unique
    • Collisions in commercial HMACs are extremely rare

Protecting Data at Rest on Amazon Glacier

  • All data is protected using server-side encryption
  • Unique encryption key is generated for each archive, uses AED-256 encryption
  • Encryption key is encrypted with master key
  • Master key is rotated on regular basis
  • For additional protection, encrypt data before uploading to Amazon Glacier

Protection Data at Rest on Amazon DynamoDB

  • All user data is fully encrypted at rest on DynamoDB
  • Enhanced security encrypts all your data using encryptions keys stored in Amazon Key Management Services (AWS KMS)
  • Additional encryption options can be implemented on application-level

Protection Data at Rest on Amazon EMR

  • By default, EMR instances do not encrypt data at rest
  • AMIs are provided by AWS and you cannot use custom AMIs
  • AWS EMR clusters often uses S3 / DynamoDB as persistent data store
  • Data is copied to HDFS (Hadoop Distributed File System) when cluster is launched
  • Protection options:
    • Amazon S3 server-side encryption, no HDFS copy
    • Amazon S3 client-side encryption
    • Application-level encryption - entire file encrypted
    • Application-level encryption - individual fields encrypted / structure preserved
    • Hybrid - Combination of Amazon S3 server-side encryption and client-side encryption, and application-level encryption

Decommission Data and Media Securely

  • When deleting data storage blocks are marked as unallocated
    • the underlying physical media is not decommissioned
  • When block storage is provisioned, virtual machine manager (VMM) keeps track of which blocks the instance has written to
  • When writing the block of storage, previous block is zeroed and overwritten with your block of data
  • When reading, your previously stored data is returned
    • If the block has not previously written to, hypervisor zeros out the previous data on disk and returns a zero to the instance
  • When media reaches end of life, or on hardware fault, AWS destroys the data by following DoD (Department of Defense) or NIST (Guidelines for Media Sanitization) process
  • For more controls of securely decommissioning data, data encryption at rest with customer managed keys can help you protect the decommissioned data
    • Delete the keys used to protect the decommissioned data, making it irrecoverable

Protect Data in Transit

  • Data in transit: communication over public links (e.g. Internet)
  • Protect network traffic between clients and servers, and network traffic between servers

Concerns to communication over public links

  • Accidental information disclosure
    • Data should be encrypted when traversing public network
    • Solutions:
      • Use IPSec ESP and/or SSL/TLS
  • Data integrity compromise
    • Data integrity should not be compromised through deliberate or accidental
    • Solutions:
      • Authenticate data integrity using IPSec ESP/AH, and/or SSL/TLS
  • Peer identity compromise / identity spoofing / man-in-the-middle
    • Import to authenticate the identity of the remote end
    • Solutions:
      • Use IPSec with IKE with pre-shared keys
      • X.509 certificates to authenticate remote end
      • SSL/TLS with server certificate authentication based on CNAME or Alternative Name

Applications and Administrative Access to AWS Public Cloud Services

  • HTTP/HTTPS traffic (web applications)
    • Use HTTPS instead of HTTP with server certificate authentication
  • HTTPS offload (web applications)
    • SSL/TLS processing requires additional CPU and memory resources from both the web server and the client
    • Offload HTTPS processing on ELB
    • Offload HTTPS processing on CloudFront
  • Remote Desktop Protocol (RDP) traffic
    • RDP connections use SSL/TLS connection by default
    • Windows server should be issued a trusted X.509 certificate to protect from identity spoofing or man-in-the-middle attacks
    • By default, RDP servers use self-signed certificates, which are not trusted, and should be avoided
  • Secure Shell (SSH) traffic
    • SSH tunneling can be used to run X-Windows on top of SSH and protect application session
    • Use SSH version 2 using non-privileged user accounts
  • Database server traffic
    • Most databases support SSL/TLS wrappers
    • RDS supports SSL/TLS in some cases

Protecting Data in Transit when Managing AWS Services

  • AWS Management Console uses SSL/TLS to protect AWS service management traffic
  • The client browser authenticates the identity of the console service endpoint using an X.509 certificate
  • AWS REST APIs, accessible via SDKs or CLI also use SSL/TLS

Protecting Data in Transit to Amazon S3

  • S3 is accessed over HTTPS
  • SSL/TLS secure connection is established between client browser and console / endpoint
  • All subsequent traffic is protected within this connection

Protecting Data in Transit to RDS

  • Use SSL/TLS, when connecting to RDS over the Internet
  • SSL/TLS provides peer authentication via server X.509 certificates, data integrity authentication and data encryption for the client-server connection
  • SSL/TLS supported from RDS MySQL and Microsoft SQL instances
  • Self-signed certificate can be downloaded and designated as trusted to prevent man-in-the-middle or identity-spoofing attacks
  • Same self-signed certificate is used for all MySQL instances and another for all Microsoft SQL instances
    • Peer identity authentication does not provide individual instance authentication
    • For individual server authentication via SSL/TLS, use EC2 and self-managed relational database services

Protecting Data in Transit to Amazon DynamoDB

  • If connected from the same region, you can rely on AWS network security
  • If connected across the Internet, use HTTPS

Protecting Data in Transit to Amazon EMR Communication Paths and Protection Approaches:

  • Between Hadoop nodes
    • Communicate over TCP connections
    • Are located in the same AZ and protected by security standards and physical infrastructure layer
    • No additional protection is required
  • Between Hadoop Cluster and Amazon S3
    • EMR uses HTTPS for data between DDB and EC2
  • Between Hadoop Cluster and Amazon DynamoDB
    • EMR uses HTTPS for data between S3 and EC2
  • User or application access to Hadoop cluster
    • Can access EMR clusters using SSH scripts, REST or protocols such as Thrift or Avro
    • Use SSL/TLS for Thrift, REST or Avro
  • Administrative access to Hadoop cluster
    • EMR administrators typically manage the cluster through SSH to the master node

Secure Your Operating Systems and Applications

  • Disable root API access keys and secret key
  • Restrict access to instances from limited IP ranges using Security Groups
  • Password protect the .pem file on user machines
  • Delete keys from the authorized_keys file on your instances when someone leaves your organization or no longer requires access
  • Rotate credentials (DB, Access Keys)
  • Regularly run least privilege checks using IAM user Access Advisor and IAM user Last Used Access Keys
  • Use bastion hosts to enforce control and visibility

System hardening standards include:

  • Center for Internet Security (CIS)
  • International Organization for StandardizatioN (ISO)
  • SysADmin Audit Network Security (SANS) Institute
  • National Institute of Standards Technology (NIST)

Creating Custom AMIs

  • You can create custom AMIs and publish for private / public use
  • Published AMIs should meet your business needs and doesn’t violate the AWS Acceptable Use Policy

Clean-up Tasks before Publishing an AMI

  • Disable insecure applications
    • Disable services and protocols that authenticate users in clear text over network, or otherwise insecurely
  • Minimize exposure
    • Disable non-essential services on startup
  • Protect credentials
    • Securely delete all AWS credentials from disk and configuration files
    • Securely delete any third-party credentials from disk and configuration files
    • Securely delete all additional certificates or key material from the system
    • Ensure that software installed does not use default internal accounts and passwords
  • Use good governance
    • Ensure that the system does not violate the AWS Acceptable Use Policy (e.g. open SMTP relays or proxy servers)

Securing Linux/UNIX AMIs

  • Secure services
    • In sshd set PublickeyAuthentication to Yes and PasswordAuthentication to No in sshd_config
    • Generate unique SSH on instance creation. cloud-init handles this automatically.
  • Protect credentials
    • Remove and disable passwords for all user accounts so that they cannot be used to login and do not have a default password. Run passwd -l <username> for each account
    • Securely delete all user SSH public and private key pairs
  • Protect data
    • Securely delete all shell history and system log files containing sensitive data

Securing Windows AMIs

  • Protect credentials
    • Configure EC2 Config Service to randomly generate password for the Administrator account upon boot
    • Make sure all user accounts have randomly generated passwords
    • Ensure that the Guest account is disabled
  • Protect data
    • Clean the Windows event logs
  • Protect credentials
    • Make sure the AMI is not a part of a Windows domain
  • Minimizing exposure
    • Do not enable any file sharing, print spooler, RPC, and other Windows services that are not essential but are enabled by default

Bootstrapping

  • Use Puppet, Chef, Capistrano, Cloud-Init and Cfn-Init
  • Security software updates install the latest patches, service packs and critical updates beyond the patch level of the AMI
  • Initial application patches install application level updates, beyond the current application level build as captured in the AMI
  • Contextual data and configuration enables instances to apply configurations specific to the environment in which they are being launched-production, test or DMZ/internal, for example
  • Register instances with remote security monitoring and management systems

Managing Patches

  • You are responsible for patch management for your AMIs and live instances
  • Implemented processes to identify new security vulnerabilities and assign risk rankings to them

Protecting Your Sustem from Malware

  • Any software executed should be trusted
  • If system has executed an untrusted program, the system on which it was executed can no longer be trusted
  • Malicious code can change parts of the OS, install a rootkit, or establish back doors for accessing the system

Common approaches to Malware Protection

  • Untrusted AMIs
    • Use trusted AMIs only
    • Standard Windows and Linux AMIs provided by AWS and AMIs from trusted thrid parties
  • Untrusted Software
    • Only install software from a trusted software provider
    • Trusted software providers often sign the software using code-signing certificates or MD5/SHA-1 signatures of their products
  • Untrusted software depots
    • Set up your own software depots of trusted software for you users to install and use
    • Strongly discourage users from the dangerous practice of downloading and installing software from random sources on the internet
  • Principle of least privilege
    • Give users minimum privileges they need to carry out their tasks
  • Patching
    • Patch external-facing and internal systems to the latest security levels
  • Botnets
    • Infection might carry a code that creates a botnet - a network of infected hosts that can be controlled by a remote adversary
  • Spam
    • Infected systems can be used to send spam. AWS provides controls on how much email an EC2 instance can send. Avoid SMTP open relay.
  • Antivirus /Antispam software
    • Use reputable and up-to-date antivirus and antispam solution on your system
  • Host-based IDS software
    • Host-Based IDS software (e.g. open-source OSSEC software)
    • Includes integrity checks and rootkit detection software
    • Analyze important system files and folders and calculate checksum that reflect their trusted state

Mitigating Compromise and Abuse

  • AWS works with you to detect and address suspicious and malicious activities from your AWS resources
  • AWS uses the following mechanisms to detect abuse from customer resources:
    • AWS internal event monitoring
    • External security intelligence against AWS network space
    • Internet abuse complaints against AWS resources
  • Common causes of unintentional abuse activities:
    • Compromised resource - infected EC2 instance becoming a botnet agent
    • Unintentional Abuse - web crawler can eb classified as DOS attacker by some Internet sites
    • Secondary abuse - end user of application might post malware files on S3 bucket
    • False complaints - internet users might mistake legitimate activities for abuse
  • AWS abuse warning issued when AWS detects an abuse
  • Malicious, illegal or harmful activities that use your AWS resources may violate AWS Acceptable Use Polic
  • Can lead to account suspension
  • Best practices to respond to abuse incidents:
    • Never ignore AWS abuse communication
      • Reply to email to communicate with AWS abuse team and get help understanding the nature of the complaints
      • Respond to abuse warnings, take action to stop the malicious activities, and prevent future re-occurrence
    • Follow security best practices
      • Consistently adopt simple defense practices
      • Apply the latest software patches, restrict network traffic via a firewall and/or EC2 security groups
      • Provide least privilege access to users
    • Mitigation to compromises
      • Consider any known compromise AWS resource unsafe
      • Shutdown and rebuild the instance completely to get back to a safe state
      • Fresh re-launch can be the first mitigation approach
      • Carry out forensic analysis on a compromised instance to detect the root cause
      • Isolate infected instance to prevent further damage and infection during the investigation
      • Shutdown EBS volume and deliver it to security team to investigate
      • Always backup key business data to be able to recover
      • Review security control environment on the newly launched instances
    • Set up security communication email address
      • Choose a group email as a recipient for abuse-warning notifications
      • Adjust from Personal Information page, under Configure Additional Contacts

Using Additional Application Security Practices

  1. Always change vendor-supplied default before creating new AMIs or prior to deploying new applications, including passwords, SNMP community strings and security configuration
  2. Remove or disable unnecessary user accounts
  3. Implement a single primary function per EC2 - e.g. web server, db server, and DNS on separate servers
  4. Disable all non-essential services
  5. Disable or remove unnecessary functionality, scripts, drivers, features, EBS volumes and unnecessary web servers
  6. Use secure and encrypted protocols for communication over the plain text ones
  7. Introduce additional layers for plain text protocols, e.g. VPN
  8. Enforce security policies

Secure Your Infrastructure

Amazon VPC provides isolation from other customers and Layer3 isolation from the Internet.

Options for protecting your applications in Amazon VPC:

  • Internet-only
    • Encrypt application and administrative traffic using SSL/TLS or build VPN
    • Plan routing and server placement in public and private subnets
    • Use SGs and NACLs
  • IPSec over the Internet
    • Establish a private IPSec connection using IKEv1 and IPSec using standard AWS VPN facilities (AWS VPC VPN gateways, customer gateway and VPN connections)
    • Establish customer-specific VPN software infrastructure in the cloud, and on-premises
  • AWS Direct Connect without IPSec
    • Using private peering links, without the Internet
    • You might not need additional connection over private peering
  • AWS Direct Connect with IPSec
    • Use IPSec over AWS Direct Connect links for additional end-to-end protection
  • Hybrid
    • Use combination of approaches

Using Secure Zoning and Network Segmentation

Build network segments using the following access control methods:

  • Using Amazon VPC define an isolated network for each workload or organization entity
  • Using SGs manage access to instances that have similar functions and security requirements
  • Using NACLs allow stateless management of IP traffic
  • Using host-based firewalls to control access to each instance
  • Create a threat protection layer in traffic flow and enforce all traffic to traverse the zone
  • Apply access control at other layers (applications and services)

Security zone requires additional controls per network segment, and they often include:

  • Share Access Control - central Identity and Access Management system (IDAM)
  • Shared Audit Logging - shared logging for event analysis and correlation, and tracking security events
  • Shared Data Classification
  • Shared Management Infrastructure - various components, anti-virus/antispam systems, patching systems and performance monitoring systems
  • Shared Security (Confidentiality/Integrity Requirements) - considered in conjunction with data classification

Question to assess network segmentation and zoning requirements:

  • Do I control inter-zone communication? Can I use network segmentation tools to manage communications between security zones A and B?
  • Can I monitor inter-zone communication using an IDS/IPS/DLP/SIEM/NBAD system, depending on business requirements?
  • Can I apply per zone access control rights?
  • Can I manage each zone using dedicated management channel/roles? Role-Based Access Control for privileged access is a common requirement. You can use IAM to create different privilege levels.
  • Can I apply per zone confidentiality and integrity rules? Per zone encryption, data classification, and DRM simply increase the overall security posture.

AWS features to build isolated security zones/segments on AWS per Amazon VPC access control:

  • Per subnet access control
  • Per security group access control
  • Per instance access control (host-based)
  • Per Amazon VPC routing block
  • Per resource policies (S3/SNS/SMS)
  • Per zone IAM policies
  • Per zone log management
  • Per zone IAM users, administrative users
  • Per zone log feed
  • Per zone administrative channels (roles, interfaces, management consoles)
  • Per zone AMIs
  • Per zone data storage resources (Amazon S3 buckets or Glacier archives)
  • Per zone user directories
  • Per zone applications/application control

Strengthening Network Security

Best practices for AWS network security include:

  • Always use SGs
  • Augment security groups with Network ACLs
  • Use IPSec or AWS Direct Connect for trusted connections to other sites
  • Protect data in transit to insure the confidentiality and integrity of data
  • Design network security in layers. Apply network security at external, DMZ, and internal layers.
  • VPC Flow Logs provides further visibility.

Securing Periphery Systems: User Repositories, DNS, NTP

  • Use Amazon Route53 - Secure DNS service
  • For Internal DNS - implement custom DNS on EC2 instance

Controls for Custom Infrastructure Components (e.g. DNS)

  • Separate administrative level access
  • Monitoring, alerting, audit trail
  • NEtwork layer access control
  • Latest stable software with security patches
  • Continuous security testing (assessments)
  • All other security control processes in place

PCI DSS (Payment Card Industry Data Security Standard) approach to time synchronization

  • Verify that time-synchronization technology is implemented and kept current
  • Obtain and review the process of acquiring, distributing and storing the correct time within the organization
  • Verify that only designated time servers receive time signals from external sources and that time signals from external sources are based on International Atomic Time or Universal Coordinated Time (UTC)
  • Verify that the designated central time servers peer with each other to keep accurate time, and other internal servers receive time only from central time servers
  • Review system configurations and time-synchronization settings to verify that access to time data is restricted to only personnel who has a business need to access time data
  • Review system configurations and time synchronization settings and processes to verify that any changes to time settings on critical systems are logged, monitored and reviewed
  • Verify that the time servers accept time updates from specific, industry accepted external sources

Building Threat Protection Layers

Example of inline threat protection technologies:

  • Third-party firewall devices installed on Amazon EC2 instances (soft blades)
  • Unified threat management (UTM) gateways
  • Intrusion prevention systems
  • Data loss management gateways
  • Anomaly detection gateways
  • Advanced persistent threat detection gateways

Deploying threat protection layer technologies on AWS:

  • Support for Multiple Layers of Load Balancers
  • Support for Multiple IP Addresses
  • Support for Multiple 0Elastic Network Interfaces (ENIs)

Alternatives for inline threat management layer:

  • Distributed threat protection solution
    • Threat protection agents on individual instances in the cloud
  • Overlay network threat protection solution
    • Build an overlay network on top of Amazon VPC using GRE tunnels, vtun interfaces, or forwarding traffic on another ENI to centralized network traffic analysis and intrusion detection system, providing active or passive threat response

Test Security

  • External Vulnerability Assessment
  • External Penetration Tests
  • Internal Gray/White-box Review of Applications and Platforms

AWS Acceptable Use Policy

  • outlines permitted and prohibited behavior on AWS cloud
  • defines security violations and network abuse
  • supports both inbound and outbound penetration testing in the cloud
  • request a permission to conduct penetration tests
    • complete AWS Vulnerability Penetration Testing Request Form
    • AWS policy does not permit testing of m1.small or t1.micro

Managing Metrics and Improvements

  • Monitoring and reviewing procedures and other controls
  • Regular reviews of the effectiveness of the ISMS
  • Measure controls effectiveness
  • Risk assessments reviews at planned intervals
  • Internal ISMS audits
  • Regular management reviews
  • Update security plans

Mitigating and Protecting Against DoS & DDoS Attacks

  • AWS Premium Support services allows you to proactively and reactively involve AWS support in the process of mitigating attacks or containing ongoing incidents in your environment on AWS
  • DoS/DDoS on services sharing infrastructure (e.g. S3) will possibly affect multiple customers
    • AWS provides both mitigation and protection controls for DoS/DDoS on abstracted services from AWS
  • EC2 services use shared physical infrastructure
    • AWS does not provide mitigate or actively block network traffic affecting individual EC2 instances

Common approaches for DoS/DDoS mitigating and protection in the cloud

  • Firewalls: SGs, NACLs, Host-based Firewalls
  • Web Application Firewalls (WAF)
    • Deep packet inspection for web traffic
    • Platform and application specific attacks
    • Protocol sanity attacks
    • Unauthorized user access
  • Host-based or inline IDS/IPS systems
    • All types of attacks
  • Traffic shaping/rate limiting
    • ICMP flooding
    • Application request flooding
  • Embryonic session limits
    • Detect considerable deviations from the norm in the number of half-open (embryonic) TCP sessions and drop any further TCP SYN packets from specific sources
    • TCP SYN flooding

Manage Security Monitoring, Alerting, Audit Trail and Incident Response

Security monitoring questions

  • What parameters should we measure?
  • How should we measure them?
  • What are the threshold for these parameters?
  • How will escalation processes work?
  • Where will data be kept?

What do I need to log?

  • Actions taken by any individual with root or administrative privileges
  • Access to all audit trails
  • Invalid logical access attempts
  • Use of identification and authentication mechanisms
  • Initialization of audit logs
  • Creation and deletion of system level objects

Log File Considerations

  • Log collection
    • OS, application, third-party/middleware agents collect log file information
  • Log transport
    • Transfer logs to the central location in a secure, reliable, and timely fashion
  • Log storage
    • Centralize log files form multiple instances to facilitate retention policies, analysis, and correlation
  • Log taxonomy
  • Log analysis/correlation
  • Log protection/security

Privilege escalation gateway

  • Centralize all access to the system via a single (clustered) gateway
  • Automated password management for privileged access
    • Access control systems can rotate passwords and credentials based on given policies automatically using built-in connectors
  • Regularly run least privilege checks using AWS IAM and Access Advisor
  • User authentication
    • Common approach is using token-based authentication for the website and acquiring click-through access to other systems allowed in the user’s profile
  • Tamper-proof audit trail storage of all critical activities
  • Different sign-on credentials for shared accounts
  • Restrict leapfrogging or remote desktop hopping by allowing access only to target systems
  • Manage commands that can be used during sessions
  • Provide audit trail for terminals and GUI-based sessions for compliance and security-related purposes
  • Log everything and alert based on given threshold for the policies

Using Change Management Logs

  • Log all changes:
    • MACD - move/add/change/delete
    • ad hoc changes
    • unexpected changes, i.e. incidents
    • infrastructure changes
    • gold image/application inventory changes
    • process and policy changes
    • documentation changes
    • logging faults, software or component failure
      • faults should generate alerts, and then you should use event analysis and correlation techniques to determine the cause of the fault and whether it should trigger a security response
  • Correlate and interconnect change management and log management systems
  • Regular users should not have privileges to manage logs

Log Entry Information

  • User identification information
  • Type of event
  • Date and timestamp
  • Success or failure indication
  • Origination of event
  • Identity or name of affected data, system component, or resource

Protecting Log Information

Common controls for protecting log information

  • Verifying that audit trails are enabled and active for system components
  • Ensuring that only individuals who have a job-related need can view audit trail files
  • Confirming that current audit trail files are protected from unauthorized modifications via access control mechanisms, physical segregation and/or network segregation
  • Ensuring that current audit trail files are promptly backed up to a centralized log server or media that is difficult to alter
  • Verifying that logs for external-facing technologies are offloaded or copied onto a centralized internal log server or media
  • Using file integrity monitoring or change detection software for logs by examining system settings and monitored files and results from monitoring activities
  • Obtaining and examining security policies and procedures to verify they include procedures to review security logs at least daily and that follow-up to exceptions is required
  • Verifying that regular log reviews are performed for all system components
  • Ensuring that security policies and procedures include audit log retention policies and require audit log retention for a period of time, defined by the business and compliance requirements