AWS Security services

AWS provides a set of security services - to enable data security & ensure safety & integrity across architecture components. This includes hardware infrastructure (physical security), network security, application & data security.

Shared responsibility model & principle of least privileges are to be well understood by users (service consumers) in order to effectively implement security measures on the cloud & in the cloud (customer-managed service components); 

• Cloud adoption framework (CAF) whitepaper provides guidance for organizations considering to migrate their existing workload onto cloud OR start a new greenfield project - addressing various perspectives; 
• CAF security perspective whitepaper organizes security core capabilities - IAM, detective control, infrastructure security, data protection & incident response;

----------------------------------------------------------------------------------------------------------------------

Types of directory services for security

• AWS Cloud Directory services (best for hierarchical data)
• to share & control access to hierarchical data b/w apps
• Amazon Cognito (best for consumer apps / SaaS)
• available as a shared service
  
• login & authentication + authorization (with security groups)
• scales up to millions of users
• identity federation service with social identity providers e.g. facebook / google sign-in
•  identity broker service between application & Web ID providers
• authenticated users are provided with temporary credentials which map to "IAM Role", allowing access [authorize] to the required resources
• authentication token tat's generated is called "JSON Web Token" (JWT)
  
• AWS Directory services for Microsoft AD
• fully managed AWS AD services
• best for fully managed AD / hosted Microsoft AD solutions
• AD Connector
• this connects / allows on-premises users to login to AWS services with their existing AD credentials
• provides sign-in for on-premises employees into AWS domain to create EC2 instances
• supports MFA via existing RADIUS based MFA infrastructure
• can integrate with IAM roles via security groups to authenticate on-premises users
• Simple AD
• basic AD built using Samba
• supports user accounts, groups, policies & domains
• MFA is NOT supported
• Kerberos based SSO
• No trust relationships

----------------------------------------------------------------------------------------------------------------------

Simple token service (STS) - provides short term credentials for users to access AWS services;

STS is used to "assume a role"

• define IAM role within your / cross account
• define which principles can access IAM role
• use STS to retrieve credentials and impersonate the IAM role (AssumeRole API)
• credentials are valid between 15 mins to 60 mins
  

In order to revoke active sessions & credentials for a role, add a policy using a time statement - AWSRevokeOlderSessions; when providing access to AWS accounts owned by 3rd parties, outside of your zone of trust, use "IAM access analyzer" to find out which resources are exposed;

 

Important APIs with STS:

• AssumeRole - access a role within your account or cross account
• AssumeRoleWithSAML
• AssumeRoleWithWebIdentity
• GetSessionToken - for MFA from an user OR AWS account root user
• GetFederationToken
  

Policies - AWS-managed, customer-managed & inline policies

• use to specify 'allow' or 'deny' rules on AWS services / objects
• can be managed centrally via AWS IAM services OR creating inline policies specific to AWS service
• "NotAction" can be used in order to avoid "Deny All" policy
• Explicit "Deny" with "Action" will override "all other allow statements"
• "NotAction" can limit access to only the required resources with explicit "allow"
• policy definition format - Condition: {"condition operator": "condition-key: condition-value"}
• operators --> String, numeric, date, boolean condition, IpAddress, ArnEquals, Arnlike
  

----------------------------------------------------------------------------------------------------------------------

AWS Resource Access Manager (RAM) - used to separate concerns -- across admin, billing, accounts, etc.

• AWS RAM is used to share resources across multiple accounts within an organization
• AWS RAM is very useful to share resources across multiple teams OR groups within an AWS organization
• by this, resources created within one account can be made accessible to another account
• resource sharing involves sending a request and accepting on the receiver end, only when both sides accept, resource is shared
  

AWS SSO feature supports SAML 2.0 authentication

• with this, users can authenticate against Microsoft AD / GSuite / similar identity providers
• context from the identity providers is then used to authenticate and grant access to AWS OUs [organization units]
• roles & policies can further be used to authorize authenticated users

 AWS Cognito pools - enable provide temporary AWS credentials to access AWS resources

• identity pools are used to grant access to users in the form on "IAM Role" and the "IAM Role" is further used to access AWS resources; 
• Cognito tracks the association between user identity and different devices they use
• Cognito synchronizes user actions across multiple devices; uses "Push synchronization" to push updates & synchronize user data across multiple devices
  

----------------------------------------------------------------------------------------------------------------------

AWS Kinesis - processes data in streams, and behaves as a transient data store --> default retention upto 24 hours, can be configured to retain upto 7 days of data

•  allows data to process thru shards - configuring optimal number of shards for best performance is a good choice
• kinesis firehose & kinesis video streams are couple of other services that Kinesis acn work with
• each shard is capable to ingest around 1000 records per second
• with a default limit of 500 shards, and can increase based on the requirement
• data of the order of 1MB is processed as streams
• each record consisting of partition key, sequence number actual data

