Hosted Environments Security Best Practices / Hardening Guidelines

1. Purpose, scope, and users

Resolver has an automated process of building out Hosted Platform by hardening and securing servers.

Resolver’s Hosted Platform uses a combination of scripts, automation tools, and server imaging to build out servers. These tools and processes ensure that all servers have the same foundation, layered products, and security.

The intended audience for this document includes DevOps, QE, and Development team members looking for guidance on best practices to deploy production, testing, and development environments.

2. Introduction

Resolver AWS VPC Networking security standard:

• DevOps team should be updated with the latest AWS Security Recommendations.
• Resolver teams involved in deployment and configuration should implement appropriate AWS Security Best practices.
• Resolver’s AWS Production environments architecture personnel should clearly understand the AWS “Shared Responsibility Model” / “Shared Security Responsibility Model”

3. Reference documents

• ISO/IEC 27001:2013 standard, control A.14.2.5
• Information Security Policy (ISP)

4. AWS VPC assets categorization

Links to Jira Tasks with GRC / PSV / Core environments assets, list, and assessment:

• Core:          Link to internal Confluence page, publicly not available.
• PSV:          Link to internal Confluence page, publicly not available.
• GRC:          Link to internal Confluence page, publicly not available.

5. Defense-in-depth approach

In order to create solutions and strategies based on the industry-standard cybersecurity model CIA which is (C) Confidentiality, (I) Integrity, and (A) Availability, Resolver employs a “Defense in Depth” Security approach to implementing Information technology (IT) security controls.

The primary “Defense in Depth” Security concept is to use all available Security mechanisms/controls in the different layers of the application deployment infrastructure, which minimizes potential attack vectors by creating multiple layers of protection if one layer of defense turns out to be inadequate.

6. General best practices

The following architecture practices are designed to support AWS best practices for high availability and security.

• Utilizing AWS VPC networking technology.
• AWS VPC Security groups:
  1. Operate at the instance level (first layer of defense).
  2. Support allows rules only.
  3. Are stateful: Return traffic is automatically allowed, regardless of any rules.
  4. All rules are evaluated before deciding whether to allow traffic.
  5. Applies to an instance only if someone specifies the security group when launching the instance or associates the security group with the instance at a later time.
• AWS VPC Network access control list (ACL) can be attached to any network subnet in a VPC and provide a way to do stateless filtering of traffic.
• Network ACLs can be used for inbound or outbound traffic and provide an effective way to blacklist a CIDR block or individual IP addresses.
• ACLs can contain ordered rules to allow or deny traffic based upon IP protocol, service port, or source/destination IP address. Additional details about ACLs:
  • Operate at the subnet level (second layer of defense).
  • Support allows rules and deny rules.
  • Are stateless: Return traffic must be explicitly allowed by rules.
  • Process rules in numerical order when deciding whether to allow traffic.
  • Automatically apply to all instances in the subnets the ACL is associated with (backup layer of defense, so you don’t have to rely on someone specifying the security group).
• AWS Identity and Access Management (IAM) and IAM Roles.
• Isolation of instances between private/public subnets, network segmentation.
• A secured bastion host instance to facilitate restricted login access for system administrator actions.
• Standard IAM policies with associated groups and roles, exercising the least privilege concept.
• Everything we can log at Resolver’s Production base on AWS platform environments must also be logged in CloudWatch:
  • Monitoring and logging; alerts and notifications for all critical events.
  • Active Directory Infrastructure logs.
  • S3 buckets (with security features enabled) for logging, archiving, and application data.
  • AWS CloudTrail logs should be enabled.
  • AWS Config should be enabled.
  • Enable the AWS VPC flow log.
  • Database access log.
  • All AWS services provided for logging abilities should be logged.
  • All logs must be redirected to CloudWatch (including CloudTrail).
  • Log retention at Amazon CloudWatch must be at least 365 days.
• Implementation of proper load balancing and Auto Scaling capabilities.
• HTTPS-enabled Elastic Load Balancing (ELB) load balancers with a hardened security policy.
• Wherever available and applicable, utilize AWS Application Load Balancing (ALB) (ALB = ELB+WAF).
• Amazon RDS database backup and encryption.
• Restrict access to different levels of Logical infrastructure perimeter by utilizing different sets of credentials:
  • AWS VPC Console access:
    • Utilizing AWS IAM user credentials enforced by MFA usage.
    • VPC network, VPN access:
  • Utilizing OpenVPN user credentials enforced by MFA usage.
  • ES2 Instance level depends on the Operation System (OS) version.
    • Windows: utilizing ADDS credentials.
    • Linux: Utilizing LDAP credentials.
  • Active Directory Domain Services (ADDS) infrastructure should be configured to a Highly Available configuration to manage OS level Access Control, Authentication, Authorization, and GPO Management for Infrastructure.
  • ADDS configured to protect against password brute force attack—please refer to Resolver’s Corporate Password Policy.
  • Regular backups—please refer to Resolver’s Corporate Backup Policy.

