AWS Security Best Practices

AWS Security Best Practices

https://d0.awsstatic.com/whitepapers/Security/AWS_Security_Best_Practices.pdf  ( Aug2016)

Key Topics about AWS Security - Synopsis
___________________________________________________________________________
AWS Shared responsibility model:
- Global. Model for Infrastructure service, Container service and Abstracted service. Trusted advisor tool.  

Define and categorize assets on AWS
- Asset name, owner, category(essential, network, software),dependency, cost.

Design your ISMS to protect your assets on AWS.
- Standards for implementing,operating, monitoring, reviewing,maintaining and improving ISMS.  

Manage AWS accounts, IAM users, groups and  roles.
- Multi accounts, 2 type sign in credentials, delegation, temp credentials, roles for EC2,cross-account, federatiojn

Managing OS level access to Amazon EC2 instances.
-SSH,RDP. EC2 Key pair auth  for specific instance( diff from AWS a/c or IAM cred ), Open SSL or AWS keys.

Secure your Data.
-User Resource policy-when and how? User Capability policy- when and how? Encryption key mngnt. HSM,

Securing Data at Rest.
- 4 Concerns, Approach and Strategy. Features  of AWS (S3,EBS, EFS,)for data at rest protection.Decommission

Securing data in Transit.
- 3 Concerns, protection. IPSec, SSL/TLS. Data traveling to 1)storage 2)various AWS services and management.

Securing operating system and  applications.
- Custom AMI,Bootstrapping,Patches,Malware, compromise and abuse, Application security,bastion host.
  
Securing the infrastructure 
- VPC,Sec Zoning, NW Segmentation,  NW security, Secure periphery Systems,TPLayers, Test Sec, DDOS

Manage monitor,alert, Audit trail,Incident Response
- Questions: Monitor what, log what, change management logs, protect log info, Logging faults
_______________________________________________________________________________


Key Topics about AWS Security - Details


AWS Shared responsibility model:
- Global. Model for Infrastructure service, Container service and Abstracted service. Trusted advisor tool.  
http://cloudacademy.com/blog/aws-shared-responsibility-model-security/
E.g. In Shared responsibility model of Infrastructure as service with EC2 as an example, AWS manages security for 1,2,3,4...... Customer manages security for 1,2,3,4,5....
Understanding secure Global AWS Infrastructure: 1. Using IAM service. 2 Regions, AZs and end points.  Use Regions for regulatory compliance and network latency. Data in a region is not automatically replicated outside of it. AZs meant for fault isolation. They are connected to multiple internet providers and different power grids. AZs in the same regions are interconnected using high speed LANs. Service end points are managed by AWS.
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/UsingIAM.html
Infrastructure Services: Compute(EC2) and related services (EBS, Auto Scaling, VPC ). You control the OS and you configure and operate any identity management system that provides access to the user layer of the virtualization stack. 
Container Services: You don't manage the OS or the platform layer. AWS provides a managed service for the application "containers". E.g RDS, EMR, Elastic Beanstalk. 
Abstracted Services: E.g SQS, S3, Dynamo, SES. You access end points of these using APIs. 

1. Shared Responsibility  Model for Infrastructure Service.

Mostly talks about EC2 , Key pairs, Authentication, IAM roles, Bootstrapping, LDAP, AD

2. Shared Responsibility  Model for Container  Service.

3. Shared Responsibility  Model for Abstracted  Service.

Trusted Advisor Tool : For some premium support plans. This tool identifies security misconfigurations, suggest performance improvement tips, reports on under utlized resources. On security TA checks for compliance of the following - a)limited access to common admin ports, b) limited access to common db ports c) IAM configured to ensure secure access control of AWS resources.



Define and categorize assets on AWS
- Asset name, owner, category(essential, network, software),dependency, cost.

Design a financially and technically viable solution after proper categorization of all the assets.
Assets fall in to two categories 1) Essential ( business information, processes and activities ) or 2) Components supporting essential elements ( hardware, software, personnel, sites, partner organizations ).

Design your ISMS to protect your assets on AWS.
- Standards for implementing,operating, monitoring, reviewing,maintaining and improving ISMS.  

ISMS design depends on a)business needs and objectives b) processes employed c) size ans structure of the organization.  A frame work such as ISO 27001 may also help.  Phased approach is better.
9 phases : Define Scope, Define ISMS Policy, Select risk assessment methodology, identify risks, analyze and evaluate risks, address risks, choose security control frameworks, get management approval, statement of applicability. Best practice to assign roles to groups and assign users to groups.



Manage AWS accounts, IAM users, groups and  roles.
- Multi accounts, 2 type sign in credentials, delegation, temp credentials, roles for EC2,cross-account, federation