Kinesis can analyze data / perform data analytics before data reaches a database / data warehouse; this means kinesis analyzes "live streams"; is a differentiator since no waiting until data gets stored to perform analytics

• KCL - Kinesis client library, used to read objects from data streams
  
• KPL - Kinesis producer library, used to write objects to data streams

Cloud Hardware Security Module (HSM) - FIPS 140-2 Level3 compliant

• manage keys with cloud HSM
  
• it's a single tenant multi-AZ cluster [unlike KMS, which is a multi-tenant shared service]
  
• it runs with industry standard APIs, no AWS specific APIs for Cloud HSM
• standards - PKCS11, Java Cryptography Extensions (JCE) & Microsoft Crypto NG (CNG)
• Cloud HSM operates in its own VPCcloud HSM projects into ENIs inside our EC2 cluster - from the cluster of its own

----------------------------------------------------------------------------------------------------------------------

 AWS Key management services (KMS) - is a secure key store offered by AWS - to manage encryption keys. KMS uses hardware security modules (HSM) to protect the keys. Cryptography details are documented in KMS cryptography details whitepaper.

•  KMS applied to IAM: resource-based access policies can be attached to customer-master keys (CMKs) --> key policies; using identity-based IAM policies, principle of least privileges can be realized granting granular access to KMS API calls in the account;
• KMS is a FIPS 140-2 Level2 service; FIPS 140 is a US security standard, FIPS 140 Level3 is an additional stringent security mechanism;
• KMS is ideal for S3 objects, database passwords, API keys stored in systems manager parameter store
• supports encrypt / decrypt data upto 4KB in size, hence not suited to encrypt objects
• In order to encrypt data > 4KB, we use Data Encryption Key (DEK)
• for data level encryption during transit, use DEK and not KMS, KMS adds additional encryption/decryption overhead
• using KMS for data level encryption adds overhead to reach out to KMS in addition to transmission --> uses DES instead
  
• key policies apply to specified resources, with an action, affected principal & conditions; use of kms:* in IAM policies are NOT recommended - given this beats the principle of least privileges;
• policies also apply across levels, hence a top-level "effect:deny" denies access to all principles except for those with explicit allow privilege specified
• key grants (CMK grants) - useful to allow user principles to access a CMK; 
• users with 'PutKeyPolicy' permission for a CMK can replace the key policy with a different policy of choice. 'Grants' are used to enable granular permissions;
• grants per key / per principal are subject to key limits - as defined on AWS;
• ensure retiring principal retires grant after use - to remain within service limits
  
• MFA - can be used on critical KMS API calls. This is an additional layer of security - accomplished with an additional statement in the key policy in the "Condition" section
• example: "Condition":{
  " NumericLessThan ":{"aws: MultiFactorAuthAge":"300"}
  }
  
• CMK auditing - integrates with Cloud Trail logging services; Cloud Watch for monitoring; events such as ScheduleKeyDeletion, PutKeyPolicy, DeleteAlias, DisableKey, DeleteImportedKeyMaterial can be enabled on cloud trial logs; CMK rotated / deleted events can be monitored on cloud watch
• key tags - used to correlate specific CMKs back to a business category (cost center / business category / application name / application owner); 
• key aliases - allows abstract key users away from the original key ID & key ARN; key aliases are region independent - hence can be used to refer keys across multi-regions; naming convention can be adapted to maintain an uniform standard;
  
• key aliases CANNOT BE USED inside policies - original key IDs should be used in KMS key policies, IAM grants & KMS grants
  

AWS offers 2 options to manage keys: customer-managed CMKs & AWS managed CMKs:

1. AWS-managed CMKs are created when server-side encryption of AWS resource is enabled
2. AWS-managed CMKs can only be used to protect resources within the specific AWS service where created; does not provide granular control;
3. AWS-managed CMKs cannot be deleted; they're rotated automatically once in 3 years
4. unlike AWS-managed CMKs, customer-managed CMKs can be deleted; can be controlled via KMS / IAM policy & can be rotated automatically / on-demand once a year
5. customer-managed CMKs lets upload custom cryptographic content OR create from cryptographic content via KMS

Common KMS use cases:

• implement PCI DSS compliant data encryption; with AWS-managed CMK - for payment card industry
• manage secrets with KMS & S3; implement granular controls; keys placed in KMS can be encrypted & managed using customer-managed KMS key; 
• invoke lambda functions securely - with managed keys stored in KMS; choice of AWS managed CMK v/s customer-managed CMK on KMS also applies to lambda functions;
• using systems manager parameter store - to store passwords, license keys & certificates is another alternative to protect sensitive information & automate system management tasks at scale; 
• enforcing data-at-rest encryption in S3, EFS, EBS or RDS - data inside cloud storage volumes are encrypted with the managed-keys stored in KMS; applies to back-up volumes, snapshots, read-replicas, archived data storage, etc.;
  
