AWS Security best Practices

AWS Security Best practices

Security needs to be considered as one of the prime concern in every IT infrastructure. Its the primary role of the IT Administrator/Security specialist to secure their infrastructure in the best way he can. Everybody wants their organization IT infrastructure could be more secure. Most of the security professionals agree that it is not a matter of if you get breached, but it matters when. While security teams have been working to secure their infrastructure from any external attack. They are also accountable for addressing the risk of insider breaches. The truth is, the majority of organizations will face some sort of breach, whether it comes from external threat actors or insider threat.

Amazon Web Services provides a secure global infrastructure and services in the cloud. To design an ISMS (Information security management system) in AWS, you must first be familiar with the AWS shared responsibility model, which requires AWS and customers to work together towards security objectives. In this blog, we will be looking into the implementation of Security best practices on AWS Cloud platform.

AWS provides secure infrastructure and services, while you, customer, are also responsible for secure operating systems, platforms, and data. To ensure a secure global infrastructure, AWS configures infrastructure components and provides services and features you can use to enhance security, such as the Identity and Access Management (IAM) service, which you can use to manage users and user permissions in a subset of AWS services. To ensure secure services, AWS offers shared responsibility models for each of the different types of services.

Figure 1: Shared Responsibility Model for Infrastructure Services

Infrastructure services, such as Amazon EC2, Amazon EBS, and Amazon VPC, run on top of the AWS global infrastructure. They vary in terms of availability and durability objectives but always operate within the specific region where they have been launched. You can build systems that meet availability objectives exceeding those of individual services from AWS by employing resilient components in multiple Availability Zones.

AWS’s responsibility

Since it has little control over how AWS is used by its customers, Amazon has focused on the security of AWS infrastructure, including protecting its computing, storage, networking, and database services against intrusions. AWS is responsible for the security of the software, hardware, and the physical facilities that host AWS services. AWS also takes responsibility for the security configuration of its managed services such as Amazon DynamoDB, RDS, Redshift, Elastic MapReduce, WorkSpaces, etc.

AWS responsibility at a glance,

• Ensuring AWS and custom applications are being used in a manner compliant with internal and external policies

• Ensuring network security (DoS, MITM, port scanning)

• Configuring AWS Managed Services in a secure manner

• Providing physical access control to hardware/software

• Providing environmental security assurance against things like mass power outages, earthquakes, floods, and other natural disasters

• Database patching

• Protecting against AWS zero-day exploits and other vulnerabilities

• Business continuity management (availability, incident response)

Customer’s responsibility

AWS customers are responsible for secure usage of AWS services that are considered unmanaged. For example, while AWS has built several layers of security features to prevent unauthorized access to AWS including multifactor authentication, it is the responsibility of the customer to make sure multifactor authentication is turned on for users, particularly for those with the most extensive IAM permissions in AWS.

Customers responsibilities at a Glance,

• Preventing or detecting when an AWS account has been compromised.

• Preventing or detecting a privileged or regular AWS user behaving in an insecure manner.

• Preventing sensitive data from being uploaded to or shared from applications in an

  inappropriate manner

• Configuring AWS services (except AWS Managed Services) in a secure manner.

• Restricting access to AWS services or custom applications to only those users who require it.

• Updating Guest Operating Systems and applying security patches

• Ensuring AWS and custom applications are being used in a manner compliant with internal

  and external policies

• Ensuring network security (DoS, MITM, port scanning)

AWS provides multiple Services and the customers are using them according to their requirement to set up their complete IT infrastructure on Cloud. Based on the shared Security models, the threat is most likely from the customer’s end, it may be due to the lack of knowledge or can be anything. While setting up the IT infrastructure on Cloud, the consumers should take care of the multiple parameters (Security Best practices) mention in this blog. We can also find out the threats to infrastructure by using few services and use of AWS trusted advisor is one out of that.

Use of Trusted Advisor Service

Some AWS Premium Support plans include access to the Trusted Advisor tool, which offers a one view snapshot of your service and helps identify common security misconfigurations, suggestions for improving system performance, and underutilized resources

Trusted Advisor checks for compliance with the following security recommendations:

• Limited access to common administrative ports to only a small subset of addresses. This includes ports 22 (SSH), 23 (Telnet) 3389 (RDP), and 5500 (VNC).

• Limited access to common database ports. This includes ports 1433 (MSSQL Server), 1434 (MSSQL Monitor), 3306 (MySQL), Oracle (1521) and 5432 (PostgreSQL).

• IAM is configured to help ensure secure access control of AWS resources.

• Multi-factor authentication (MFA) token is enabled to provide two-factor authentication for the root AWS account.

Manage AWS Accounts, IAM Users, Groups, and Roles