AWS Account : The one with root permissions. Use this to create IAM accounts.
IAM Users: IAM users can be a person, service or application that needs access to your AWS resources through management console, CLI or via API.

Strategies for Using Multiple AWS Accounts :
Single : Centralized security
Three : Prod, QA, Dev.
Multi : Autonomous Depts
Multi : Central for common ( DNS. AD , CMS etc ) separate for projects.
Billing consolidation possible.

Managing IAM Users:
IAM users with certain credentials can create other IAM users.
Managing IAM Groups:
Collection of IAM users in one AWS account. Group is given permission to access AWS resources by assigning one or more IAM policies. E.g
It is better to provision user access via group memberships as well as permissions and policies assigned at group level.

Managing AWS Credentials:
Two Types of Credentials : 1) Used for management console sign-in access (user name / password )  2) For programmatic access ( Access keys ).

User name / password : Email address.
Access keys : Used to digitally sign API calls made to AWS services.  Access Key ID and Secret key combination.

Understanding Delegation using IAM roles and  Temporary Security credentials:
Scenarios where you want to delegate access to users or services that normally don't have access to AWS resources.

Three use case scenarios:
1)Applications running on EC2 ( e.g application accessing S3)
2)Cross account access ( Separate PROD and DEV AWS account. Want to access each other )
3)Identity Federation ( Users already in LDAP, AD etc, )

Temp roles are programmatically assumed by the party ( application/user ) accessing an AWS resource. These temp roles have configurable expiration ad are rotated.

IAM Roles for EC2:

Identity Federation:

Managing OS level access to Amazon EC2 instances.
-SSH,RDP. EC2 Key pair auth  for specific instance( diff from AWS a/c or IAM cred ), Open SSL or AWS keys.

 How do I add new user accounts with SSH access to my Amazon EC2 Linux instance?
https://aws.amazon.com/premiumsupport/knowledge-center/new-user-accounts-linux-instance/
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html#having-ec2-create-your-key-pair

Add a new user from the EC2 Linux instance command shell

Create a key pair for each new user account that you add to your instance

Configure a new user account on the EC2 Linux instance to use the public key from the key pair

Update the authorized_keys file with the public key

Verify that you can use SSH to connect to your instance



Secure your Data.
-User Resource policy-when and how? User Capability policy- when and how? Encryption key mngnt. HSM,

Resource Authorization:
After authentication of a user or an IAM role , resource authorization is provided using resource policies or capabilities policies , depending on ....
Resource policies : Policy is attached to a resource and describes who can do what with the resource.
Capability policies : ( "user based permissions" ) are used to enforce company wide policies. Assigned to users directly or through group, or through a role.

Storing and managing encryption keys in the cloud:
AWS Key management and storage  services.
AWS Cloud HSM ( Hardware Security Module )
DRM, PKI, Luna SA HSM from SafeNet,
When you sign up for Cloud HSM you get dedicated single tenant access to cloud HSM appliance. It appears as a resource in VPC. You, not AWS manage the cryptographic domain of Cloud HSM. Domain is a physical and logical security boundary that limits access to security keys.

Securing Data at Rest.
- 4 Concerns, Approach and Strategy. Features  of AWS (S3,EBS, EFS,)for data at rest protection.Decommission

Four Data Security Concerns :
1. Accidental Information Disclosure
2. Data Integrity Compromise.
3. Accidental Deletion.
4. System, infrastructure, software or hardware availability.

Common Strategies to address above concerns:
1.Permissions
2. Encryption ( File, partition, volume or application-level )
3. Data integrity checks ( MAC/HMAC/Digital sign, ) , Backup, Versioning.
4. MFA Delete
5. Backup replication.

How S3 security features protects data at rest.
1.Permissions
2. Versioning
3.Replication
4. Backup
5.Encryption Server-side
6. Encryption client side

How EBS  security features protects data at rest.
1. Replication
2, Backup
3. Encryption ( different OS )
4. Bitlocker, TrueCrypt, SafeNet

How RDS  security features protects data at rest.

Additional protection can be added at the platform layer using SQL cryptographic functions. Protection can be added at application layer by encrypting all fields and using application key.
MySQL DB level example:

INSERT INTO Customers(CustomerFirstName,CustomerLastName)

VALUES