7. Availability aspect

• Multi-Availability Zones (Multi-AZ) architecture is intended for high availability.
• 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 AWS’s individual services by employing resilient components in multiple Availability Zones.
• Resolver’s standard architecture for production environments includes the utilization of AWS Multi-AZ as a mandatory mechanism.
• All critical assets (based on Resolver’s risk assessment) in production environments are deployed with redundant components to provide fault tolerance and high availability. This approach is a standard deployment best practice for all of Resolver’s production environments.

8. AWS IMA accounts management (confidentiality and integrity)

Create a standard to use and protect the AWS IMA root Account:

• Once you have created the AWS IMA Root Account, you must do the following:
  • Create and use IAM users instead of your root account. Do not use your AWS root account to access AWS. Instead, create individual IAM users for access to your AWS account. This allows you to give each IAM user a unique set of security credentials and grant different permissions to each user.
  • Grant least privilege. Apply fine-grained permissions to ensure that IAM users have the least privilege to perform only the tasks they need to perform. Start with a minimum set of permissions and grant additional permissions as necessary.
  • Manage permissions with groups. Assign permissions to groups instead of users to make it easier for you to assign and reassign permissions to multiple users at the same time. As people change job roles, you can simply change which IAM group each IAM user belongs to. (e.g. DevOps Viewer, DevOps infrastructure Operator, DevOps SQL Operator, DevOps Web Operator, Security Auditor, etc.)
  • Restrict privileged access further with policy conditions. Use conditions to add more granularity when defining permissions. The more explicitly you can define when resources are available and to whom, the safer your resources will be. Using conditions also can prevent your AWS users from accidentally performing privileged action.
  • Enable AWS CloudTrail to get logs of API calls. Enable logging of AWS API calls to gain greater visibility into users’ activity in your AWS resources. Logging lets you see which actions users have taken and which resources have been used, along with details such as the time and date of actions and the actions that have failed because of inadequate permissions.
  • Rotate security credentials regularly. Change your passwords and access keys regularly, and make sure that all IAM users in your AWS account do as well. You can apply a password policy to your AWS account to require all your IAM users to rotate their passwords, and you can choose how often they must do so. If a password is compromised without your knowledge, regular credential rotation limits how long that password can be used to access your AWS account.
  • Refer to “Resolver Corporate Password Policy” as a reference for password max lifetime.
  • Remove unused security credentials that are no longer needed. Generate and download a credential report that lists all IAM users in your AWS account and the status of their various credentials. Review the credential report to determine which credentials have not been used recently and can be removed. Removing unused credentials reduces your attack surface.
  • NOTE: Use quarterly review meetings to review active users.
  • Ensure you protect the AWS IMA Root Account with Multi-Factor Authentication (MFA), and enable MFA for all users.
  • Use IAM roles to share access. Never share credentials! Instead, use IAM roles that allow you to specify whom you trust and what each role can do in your account. Also, use IAM roles to delegate permissions across and within your accounts to both IAM and federated users.
  • Save the private key of the root account in an external USB device and store it in a protected safely.

9. Network segmentation (confidentiality)

Each tier of Production software deployment should be separated from the others. For example:

• AWS ALB (Application Load balancer) internet-facing interface tier.
• Web Servers (no public access from the internet) tier.
• Application Server (BI) (restricted access only from Web Server) tier/ network segment.
• DataBase (DB) isolated segment of the network, restricted access ONLY from BI network segment.

Each communication tier should be restricted only to a specific server by a combination of specific IP/ports.

10. Network/infrastructure DDoS safeguard

Enable AWS Shield to manage Distributed Denial of Service (DDoS) protection service.

11. VPN communication to AWS infrastructure (confidentiality)

Communication utilizing OpenVPN + LDAP/AD credentials + Multifactor Authentication (MFA).

12. Windows-based hosts

• Use the following base-level hardening steps:
  • Disable all unnecessary services.
  • Uninstall unnecessary software.
  • Disable wireless & WWAN.
  • Disable IPv6 (if not in use).
  • Disable LLMNR and NBT-NS.
  • Upgrade these systems monthly (on the second Tuesday of each month).
• All servers must run antivirus software. Daily automatic updates should be configured. A full scan should be performed on a monthly basis, and the report should be carefully evaluated.
• The standard process to perform maintenance work is:
  • Create a VPN Connection to the VPC environment, utilizing MFA.
  • Connect to Jump or Management host utilizing your domain account credential.
  • Use a combination of PowerShell over WRM (Windows Remote Management) to run the appropriate automation script(s).
• Direct RDP connections to servers should only be used in very rare scenarios.