Create multiple IAM user, IAM users can be a person, service, or application that needs access to your AWS resources through the management console, CLI, or directly via APIs. Best practice is to create individual IAM users for each individual that needs to access services and resources in your AWS account. You can create fine-grained permissions to resources under your AWS account, apply them to groups you create, and then assign users to those groups. This best practice helps ensure users have least privilege to accomplish tasks.

• You create IAM users under your AWS account and then assign them permissions directly, or assign them to groups to which you assign permissions.

• Ensure IAM policies are attached to groups or roles

• Rotate IAM access keys regularly and standardize on the selected number of days

• Set up a strict password policy.

• Set the password expiration period to 90 days and ensure the IAM password policy prevents reuse.

• Do not use root account credentials for day-to-day interactions with AWS.

• Ensuring that users have appropriate levels of permissions to access the resources they need, but no more than that, is an important part of every ISMS.

• It strongly discourages the use of shared user identities, where multiple entities share the same credentials

Managing AWS Credentials

There are two primary types of credentials associated with identities

1. Credentials for sign-in to the AWS Management Console and AWS portal pages, and

2. programmatic access to the AWS APIs.

• IAM user passwords can be forced to comply with a policy you define (that is, you can require minimum password length or the use of non-alphanumeric characters etc).

• Multi-factor authentication (MFA)

• Make sure the API credentials are having least permission only specific to the application need.

• Make sure these API credentials should be inactive if it is not in use.

• As a best practice, users should rotate their access keys on a regular basis.

• Enforce MFA on APIs whether access is through the console or via APIs.

Using IAM Roles and Temporary Security Credentials

• Applications running on Amazon EC2 instances that need to access AWS resources should use roles rather than the long-term credentials

• Cross-account access: users from one account might need to access resources in the other account, so they can use cross region switch role policy to manage multiple AWS accounts.

• Identity Federation: Users might already have identities outside of AWS, such as in your corporate directory. However, those users might need to work with AWS resources. so, these users also need AWS security credentials in order to make requests to AWS.

Managing OS-level Access to Amazon EC2 Instances

• To enable authentication to the EC2 instance, AWS provides asymmetric key pairs, known as Amazon EC2 key pairs. These are industry-standard RSA key pairs. Each user can have multiple Amazon EC2 key pairs and can launch new instances using different key pairs.

• You can choose to have Amazon EC2 key pairs generated by AWS. In this case, both the private and public key of the RSA key pair is presented to you when you first create the instance. You must download and securely store the private key of the Amazon EC2 key pair

Securing Your Data

• You can use existing processes to manage encryption keys in the cloud, or you can leverage server-side encryption with AWS key management Designate data as confidential and limit the number of

• users who can access it

• Use encryption to protect confidential data on Amazon EBS or Amazon RDS.

• Perform data integrity checks, such as Message Authentication Codes (SHA-1/SHA-2), or Hashed Message Authentication Codes (HMACs), digital signatures, or authenticated encryption (AES-GCM), to detect data integrity compromise. If you detect data compromise, restore the data from backup, or, in the case of Amazon S3, from a previous object version.

• For services such as Amazon S3, you can use MFA Delete to require multi-factor authentication to delete an object, limiting access to Amazon S3 objects to privileged users.

• In the case of a system failure or a natural disaster, restore your data from backup, or from replicas

• Use bucket-level or object-level permissions alongside IAM policies to protect resources from unauthorized access and to prevent information disclosure, data integrity compromise, or deletion.

• Enable versioning to store a new version for every modified or deleted object from which you can restore compromised objects if necessary.

• Amazon S3 supports server-side encryption of user data. Server-side encryption is transparent to the end user. AWS generates a unique encryption key for each object and then encrypts the object using AES-256. The encryption key is then encrypted itself using AES-256-with a master key that is stored in a secure location. The master key is rotated on a regular basis

• With client-side encryption, you create and manage your own encryption keys. Keys you create are not exported to AWS in clear text. Your applications encrypt data before submitting it to Amazon S3 and decrypt data after receiving it from Amazon S3. Data is stored in an encrypted form, with keys and algorithms only known to you

• Access to your confidential data should be limited. When data is traversing the public network, it should be protected from disclosure through encryption. Encrypt data in transit using IPSec ESPand/or SSL/TLS.

• Whether or not data is confidential, you want to know that data integrity is not compromised through deliberate or accidental modification.

Managing Application and Administrative Access to AWS Public Cloud Services

• When accessing applications running in the AWS public cloud, your connections traverse the Internet. In most cases, your security policies consider the Internet an insecure communications medium and require application data protection in transit.

• Use HTTPS (HTTP over SSL/TLS) with server certificate authentication.

• Don’t use expired SSL/TLS certificates