(AES_ENCRYPT('John',@key),AES_ENCRYPT('Smith',@key); 

 

Impact on range queries.
Different DBs have different methods.
In all regions AWS supports Transparent Data Encryption and Native Data Encryption.

HMAC and SHA1 one way hashing can be employed.

How Glacier   security features protects data at rest.
All data on Glacier is protected using server side encryption. AES256. Uniue keys used for each archive. Keys are again encrypted using AES256 and  a master key and this key is stored in secure location.

How Dynamo security features protects data at rest.
Dynamo is a shared service. You can add a data encryption layer over the standard Dynamo DB service - similar to RDS data protection at application layer. When storing encrypted fields in Dynamo DB, it is a best practice to use raw binary fields or Base64-encoded string fields.

Protecting Data at rest on EMR.
EMR is a managed service in the cloud. By default EMR instances do not encrypt data at rest. EMR clusters either use S3 or Dynamo DB as the data store. For higher level security you can employ several techniques like 1) S3 server side encryption, 2) S3 client side encryption, 3) application level encryption  - entire file 4) application level encryption - individual fields. 5) Hybrid

Decommissioning Data and Media securely :
Done differently than on premise.
When you ask AWS to delete data on the disk, AWS doesn't de commission the underlying media, it actually marks the blocks unallocated.  AWS uses secure mechanism to re allocate blocks elsewhere. Hypervisor zeros out previous data when the new instance owner tries to read. At the end of life AWS truly decommissions a media. When there is a regulatory compliance requirements, the keys of encrypted data are destroyed as well.

Securing data in Transit.
- 3 Concerns, protection. IPSec, SSL/TLS. Data traveling to 1)storage 2)various AWS services and management.

This is about protecting network traffic between server and client as well as between servers.

Concerns to public network communication:
1.Accidental information disclosure. ( Encrypt data in transit using IPSec ESP or SSL/TSL )
2, Data integrity compromise ( Authenticate using IPSec ESP/AH or SSL/TSL )
3. Man in the middle, spoofing, ( IPSec with IKE, X.509 certificate , Server certificate CN )

IPSec is a protocol that extends IP protocol stack in the network infrastructure. SSL/TLS operates on session layer.

Managing Application and Administrative Access to Public Cloud Services:  
1. Use HTTPS ( HTTP over SSL/TLS )
2. RDP
3. SSH

Protecting Data in Transit when managing AWS Services:
AWS management console uses SSL/TLS beteen clinet browser and console service end points. AWS APIs are REST over HTTPS. 

Protecting Data in Transit to S3
S3 is accessed over HTTPS.

Protecting Data in Transit to RDS
If Instance and RDS in same Region AWS network and secure. If connecting to RDS over internet use SSL/TLS.  SSL/TLS provides peer authentication via server X.509 certificates. Supported now for MySQL and Microsoft SQL. For Oracle it is Native Network Encryption based on AES or triple DES.

Protecting Data in Transit to Dynamo DB
Us HTTPS for connecting to Dynamo DB over internet.

Protecting Data in Transit to EMR
EMR involves separate application communication paths each of which needs separate data protection mechanism. These are
1. Between Hadoop nodes -
2. Between Hadoop cluster and S3
3. Between Hadoop cluster and Dynamo DB
4. Usr or application access to Hadoop cluster
5. Administrative access to Hadoop cluster


Securing operating system and  applications.
- Custom AMI,Bootstrapping,Patches,Malware, compromise and abuse, Application security,bastion host.

Some recommendations: 1) Disable root API access key and secret key 2) IP range limit using security groups 3) password protect .pem files on user machines 4)Delete keys from the authorized_keys file when some one leaves the org or no more need access 5) Rotate acess keys ( DB / Access keys ) 6) Regularly run lease privilege checks using IAM User Access Advisor and IAM user Last Used Acces Keys. 7) Use bastion hosts to enforce control and visibility. 

Many institutions giving guidelines on hardening : CIS, ISO, SANS, NIST
If a published AMI is found vulnerable AWS will pull it out.

Creating Secure Custom AMIs As a publisher of AMI you are responsible for the initial security posture. The security controls you apply on an AMI are effective at a specific point in time, they are not dynamic. Set up private AMI any whay you want . But Public AMIs should meet certain recommendations as users need not be security experts.
1. Disable insecure applications
2. Minimize exposure on start up.
3. Protect credentials : delete AWS credentials, third party credentials, certifictes or key materials,   from disk and config files
4. Protect credentials : Make sure software installed doesn't use default credentials
5. Use good governance ; Adhere to TOS of AWS ( No proxy server , no open SMTP relaying )
6. Secure services : generate unique SSH host  key for instance
7. Secure services : Configure sshd to allow only pubkey authentication and no passowrd authentication.
8. Protect credentials : Remove and Disable all default user passwords, ssh public and private ssh public and private key pairs.
9. Protect data : delete all shell history and log file data containing sensitive data.