• manage & control key life-cycle policies - rotation (creation & deletion); configure relevant alerts via AWS cloud watch alarms & capture audit logs via AWS cloud trail

----------------------------------------------------------------------------------------------------------------------

Systems Manager Parameter Store - it's basically used to store your parameters used to connect to database, passwords, connection strings, etc. for different environments; parameter store allows you to organize parameters by folder structure OR hierarchy [upto 15 levels in depth];

 

Secrets Manager - has the ability to automatically rotate secrets

• it can automatically rotate keys in RDS
• secrets manager generates random secrets - good for programmatic access
  

AWS Shield - consider shield for DDoS attacks; available in 2 tiers --> Standard & Advanced;

Shield "standard" is good for layer3 & layer4 attacks, SYN/UDP floods, reflection attacks

available at no additional cost

Shield Advanced cost $3000/month/AWS Organization

• enhanced protection for EC2, ELB, CloudFront, Global Accelarator, Route 53
• business & enterprise customer support 24X7 -- DDoS Response team (DRT)
• DDoS cost protection - insurance in case of an attack
  

Web-application firewall (WAF) rules

• "allow all" requests, except those specified to deny
• "block all" requests, except those specified to allow
• "count" requests, matching properties that you specify
• properties = originating IP address, originating country, request size, values in request header, strings in request matching "regex";
• SQL INJECTION can be blocked using WAF
• also "Cross-site" scripting (XSS) requests can be blocked by WAF

AWS Firewall manager - it's tightly integrated with AWS WAF; allows to centrally configure & manage firewall rules across an AWS organization

----------------------------------------------------------------------------------------------------------------------
 

Incident response management - incident responses involve: directive controls, detective controls, responsive controls & preventive controls; principal foundation for incident response - educate, prepare, simulate & iterate;

• incident responses follows an evolving lifecycle, similar to development; common incidents can be tracked, categorized & automated - to handle recurring incidents; AI & ML can be applied to automate incident responses - however, to be dealt with care --> precisely when human intervention is needed;
  
• learning from known incidents; applying learning to avoid similar threats in the future is a related focus area for incident response management; threat intelligence & reducing attack surface area play a key role;
  
• utilizing computing & shared services on the cloud - for earlier detection of possible attack surfaces; fast troubleshooting & incident resolution are the key focus areas (also as per NIST design goals)
  
• incident domains - application, infrastructure & service domains
• incident response team should be trained to use tools for logging, tracking, auditing & event / alert responses: ELK stack, Kinesis for real-time streaming analytics, Redshift, Macie, QuickSight, AWS Glue, Amazon Sagemaker, etc.
  
• indicators / detection of cloud security events - logs & monitors [AWS Guard Duty, Amazon Detective, AWS Security Hub, Amazon Macie, Route 53 health checks & Cloud Watch alarms], billing activity (sudden change), threat intelligence, partner tools [security partner solutions / security marketplace], AWS Outreach, etc.

----------------------------------------------------------------------------------------------------------------------

Infrastructure security

• network security via NACLs & security group configuration; secure API endpoints to allow only HTTPS - with transmission protection over SSL; URL whitelisting at the network layer inbound, filtering rules; restrict communication protocol access over allowed ports;
  
• AWS GovCloud is an isolated region to allow US government agencies migrate workload onto cloud - adhering to regulatory & compliance requirements;
• monitor network ingress & egress - network usage & port scanning for application usage & unauthorized access; 

Tagging & Resource Groups

• use tags for cost allocation, security, automation, across all resources
• up to 50 tags is permitted for most of the resource types in AWSusing tags - name / value pairs can help you easily analyze resource usage statistics, compare costs across different departments in an organization,
• sum up overall costs at an account level, etc.
• also useful in automation & security rule settings --> to control access and categorize by tags
• standards enforcing can be done by tags
• e.g. set AWS Config rules to delete EC2 resources not properly tagged

Resource groups

• based of the tags created, we can combine resources into different groups
• custom consoles, metrics & alarms + configuration details can be specified for "resource groups"

 NACL & host-based firewall - Host-based firewall can be configured on EC2 instances; they serve as an additional layer of control in addition to NACL

In order to effectively implement security mechanism use:

• NACL - for layer4 security, with allow/ deny rules, with specific IP ranges - so as to block malicious requests
• WAF - for layer7 security, can be used with ALB / CloudFront distributions...WAF's IP blocking & filtering configuration limits access to users on public internet
• Security groups - stateful explicit 'allow' rules, to allow whitelisted traffic into your public & private subnet(s)

----------------------------------------------------------------------------------------------------------------------