• Offload HTTPS processing on Elastic Load Balancing to minimize the impact on web servers while still protecting data in transit. Further, protect the backend connection to instances using an application protocol such as HTTP over SSL.

• Users who access Windows Terminal Services in the public cloud usually use the Microsoft Remote Desktop Protocol (RDP). By default, RDP connections establish an underlying SSL/TLS connection.

• SSH is the preferred approach for establishing administrative connections to Linux servers. SSH is a protocol that, like SSL, provides a secure communications channel between the client and the server.

• If clients or servers need to access databases in the cloud, they might need to traverse the Internet as well.

• When using CloudFront, ensure CloudFront distributions use HTTPS.

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

• Provision access to resources using IAM roles.

• Ensure EC2 security groups don’t have large ranges of ports open.

• Use secure SSL ciphers when connecting between the client and ELB.

• Use standard naming (tagging) convention for EC2. Encrypt Amazon’s Relational Database Service (RDS)

• Ensure access keys are not being used with root accounts.

• Use secure CloudFront SSL versions.

• Rotating SSH keys periodically will significantly reduce the risk of account compromise due to developers accidentally sharing SSH keys inappropriately.

• Minimize the number of discrete security groups.

Inactive Entities

1. Reduce the number of IAM groups.

Reducing unused or stale IAM groups also reduces the risk of accidentally provisioning entities with older security configurations.

2. Terminate unused access keys.

Unused access keys increase the threat surface of an enterprise to a compromised account or insider threat. It is highly recommended that any access keys unused for over 30 days be terminated.

3. Disable access to inactive or unused IAM users.

As a best practice, unused IAM user accounts or users who haven’t logged into their AWS accounts in over 90 days should have their accounts disabled. This reduces the likelihood of an abandoned

account being compromised and leading to a data breach.

4. Remove unused IAM access keys.

Removing unused AWS IAM credentials can significantly reduce the risk of unauthorized access to your AWS resources. Access must not be enabled to resources for IAM users who have left the

organization or applications tools that are no longer using these resources.

5. Delete unused SSH Public Keys.

Deleting unused SSH Public Keys lowers the risk of unauthorized access to data using SSH from unrestricted locations.

Access Restrictions

1. Restrict access to Amazon Machine Images (AMIs).

Unrestricted access to AMIs makes these AMIs available in the Community AMIs where everyone with an AWS account can use them to launch EC2 instances. Most of the time, AMIs will contain snapshots of enterprise-specific applications (including configuration and application data). Hence, unrestricted access to AMIs is not recommended.

2. Disallow unrestricted ingress access to uncommon ports.

Allowing unrestricted inbound access to uncommon ports can increase opportunities for malicious activity such as hacking, data loss, brute-force attacks, DoS attacks, etc.

3. Restrict access to EC2 security groups.

Unrestricted access to EC2 security groups opens an enterprise to malicious attacks such as brute-force attacks, DoS attacks, or man-in-the-middle attacks.

4. Restrict access to RDS instances.

When the VPC security group associated with an RDS instance allows unrestricted access (i.e. source set to 0.0.0.0/0), entities on the internet can establish a connection to your database. This increases the risk of malicious activities such as brute force attacks, SQL injections, or DoS attacks.

5. Restrict outbound access.

Outbound access from ports must be restricted to required entities only, such as specific ports or specific destinations.

Creating Custom AMIs

You can create your own AMIs that meet the specific requirements of your organization and publish them for internal (private) or external (public) use. As a publisher of an AMI, you are responsible for the initial security posture of the machine images that you use in production

• Disable services and protocols that authenticate users in clear text over the network, or otherwise insecurely.

• 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.

• Configure sshd to allow only public key authentication. Set PubkeyAuthentication to Yes and PasswordAuthentication to No in sshd_config.

• Remove and disable passwords for all user accounts so that they cannot be used to log in and do not have a default password. Run passwd -l <USERNAME> for each account.

• Securely delete all user SSH public and private key pairs.

• Securely delete all shell history and system log files containing sensitive data.

• Ensure that the Guest account is disabled.

• Clear the Windows event logs.

• Make sure the AMI is not a part of a Windows domain.

• Do not enable any file sharing, print spooler, RPC, and other Windows services that are not essential but are enabled by default.

Protecting Your System from Malware

• Protect your systems in the cloud as you would protect a conventional infrastructure from threats such as viruses, worms, Trojans, rootkits, botnets, and spam.

• Launch instances from trusted AMIs only. Trusted AMIs include the standard Windows and Linux AMIs provided by AWS and AMIs from trusted third parties. Launching an untrusted third-party AMI can compromise and infect your entire cloud environment.