Bootstrapping:
After a hardened AMI is instantiated you still can amend security by bootstrapping either by using custom bash scripts or Window power shell or by using applications like Chef or Puppet.
Some bootstrapping actions to consider are : 1)Security software updates install the latest patches ,service packs, and critical updates, beyond patch level of AMI, 2) Initial application patches and updates  3) Contextual data and configuration ( test/dev/prod dmz ) 4) Register instance with remote security monitoring and management systems.

Managing patches :
You are responsible for patch management. Check with vendor list of all components you are using.

Controlling security for public AMIs:
Make sure your AMI doesn't have any credentials on it when you are sharing it.

Protecting your system from malware:  ( Viruses, worms, trojans, botnets and spam )
If you execute a piece of untrusted  code on your system, it is not your system any more. The code assumes or even spoofs the identity of another or super user.

Some common approaches to malware protection factors: 
Untrusted AMIs, Untrusted software, Untrusted software depots, principle of least privilege, patching, botnets, spam, antivirus software, host based IDS software,


Mitigating compromise and abuse:
AWS customers should not abuse  the broader internet resources. Abuse activities are externally observed behavior of AWS customer's instances or other resources that are malicious, offensive, illegal or could ham other internet sites.
AWS deploys many methods to monitor abuse activities. However, Common causes of un intentional abuse activities involve:
Compromised resources: ( un patched EC2 becoming botnet agent )
Un intentional abuse : ( overly aggressive web crawler classified as DOS )
Secondary abuse : (An AWS User's user id posting malware on S3 bucket )
False complaints  : (Internet users mistaking legitimate activities for abuse )

AWS security warning.
AWS acceptable use policy
Best Practices to respond to abuse incidents: Never ignore AWS abuse mails, follow security best practices, mitigation to compromises, set up security communication email address

Using additional Application Security Practices
Implement a single primary function per Amazon instance. Enable only necessary services on the instance.  Disable all un necessary features , drivers.
Use SSH for file transfer instead of FTP.


Securing the infrastructure 
- VPC,Sec Zoning, NW Segmentation,  NW security, Secure periphery Systems,TPLayers, Test Sec, DDOS

This section provides information about securing infrastructure services on the AWS platform. 

Using Amazon VPC
Using VPC you can create private cloud withing Amazon public cloud.
Can use private IP addresses within private cloud which are very restrictively routed to internet. It provides  Layer 3 ( Network Layer IP routing ) isolation from Internet as well as isolation from other cloud in the AWS.
Below Table shows options for protecting applications in Amazon VPC.

Concern       |  Description         |    Recommended Protection Approach


1. Internet Only : 
2. IPSec over internet : ( IPSec tunnels from customer on - premise to AWS end points )
3. AWS Direct Connect without IPSec : Private peering over dedicated links.
4. AWS Direct Connect with IPSec : For additional end to end protection
5. Hybrid : Combination of above.
( Refer VPC connectivity WP )




Using  a)Security Zoning and  2)Network Segmentation
It is a best practice to segment infrastructure in to Zones that impose similar security controls.

You can build your own overlay infrastructure components like VPC, subnets, routing tables, segmented/zoned applications, custom service instances like user repositories, DNS and time servers to supplement AWS managed cloud infrastructure. 


Security zoning and network segmentation are two different concepts. a) Network segment isolates one network from another b) a zone creates a group of system components with similar security levels with common controls. 


On AWS you can build network segments using the following access control methods:
a) VPC b)Security groups (stateful fire walls in both directions) c) NACLs for stateless  (agnostic to sessions ) management of IP traffic. Out side layer of security group. d)Host based fire walls e) threat protection layer in traffic flow f) applying access control at other layers ( applications and services )



Security groups are logical grouping of instances, and they also allow the enforcement of inbound and outbound traffic rules on these instances regardless of the subnet where instances reside.



Creating a security zone requires additional controls per network segment, and they often include:

a) Shared access control, b) Shared audit logging, c) Shared data classification, d) shared management infrastructure e) shared security requirements.





To assess your network segmentation and security zoning requirements answer the following questions :
- Do I control inter-zone communication?
- Can I monitor inter-zone communication?
- Can I apply per-zone access control rights?
- Can I manage each zone using dedicated management channel/roles?
- Can I apply per zone confidentiality and integrity rules?


AWS provides flexible security zoning options. Security engineers and architects can leverage the following 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 ( s3/ Glacier ), per zone user directories, per zone applications/application controls. 