NOTE: NO DIRECT RDP CONNECTION SHOULD EVER BE AVAILABLE FROM THE INTERNET.

• Perform timely updates/patching of the Operating System.
• Enable Advance Auditing policy.

13. Linux-based hosts

Use a non-root user account for the installation.

1. Use a non-root user for the installation.
2. Create a new user:
   1. Add the user to the “sudoers” list.
   2. Do not allow remote/ssh access if it’s not necessary.
3. Disable SSH remote access to root.
4. Use a separate non-root user for each application running.
5. Create a dedicated user for your application:
   1. It is recommended that you create a dedicated user per application. This way, the user can access the files created and owned by the same user but cannot view or edit files that belong to other users.
   2. Create a nologin user for your application, this is the recommended method of work for product components:
   3. useradd –s /sbin/nologin app-user.
6. Recommended to Use X.509 Certificate for Authentication.
7. Use a strong Password Policy.
8. Minimize Software to Minimize Vulnerability on your system. Remove/uninstall all packages your application and system don’t use for functionality.
9. Disable Firewire and USB Mass Storage Devices.
10. Disable wireless and WWAN.
11. Disable IPv6 (if not in use).
12. Keep Linux Kernel and Software up-to-date. To mitigate vulnerabilities with package management, update the system and software (e.g. yum update).
13. Minimize access to the system. If you do not need remote access to the system, stop SSH service.
14. If your application uses TCP/IP internal communication, use localhost IPv4 127.0.0.1 listener, do not use IPv6 address.
15. Restrict incoming and outgoing traffic:
    1. Allow incoming traffic for specific ports to which your application is listening (using iptables / firewall-cmd) in case if it is necessary for application functionality.
    2. Allow incoming traffic from specific sources (IP addresses/hostnames) using iptables / firewall-cmd.
    3. Allow outgoing traffic to specific ports (using iptables / firewall-cmd) to which your application is configured to connect and if it is necessary for application functionality.
    4. Allow outgoing traffic to a specific destination (IP addresses/hostnames) and port (using iptables / firewall-cmd) to which your application is configured to connect and if it is necessary for application functionality.
    5. Deny the rest of the incoming\outgoing traffic with the server.
16. Encrypt Data whenever possible:
    1. Encrypt transmitted data (for incoming and outbound traffic); TLSv1.2 (secure) communication whenever possible.
    2. Encrypt stored data; use strong symmetry encryption (e.g., AES256) for saved/stored data; use strong hash functions for stored passwords (e.g. SHA256).
17. All servers must run antivirus software. Each 4-hour automatic update should be configured. Run a full scan at least monthly and evaluate the report.
18. The standard process to perform maintenance is to use a VPN Connection to the VPC environment, utilizing MFA.
19. Connect to Jump or Management host utilizing your LDAP account.

14. Application-level protection (confidentiality and integrity)

• Deploy AWS WAF / AWS Application Load Balancer (ALB) as a Secure Reverse proxy solution to protect Web Front-end, where it is available and when it’s applicable.
• Use the least privilege principle in applications.
• Perform regular Vulnerability Scanning at least once a month.
• Perform regular penetration testing at least once per major release.
• All users must authenticate to the system with a username and password.
  • Implement Web-SSO authentication scheme if it’s acceptable by the customer ONLY over Secure HTTPS protocol utilizing TLS v1.2 with ciphers suites supporting Authenticated Encryption with Associated Data (AESD), e.g. AES-GSM or AES-CCM
  • Or, if applicable (depending on application), implement two-factor authentication (2FA) to provide an additional level of security.
• Users should be assigned to roles that control access to functionality.
• Application administrators are responsible for controlling access to user roles.
• The application maintains an audit log of user activity which redirects to AWS CloudWatch.
• Audit logs are read-only from within the application. This ensures the audit logs cannot
  be tampered with from within the application.
• After a period end, the audit logs are archived and not available from within the
  Past period audit logs are available only from the backend. The application
  has the ability to retain archived logs in the database for a period of 7 years or longer, depending upon what the business decides.
• Passwords are encrypted and saved in the database using the bCrypt one-way hashing algorithm, with each password having its own unique seed. Clear text passwords are never saved or communicated.
• Password complexity is enforced by the application. Passwords must be at least eight (8) characters in length, contain a lower-case letter, upper case letter, and a number, and must be different than the last seven passwords. Application administrators can choose how many previous passwords to enforce.

15. Non-conformance

All policies require the participation of staff and contractors to be successful. Any employee or contractor found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.

16. Validity and document management

This document is valid as of August 2022.

The owner of this document is an Information Security Analyst who must check and, if necessary, update the document at least once a year.

When evaluating the effectiveness and adequacy of this document, the following criteria need to be considered:

• The number of incidents arising from the unclear definition of the document.

EFFECTIVE ON: August 2022

REVIEW CYCLE: Annual at least and as needed