• Only install and run trusted software from a trusted software provider. A trusted software provider is one who is well regarded in the industry, and develops software in a secure and responsible fashion, not allowing malicious code into its software packages. Open source software can also be trusted software, and you should be able to compile your own executables.

• you perform careful code reviews to ensure that source code is non-malicious.

• Give users the minimum privileges they need to carry out their tasks. That way, even if a user accidentally launches an infected executable, the impact on the instance and the wider cloud system is minimized.

• Patch external-facing and internal systems to the latest security level. Worms often spread through unpatched systems on the network.

• Be sure to use a reputable and up-to-date antivirus and antispam solution on your system.

Secure Your Infrastructure: Amazon Virtual Private Cloud (VPC)

• Encrypt application and administrative traffic using SSL/TLS, or build custom user VPN solutions.

• Carefully plan routing and server placement in public and private subnets.

• Use security groups and NACLs.

• Establish a private IPSec connection using IKEv1 and IPSec using standard AWS VPN facilities (Amazon VPC VPN gateways, customer gateways, and VPN connections).

• Alternatively, establish customer- specific VPN software infrastructure in the cloud, and on-premises.

• With AWS Direct Connect, you can establish a connection to your Amazon VPC using private peering with AWS over dedicated links, without using the Internet. You can opt to not use IPSec in this case, subject to your data protection requirements. You can use IPSec over AWS Direct

• Connect links for additional end-to-end protection.

Strengthening Network Security

• Always use security groups: They provide stateful firewalls for Amazon EC2 instances at the hypervisor level. You can apply multiple security groups to a single instance, and to a single ENI.

• Augment security groups with Network ACLs: They are stateless but they provide fast and efficient controls. Network ACLs are not instance-specific so they can provide another layer of control in addition to security groups.

• Use IPSec or AWS Direct Connect for trusted connections to other sites.

• Use Virtual Gateway (VGW) where Amazon VPC-based resources require remote network connectivity.

• Protect data in transit to ensure the confidentiality and integrity of data, as well as the identities of the communicating parties

• VPC Flow Logs provides further visibility as it enables you to capture information about the IP traffic going to and from network interfaces in your VPC.

Controls for Periphery Systems

• Separate administrative level access

• Log and monitor authorized and unauthorized activity.

• Restrict network access to only systems that require it.

• Ensure that the software is patched and not subject to any known vulnerabilities or other risks.

• Ensure that the infrastructure is tested regularly.

• All other security controls processes in place

Mitigating and Protecting Against DoS & DDoS Attacks

Firewalls: Security groups, network access control lists, and host-based firewalls

• Manage the list of allowed destination servers and services (IP addresses & TCP/UDP ports)

• Manage the list of allowed sources of traffic protocols

• Explicitly deny access temporarily or permanently from specific IP addresses

• Manage the list of allowed

Use of Web application firewalls (WAF)

• Platform- and application-specific attacks

• Protocol sanity attacks

• Unauthorized user access

Host-based or inline IDS/IPS systems

All types of attack

Traffic shaping/rate limiting

• ICMP flooding Application request flooding

• TCP SYN flooding

Security Monitoring, Alerting, Audit Trail, and Incident Response

• Ensure CloudTrail is enabled across all AWS

• Turn on CloudTrail log file validation

• Integrate CloudTrail with CloudWatch

• Enable access logging for CloudTrail S3 buckets

• Enable access logging for Elastic Load Balancer (ELB)

• Note how log files are collected. Often operating system, application, or third-party/middleware agents collect log file information.

• When log files are centralized, transfer them to the central location in a secure, reliable, and timely fashion.

• Centralize log files from multiple instances to facilitate retention policies, as well as analysis and correlation.

• Present different categories of log files in a format suitable for analysis.

• Log files provide security intelligence after you analyze them and correlate events in them. You can analyze logs in real time, or at scheduled intervals.

• Log files are sensitive. Protect them through network control, identity and access management, encryption, data integrity authentication, and tamper-proof time- stamping.

Managing Logs for Critical Transactions

• User identification information

• Type of event

• Date and time stamp

• 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 include the following:

• 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 (for example, wireless, firewalls, DNS, mail) are offloaded or copied onto a secure 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

• Verifying that regular log reviews are performed for all system components

————————————————————————————————————————————————————————–

References,

AWS Security Best practices Whitepapers

https://aws.amazon.com/whitepapers/aws-security-best-practices/

---

Also Check,

Security Check Lists on AWS and Linux Servers.

If you Like Our Content here at Devopsage, then please support us by sharing this post.

Please Like and follow us at, LinkedIn, Facebook, Twitter, and GitHub

Also, Please comment on the post with your views and let us know if any changes need to be done.

Thanks!!

————————————————————————————————————————————————————————-