Strengthening Network Security
You are responsible for controlling access to your systems in the cloud and for configuring network security within your VPC, as well as secure inbound and outbound traffic. IP address based filtered access to applications.
Best practice for network security on the AWS cloud include:
-Always use Security Groups. Can apply multiple SG to an instance.
- Augment SG with NACL.
- Use IPSec, Direct Connect or Virtual Gateway for remote VPC access
-Protect data in transit
- Design network security in layers.
-Use VPC Flow log to see IP traffic in and out of VPC



Securing Periphery Systems : User Repositories, DNS, NTP
All DNS Systems and other important custom infrastructure components should apply the following controls.
a) Separate administrative level access, b) Monitoring, alerting and trail, c) Network layer access control, d) latest stable software with patches, e) Continuous security testing f) all controls in place
It is important that a time server is maintained.


Building Threat Protection Layers
Many organisations consider a layered approach for network security. In AWS you can choose  combination of VPC, implicit firewall, SG, NACL, host based firewall, IDS/ISP systems to achieve this. While SG,NACL and host based FW suffice many customers, if you want security in depth you should go a for a defense in depth network level security control appliance. You should do this inline before traffic is forwarded to its final destination.

The following key features in the AWS VPC support deploying threat protection layer technologies.
- Support for multiple layers of load balancers
- Support for multiple IP addresses
- Support for multiple elastic network interfaces ( ENIs)

Latency and complexity sometimes prevent layered approach. In such cases you can
- A distributed threat protection solution. Agents are placed on individual instances and commonly monitored and coordinated.
- An overlay network threat protection solution - ( GRE tunnels, vtun,





Test Security
Verifying existing controls needs testing. AWS customers should take a number of test approaches.
- External vulnerability assessment
- External penetration testing
- Internal gray/white-box review of applications and platforms.
You must get pre approval before doing a penetration testing.


Managing Metrics and Improvement
Measuring control effectiveness should be an integral part of ISMS. 

Table shows measurement and improvement best practices.

- Monitor and review procedures and other controls
- Review effectiveness of ISMS
- Measure control effectiveness
- Risk assessment reviews
- Internal ISMS audits
- Management reviews
- Update security plans


Mitigating and  Protecting against DOS and DDOS attacks.
Mitigation techniques are similar to those used on premises. AWS recommends getting premium support if you think you are going to be a target of a potential DOS attack. On abstracted services like S3 AWS themselves give protection. On services such as EC2 AWS and customer need to work together. AWS uses proprietary techniques to mitigate and contain DoS/DDoS attack to its platform. In order not to interfere AWS will not block traffic to individual EC2 instance. Baseline and pattern and other spastics important to  trigger DOS attack behavior.

Table below highlights approaches for DOS mitigation and protection.
TECHNIQUE    |   DESCRIPTION      |    PROTECTION FROM DOS/DDOS ATTACK
1. Firewalls, NACLs, Security Groups, Host based firewalls
2. WAF - Provide deep packet inspection for web traffic
3. Host based or inline IDS/IPS systems: Use statistical models and signature based algos.
4. Traffic shaping / Rate limiting :  ( limits ICMP flooding )
5. Embryonic session limits : TCP SYN flooding. ( Detect half open sessions )
Elastic nature of AWS can work to the advantage in the event of DOS attack. Cloud absorbs that attack. You can also use CloudFront to absorb sustained attack. Ideal solution is a layered model.



Manage monitor,alert, Audit trail,Incident Response
- Questions: Monitor what, log what, change management logs, protect log info, Logging faults

Security monitoring starts with answering following questions.
1,2,3

Following areas are recommended for logging
1,2,3

When you design a log file keep the following considerations in mind
1,2,3,4,

To determine which log files to include answer following questions:
1,2,3




 Privilege escalation gateway to log at higher levels beyond that is provided by AWS. Privileged escalation gateway, you access system through a single clustered gateway. Proxies come in between. These gateways should provide:
Automated password management.
Regularly run least privilege checks
User authentication
Tamper-proof audit trail
different credentials for shared accounts
Restric leap frogging or remote desktop hopping
Manage commands
Provide audit trails for terminals and GUI based sessions
Log everything



Using Change Management Logs
By managing security logs you can also track  changes as part of change control process ( MACD Move ADD Change Delete ).  Type of changes. IDS ( Intrusion Detection Systems ), AAA (Autentication, Authorization and Accounting ) protocol servers for servers ( e.g RADIUS ) 


Managing change for Critical Transactions
For critical applications all MACD shouldbe logged with following information.
1,2,3.....

Protecting Log Inforamtion:
Common controls for protecting log information include the following.  
1,2,3,4....

Logging Faults:
Faults ( hardware/software or service ) also should be logged.

 
_______________________________________________________________________________