Technical Countermeasure Report · to preserve forensic quality of the logs, it is important a...

Technical CountermeasureReport

User Accounts

Administrator adminReport generated by:Unique ID: user-accountsWorkflow State:

Index

Summary

Architectural Diagrams

Required CountermeasuresComponent: API GWComponent: MySQL

Implemented CountermeasuresComponent: API GWComponent: MySQL

Rejected CountermeasuresComponent: API GW

Countermeasure Test ResultsFailed

Component: API GWComponent: MySQL

PassedComponent: API GW

Not testedComponent: ELB - Elastic Load BalancerComponent: MySQL

Appendix A: Countermeasure DetailsComponent: API GWComponent: ELB - Elastic Load BalancerComponent: MySQL

Product name: User Accounts

Unique ID: user-accounts

Administrator adminOwner:

Business unit: bu_user_admin

Product description:

SummaryShown below is a brief description of the product and summary analysis of the risks.

3Technical Countermeasure ReportUser Accounts

Architectural Diagrams

irius-risk-diagram-architecture-image.png09-May-2019 15:20:22admin

Filename:Username: Date uploaded:


Required Countermeasures

Component: API GW

Related threatsCountermeasure name Test resultLog details of user actions within thesystem • Attacks against the authentication system may go undetectedNot Tested

Log and reject all data validationfailures • Attacks against the authentication system may go undetectedNot Tested

Encrypt data between the client andserver/service • Attackers gain control of the connection through a Man In The

Middle attackNot Tested

Use a synchronised time source • Attacks against the authentication system may go undetectedNot Tested

Validate all data received from theclient side • Attackers gain access to the system through Server Side Code

InjectionNot Tested

Log the backend TLS connectionfailures • Attacks against the authentication system may go undetectedNot Tested

Ensure the integrity of the loggingsystem

• An attacker injects, manipulates or forges malicious log entriesin the log file, allowing him to mislead a log audit, cover traces ofattack, or perform other malicious actions

Not Tested

Limit the number of accounts withprivileges allowing modificationand/or deletion of audit logs files


Failed

Ensure that the client-side and theserver-side are using the sameencoding style

• Attackers gain access to the system through Server Side CodeInjection

Not Tested

Component: MySQL

Related threatsCountermeasure name Test result

Use prepared statements for alldatabase queries • Attackers gain unauthorised access to data and/or systems

through SQL Injection attacksNot Tested

Apply required security patches to theservice • Attackers gain access to unauthorised data by exploiting

vulnerabilities in the serviceNot Tested


Implemented Countermeasures

Component: API GW


Escape meta-characters from un-trusted data


Passed

Do not write secrets to the log files • Data leakage or disclosure to unauthorized partiesNot Tested

Develop a log retention policy • Data leakage or disclosure to unauthorized partiesNot Tested

Restrict actions of users that followunusual patterns. • Attackers subvert the intended workflow of the application in

order to perform unauthorised operationsNot Tested

Component: MySQL


Require authentication beforepresenting restricted data • Attackers obtain unauthorised access by connecting directly to

the serviceFailed

Access the data store from anaccount with the least privilegesnecessary

• Attackers who compromise the application or application servercould directly access and modify the data store

Not Tested


Rejected Countermeasures

Component: API GW

Related threatsCountermeasure name Test result Reason

Implement application and networkrate limiting • Denial of service through

resource exhaustionNot Tested

This Component is not plannedto be behind the WAF, wecannot implement this on afeasible way.

Detect and notify the usage ofautomated tools or unusualbehavior

• Attackers subvert the intendedworkflow of the application in order toperform unauthorised operations

Not Tested

This Component is not plannedto be behind the WAF, wecannot apply thiscountermeasure.


Countermeasure Test ResultsFailedThe below table shows all countermeasures with failed test results.

Component: API GW

Name DescriptionLimit the number of accounts withprivileges allowing modification and/ordeletion of audit logs files

Limit the number of account with privileges to modify and/or delete audit logs files.

Component: MySQL

Name Description

Require authentication beforepresenting restricted data

The application should ensure users have undergone an Identification andVerification (ID&V) process before allowing access to secret, sensitive or otherwiserestricted data. For less sensitive but still restricted data, simple verification of thelocation of the user may suffice (e.g. IP restrictions).

• For non-sensitive but non-public data, access could be restricted by IP address,for example limiting access to internal networks, workstations, or gateways • For more sensitive data, TLS client-side certificates may be appropriate • Where secret or other sensitive data is handled, a full authentication process toidentify and validate users with single or multi-factor authentication may be required


PassedThe below table shows all countermeasures with passed test results.

Component: API GW

Name Description

Escape meta-characters from un-trusteddata

If untrusted data, including any data received from the client side of a connection isdirectly written to a log file, then this data could contain newline or other meta-characters that would allow an attacker to forge log entries.Such meta-characters should first be escaped or removed before the data is writtento the logging system.


Not testedThe below shows all countermeasures with not tested results.

Component: API GW

Name Description

Log details of user actions within thesystem

To maintain proper accountability, logs should be maintained with sufficientinformation to track user actions within the system. These logs should be forensicallysound, non-repudiable, and contain comprehensive details about activity. While theexact data for an event may vary, the following should be captured at a minimum:

• Timestamps against a proven external source (e.g. an NTP server) • Origin, with this field we mark if the logs are provided by a trusted or untrustedsource. • Event, status, and/or error codes (with sensitive data masked as appropriate ornot introduced in logs) • Service, command, application or function name and details • User or system account associated with an event • Devices used (e.g. source and destination IPs, terminal session ID, webbrowser, etc)Source: https://security.berkeley.edu/security-audit-logging-guideline

Log and reject all data validation failures

Data validation failures, together with access control violations, are symptomatic ofmalicious activity where an attacker is attempting to subvert the protections in place.It is therefore likely that unexpected input detected by the application relates to anattack. Rejecting and logging such activity, and ideally terminating the session,increases the likelihood of detecting and inhibiting structured attacks against theapplication.

• Log all validation failures when rejecting requests. • Ensure logged data is appropriately sanitized and encoded to prevent attacksagainst the logs and subsequent access to them. • Terminate the offending user session to inhibit further attack. • Ensure errors returned to the client-side are generic to prevent an attackerenumerating the defenses in place or gaining knowledge about the back-end.

Encrypt data between the client andserver/service

Data passed between the client and server should be protected by encryption intransit.

• Implement cryptographically strong TLS end-to-end encryption between theclient and server, terminating within a secure environment on the server-side. • Consider use of client certificates to prevent interception of (or man-in-the-middle attacks on) the encrypted connection. • Alternatively, asymmetric (public-key) encryption could be utilized, although arecognized, proven, and tested implementation/library should be used

Do not write secrets to the log files The logs may be accessed by attackers and in order to protect sensitive data, nosuch sensitive data should be included in the logs

Prevent unauthorised access to sourcecode through the service

Access to the source-code for the application can aid an attacker in determined bugsor vulnerabilities in the code or logic. For closed-source projects it is thereforeimportant to control and restrict access to the source. Application services mayunexpectedly expose code, for example a service providing files to a user could bemanipulated to access source code if implemented insecurely.

• Ensure that source code is not inadvertently disclosed through misconfigurationor vulnerabilities in the service. • Check that configuration files are not downloadable directly from the service,and cannot be read and viewed through the service itself. • Ensure backups, operating system, and version control artifacts do not exposecode.


https://security.berkeley.edu/security-audit-logging-guideline

Use a synchronised time source

In order to correlate logs and data from different internal and external systems, andto preserve forensic quality of the logs, it is important a unified and trustedsynchronized time source is used throughout the environment.

• Servers should be synchronize to an internal or external NTP server • The centralized source should in turn use (or be) a trusted central time source.This control is critical in identifying application events (including attacks) throughlogging, and in conduction post-event analysis, in particular to track the whole user(or attacker) journey through the system should it be compromised.

It is good practice to use the concept of Indicators of Compromise (IoC) should beused to detect possible situations in which the system has been compromised and togive an appropriate response. IoCs are often tracked through logs, and accuratetime is often essential.

Implement application and network ratelimiting

A number of attacks rely on brute-force techniques to send large volumes ofrequests to enumerate or attempt to exploit flaws in an application, for example,sending common passwords to multiple target accounts within an application. Byprofiling normal traffic volumes, and applying rate limiting, the application can be builtto actively mitigate such attacks.

• Connection rate-limiting based on the source IP address can be used to restrictattacks against the authentication or registration systems. Multiple failures (orattempts) from a single IP should result in temporarily blocking or dropping trafficfrom the source. Note however that some corporate and ISP environment may placemultiple valid and discrete clients behind the same IP address, resulting in false-positives. • Attackers may use botnets and other IP masking techniques to deliver attacksfrom multiple sources to avoid IP based rate-limiting. To mitigate this class of attack,Indicators of Compromise should be monitored (for example a higher rate of loginfailures than usual), and appropriate actions taken. For example, when theapplication detects active brute-force attacks, a Web Application Firewall (WAF) orother intermediate devices could be used to block attacks sharing a signature frompattern matching or deep packet inspection (e.g. HTTP headers or commonpasswords across multiple accounts). Similarly, the application could respond byrequiring a CAPTCHA, cookie, or Javascript challenge when an attack is detected.

Remediation:Implement the mechanisms to lockout accounts:

• When the application detects a set number of failure login attempts, the accountshall be locked for a certain time period. • When the application detects that an account is locked more times than usual,this account shall be disabled. A disabled account shall only be restored by anadministrator. • When the application detects active brute-force attacks, the application shallrequire a CAPTCHA, cookie, or JavaScript challenge.


Validate all data received from the clientside

All data received from the client-side should be considered tainted and a potentialrisk, regardless of the source or transport method. For example, while hidden formfields, cookies, or other headers may be obfuscated from a user, along withparameters passed in ViewStates or other encapsulated forms, these can bemodified by the user at the client-side in memory, or in transit on the network.Similarly, data passed from binary or compiled components can be modified in situ orin transit.

Furthermore, encryption only secures the data in transit between the two ends of theencrypted tunnel (one end of which is typically controlled by the client); data passingthrough the link may still be malicious.

As such, all data from the client side must be subjected to strict validation,sanitization, and encoding against expected syntactic and semantic criteria.

• Define a specification of the data that is expected at each input; both the syntax(e.g. alphanumeric only) and semantics (e.g. a word of between 1 and 25 characters,or a specific list). As an example of business rule logic, "boat" may be syntacticallyvalid because it only contains alphanumeric characters, but it is not valid if the inputis only expected to contain colors such as "red" or "blue." • Implement a 'known good' or white-list approach, where only inputs that meetthe strict criteria for each input are accepted, and reject, transform, or encapsulateany non-compliant data. • While useful for identifying malicious content, do not rely on looking for specificmalformed or attack payloads (blacklists). It is almost impossible to maintain acomprehensive and accurate blacklist due to the complexity and evolving nature ofattacks, opportunities to obfuscate payloads, and changes to the code's executionenvironment. As noted, blacklists can be useful for detecting and logging potentialattacks, or determining which inputs are so malformed that they should be rejectedoutright. • Validate all data received from the client, including values such as HTTPheaders and cookie values if these are used as input on the server side, X- headers,and other platform specific data objects passed between the client and server.

Develop a log retention policy

Develop a log retention policy to identify storage requirements for device logs andimplement procedures to ensure that the audit logs are available for a securityresponse in the case of incident or investigation.

The audit logs must be collected for the last 30 days in easily accessible storagemedia. Older logs should be archived in a protected storage and should beaccessible in the future as required for incidents or investigations.

Log the backend TLS connectionfailures

Implement functionality to record backend TLS connection failures and include thesein the logs.

Ensure the integrity of the loggingsystem

Ensure Log integrity for the application generated logs, such as storing logs on write-once media, forwarding a copy of the logs to a centralized SIEM or generatingmessage digests for each log file.

Detect and notify the usage ofautomated tools or unusual behavior

Don't allow users to manipulate a system or guess its behavior based on input oroutput timing and detect the usage of automated tools or unusual behavior, such asactions not performed in reasonable "human time" or other abnormal time patterns.

When the usage of automated tools is detected, the application shall respond withdenying the access and notifying the security group.

Restrict actions of users that followunusual patterns.

Restrict actions that users can do outside of the approved/required business processflow.

This is important because without this safeguard in place attackers may be able tobypass or circumvent work-flows and checks allowing them to prematurely enter orskip required sections of the application potentially allowing action/transaction to becompleted without successfully completing the entire business process, leaving thesystem with incomplete back-end tracking information.

Ensure that the client-side and theserver-side are using the sameencoding style

Ensure that the client-side and the server-side are using the same encoding style.


Component: ELB - Elastic Load Balancer

Name Description

Use the Perfect Forward Secrecyfeature

For greater communication privacy Elastic Load Balancing allows the use of PerfectForward Secrecy. This feature provides additional safeguards against eavesdroppingon encrypted data, through the use of a unique random session key, and thereforeprevents the decoding of captured data, even if the secret long-term key iscompromised.

To begin using Perfect Forward Secrecy:Configure your load balancer with the newly added Elliptic Curve Cryptography(ECDHE) cipher suites.

Select the Server Order Preferenceoption

Within Elastic Load Balancing ensure the use of newer and stronger cipher suiteswhen establishing a new connection supporting the Server Order Preference option.When this option is selected, the load balancer selects the first cipher in its list that isin the client's list of ciphers.

Remediation:To enable Server Order Preference:

• Open the Amazon EC2 console. • Under LOAD BALANCING, choose Load Balancers.

• Select your Load Balancer.

• On the Listeners tab, for Cipher, choose Change.

• On the Select a Cipher page, select Custom Security Policy.

• For SSL Options, select Server Order Preference.

• Click Save.

Use HTTPS listener for Web Tier ELB

A load balancer takes requests from clients and distributes them across the EC2instances that are registered with the load balancer (also known as back-endinstances).

A listener is a process that checks for connection requests. It is configured with aprotocol and a port for front-end (client to load balancer) connections

Note: an HTTPS listener configured on the ELB is not mandatory if you areterminating SSL connections directly on the Web Tier EC2 instances, and using aTCP listener on the ELB (TCP pass-through)

Using an HTTPS Elastic Load Balancer listener will make sure the application trafficbetween the client and the Web Tier ELB is encrypted over the SSL\TLS channel.

Remediation:Using the Amazon unified command line interface:

• If the ListenerDescription field is missing, add a new HTTPS listener configuredwith a SSL\TLS certificate (the listener forwards traffic to the backend instances onport 80, but this can be modified by editing InstancePort=80):aws elb create-load-balancer-listeners --load-balancer-name <web_tier_elb> --listenersProtocol=HTTPS,LoadBalancerPort=443,InstanceProtocol=HTTP,InstancePort=80,


Configure the latest SSL SecurityPolicies for Web Tier ELB

Elastic Load Balancing uses an Secure Socket Layer (SSL) negotiationconfiguration, known as a security policy, to negotiate SSL/TLS connections betweena client and the load balancer. A security policy is a combination of SSL/TLSprotocols, ciphers, and the Server Order Preference option.

Elastic Load Balancing supports configuring your load balancer to use eitherpredefined or custom security policies.

Secure Sockets Layer (SSL) and Transport Layer Security (TLS) are cryptographicprotocols that are used to encrypt confidential data over insecure networks such asthe Internet. The TLS protocol is a newer version of the SSL protocol. In the ElasticLoad Balancing documentation, we refer to both SSL and TLS protocols as the SSLprotocol.

Note: an SSL certificate configured on the ELB and an SSL Security Policy is notmandatory if you are terminating SSL connections directly on the Web Tier EC2instances, and using a TCP listener on the ELB (TCP pass-through)

Making sure the latest ELB SSL Security Policy is used will ensure the SSL/TLSconnection will be negotiated using only the appropriate cryptographic protocolsdeemed safe with no proven vulnerabilities.

Remediation:Using the Amazon unified command line interface:(Note that you should replace <web\_tier\_elb> with your Web-tier ELB name, and_<latest\_ssl\_policy>_ with the proper policy name)

aws elb set-load-balancer-policies-of-listener --load-balancer-name <web_tier_elb> --load-balancer-port 443 --policy-names <latest_ssl_policy>

Add SSL/TLS Certificate to App TierELB

When you use HTTPS for your front-end listener, you must deploy an SSL/TLScertificate on your load balancer. The load balancer uses the certificate to terminatethe connection and then decrypt requests from clients before sending them to theback-end instances.

The SSL\TLS protocol uses an X.509 certificate (SSL\TLS server certificate) toauthenticate both the client and the back-end application. An X.509 certificate is adigital form of identification issued by a trusted certificate authority (CA) and containsidentification information, a validity period, a public key, a serial number, and thedigital signature of the issuer.

You can create a certificate using a Third Party Certificate Authority, AWS CertificateManager or a self signed certificate like OpenSSL.

Note: an SSL certificate configured on the ELB is not mandatory if you areterminating SSL connections directly on the App Tier EC2 instances, and using aTCP listener on the ELB (TCP pass-through)

All the application traffic between the Web Tier instances and the App Tier ELBnodes should be encrypted using an SSL\TLS certificate.Remediation:

Using the Amazon unified command line interface:

• Adding a HTTPS listener configured with a SSL\TLS certificate (the listenerforwards traffic to the backend instances on port 80, but this can be modified byediting InstancePort=80):

aws elb create-load-balancer-listeners --load-balancer-name <app_tier_elb> --listenersProtocol=HTTPS,LoadBalancerPort=443,InstanceProtocol=HTTP,InstancePort=80,


Configure the latest SSL SecurityPolicies for App Tier ELB

Elastic Load Balancing uses an Secure Socket Layer (SSL) negotiationconfiguration, known as a security policy, to negotiate SSL/TLS connections betweena client and the load balancer. A security policy is a combination of SSL/TLSprotocols, ciphers, and the Server Order Preference option.

Elastic Load Balancing supports configuring your load balancer to use eitherpredefined or custom security policies.

Secure Sockets Layer (SSL) and Transport Layer Security (TLS) are cryptographicprotocols that are used to encrypt confidential data over insecure networks such asthe Internet. The TLS protocol is a newer version of the SSL protocol. In the ElasticLoad Balancing documentation, we refer to both SSL and TLS protocols as the SSLprotocol.

Note: an SSL certificate configured on the ELB and an SSL Security Policy is notmandatory if you are terminating SSL connections directly on the App Tier EC2instances, and using a TCP listener on the ELB (TCP pass-through)

Making sure the latest ELB SSL Security Policy is used will ensure the SSL/TLSconnection will be negotiated using only the appropriate cryptographic protocolsdeemed safe with no proven vulnerabilities.


• (Note that you should replace <app\_tier\_elb> with your App-tier ELB name,and <latest\_ssl\_policy> with the proper policy name)aws elb set-load-balancer-policies-of-listener --load-balancer-name <app_tier_elb> --load-balancer-port 443 --policy-names <latest_ssl_policy>

Use HTTPS listener for App Tier ELB

A load balancer takes requests from clients and distributes them across the EC2instances that are registered with the load balancer (also known as back-endinstances).

A listener is a process that checks for connection requests. It is configured with aprotocol and a port for front-end (client to load balancer) connections.

Note: an HTTPS listener configured on the ELB is not mandatory if you areterminating SSL connections directly on the App Tier EC2 instances, and using aTCP listener on the ELB (TCP pass-through)

Using an HTTPS Elastic Load Balancer listener will make sure the application trafficbetween the client and the App Tier ELB is encrypted over the SSL\TLS channel.


• If the ListenerDescription field is missing, add a new HTTPS listener configuredwith a SSL\TLS certificate (the listener forwards traffic to the backend instances onport 80, but this can be modified by editing InstancePort=80):aws elb create-load-balancer-listeners --load-balancer-name <app_tier_elb> --listenersProtocol=HTTPS,LoadBalancerPort=443,InstanceProtocol=HTTP,InstancePort=80,


Add SSL/TLS Certificate to Web TierELB

When you use HTTPS for your front-end listener, you must deploy an SSL/TLScertificate on your load balancer. The load balancer uses the certificate to terminatethe connection and then decrypt requests from clients before sending them to theback-end instances.

The TLS protocol uses an X.509 certificate (SSL/TLS server certificate) toauthenticate both the client and the back-end application. An X.509 certificate is adigital form of identification issued by a trusted certificate authority (CA) and containsidentification information, a validity period, a public key, a serial number, and thedigital signature of the issuer.

You can create a certificate using a Third Party Certificate Authority or AWSCertificate Manager.

Note: an SSL certificate configured on the ELB is not mandatory if you areterminating SSL connections directly on the Web Tier EC2 instances, and using aTCP listener on the ELB (TCP pass-through)

All the application traffic between the clients and the Web Tier ELB nodes should beencrypted using a SSL/TLS certificate.


• Adding a HTTPS listener configured with a SSL/TLS certificate (the listenerforwards traffic to the backend instances on port 80, but this can be modified byediting InstancePort=80):aws elb create-load-balancer-listeners --load-balancer-name <web_tier_elb> --listenersProtocol=HTTPS,LoadBalancerPort=443,InstanceProtocol=HTTP,InstancePort=80,

Associate each Auto-Scaling Group toELB

Elastic Load Balancing automatically distributes incoming application traffic acrossmultiple Amazon EC2 instances within a VPC.

It enables greater levels of fault tolerance in your applications, seamlessly providingthe required amount of load balancing capacity needed to distribute application trafficacross 1 or more Availability Zones within a VPC.

Elastic Load Balancing must be integrated with Auto Scaling Groups to ensure thatyou have availability of compute resources in the event of a failure.

Integrating Auto Scaling Groups with an Elastic Load Balancer will help provide highavailability and back-end EC2 instance scaling.

Through Auto-Scaling Group configuration you can define:minimum / maximum number of EC2 instances to be launched by the Auto-ScalingGroupAvailability Zones / subnets used


• List existing load balancers:aws elb describe-load-balancers --query'LoadBalancerDescriptions[*].{ELBName:LoadBalancerName}'

or

• Create new load balancer:aws elb create-load-balancer --load-balancer-name <elb_name> --listeners<listener_config> --subnets <application_subnet> --security-groups<application_security_groups>

• Attached load balancer from previous steps to autoscaling group:aws autoscaling attach-load-balancers --load-balancer-names <elb_name> --auto-scaling-group-name <autoscaling_group_name>


Set a HTTPS connection from allCloudFront Distributions to the Web TierELB origin

Configure the Origin Protocol Policy for the Web tier ELB origin either to require thatCloudFront fetches objects from your origin by using HTTPS or to require thatCloudFront uses the protocol that the viewer used to request the objects. Forexample, if you choose Match Viewer for the Origin Protocol Policy and the vieweruses HTTPS to request an object from CloudFront, CloudFront also uses HTTPS toforward the request to your origin.

In order to use HTTPS, an SSL\TLS certificate must be attached.

To ensure that objects are encrypted from edge locations to the Web-Tier ELB originaccording to the data classification policy, use Match Viewer.


• For configuring "OriginProtocolPolicy"first save locally the current distributionconfig:aws cloudfront get-distribution-config --id application_cfn_distribution_id --query"DistributionConfig" > /tmp/cf-distribution.json

Edit and replace "OriginProtocolPolicy"element in /tmp/cf-distribution.json with thebelow section:"OriginProtocolPolicy": "https-only",

• Retrieve the current ETag of your CloudFront distribution:aws cloudfront get-distribution-config --id <application_cfn_distribution_id> --query"ETag"

• Update the CloudFront distribution using the edited config and the above Etag:aws cloudfront update-distribution --id <application_cfn_distribution_id> --distribution-config file:///tmp/cf-distribution.json --if-match <application_cfn_distribution_etag>

Associate Web Tier Auto-Scaling Groupto ELB







• List existing load balancers:aws elb describe-load-balancers --query'LoadBalancerDescriptions[*].{ELBName:LoadBalancerName}'or

• Create new load balancer:aws elb create-load-balancer --load-balancer-name <web_tier_elb> --listeners<listener_config> --subnets <web_tier_elb_subnet1> <web_tier_elb_subnet2> --security-groups <web_tier_elb_security_group>

• Attached load balancer from previous steps to autoscaling group:aws autoscaling attach-load-balancers --load-balancer-names <web_tier_elb> --auto-scaling-group-name <web_tier_autoscaling_group_name>


Associate App Tier Auto-Scaling Groupto ELB








or

• Create new load balancer:aws elb create-load-balancer --load-balancer-name <app_tier_elb> --scheme internal--listeners <listener_config> --subnets <app_tier_subnet1> <app_tier_subnet2> --security-groups <app_tier_elb_security_group>

• Attached load balancer from previous steps to autoscaling group:aws autoscaling attach-load-balancers --load-balancer-names <app_tier_elb> --auto-scaling-group-name <app_tier_autoscaling_group_name>


Configure Health Check for Web TierELB

By default, an Auto-Scaling Group periodically uses the results of the EC2 instancestatus checks to determine the health status of each instance. If an instance fails theEC2 instance status checks, Auto-Scaling marks the instance as unhealthy andreplaces the instance.

However, if you have attached one or more Elastic Load Balancing (ELB) loadbalancers to your Auto-Scaling Group and the instance fails the ELB health checks,Auto-Scaling does not replace the instance.

Amazon ELB will periodically sends pings, attempt connections, or sends requests totest the EC2 instances, these tests are called health checks.

The status of the instances that are healthy at the time of the health check isInService.

The status of any instances that are unhealthy at the time of the health check isOutOfService.

The load balancer performs health checks on all registered instances, whether theinstance is in a healthy state or an unhealthy state. The load balancer routesrequests only to the healthy instances. When the load balancer determines that aninstance is unhealthy, it stops routing requests to that instance. The load balancerresumes routing requests to the instance when it has been restored to a healthystate

Ensure availability of back-end EC2 instances associated with an Amazon ELBthrough application layer health check (ex: http) instead of TCP health checks.

Remediation:Using the Amazon unified CLI:

• Create a JSON file containing the attributes you want to modify and save itlocally as /tmp/ELBhealthcheck.json:{ "Target": "<string>", "Interval": <integer>, "Timeout": <integer>, "UnhealthyThreshold": <integer>, "HealthyThreshold": <integer>}

• Modify Web tier ELB to include appropriate health check:aws elb configure-health-check --load-balancer-name <web_tier_elb> --health-checkfile:///tmp/ELBhealthcheck.json


Configure Health Check for App TierELB

By default, an Auto-Scaling Group periodically uses the results of the EC2 instancestatus checks to determine the health status of each instance. If an instance fails theEC2 instance status checks, Auto-Scaling marks the instance as unhealthy andreplaces the instance.

However, if you have attached one or more Elastic Load Balancing (ELB) loadbalancers to your Auto-Scaling Group and the instance fails the ELB health checks,Auto-Scaling does not replace the instance.

Amazon ELB will periodically sends pings, attempts connections, or sends requeststo test the EC2 instances, these tests are called health checks.

The status of the instances that are healthy at the time of the health check isInService.

The status of any instances that are unhealthy at the time of the health check isOutOfService.

The load balancer performs health checks on all registered instances, whether theinstance is in a healthy state or an unhealthy state. The load balancer routesrequests only to the healthy instances. When the load balancer determines that aninstance is unhealthy, it stops routing requests to that instance. The load balancerresumes routing requests to the instance when it has been restored to a healthystate

Ensures availability of back-end EC2 instances associated with an Amazon ELBthrough application layer health check (ex: http) instead of TCP health checks.


• Create a JSON file containing the attributes you want to modify and save itlocally as /tmp/ELBhealthcheck.json:{ "Target": "<string>", "Interval": <integer>, "Timeout": <integer>, "UnhealthyThreshold": <integer>, "HealthyThreshold": <integer>}

• Modify App tier ELB to include appropriate health check:aws elb configure-health-check --load-balancer-name <app_tier_elb> --health-checkfile:///tmp/ELBhealthcheck.json


Enable the ELB logging

Elastic Load Balancing automatically distributes incoming application traffic acrossmultiple Amazon EC2 instances in the a VPC. It enables you to achieve greaterlevels of fault tolerance in your applications, seamlessly providing the requiredamount of load balancing capacity needed to distribute application traffic.

AWS Elastic Load Balancers (ELBs) can record all incoming requests sent to theload balancer and store within logs on S3. This allows for diagnosing applicationfailures and analyzing web traffic and security analysis of incoming traffic


• Create a JSON file containing the attributes you want to modify and save itlocally as /tmp/ElbLogs.json:{"AccessLog": { "Enabled": true, "S3BucketName": "string", "EmitInterval": integer, "S3BucketPrefix": "string" }}

• Update the Load Balancer attributes:aws elb modify-load-balancer-attributes --load-balancer-name <elb_name> --load-balancer-attributes file:///tmp/ElbLogs.json

Set Root Domain Alias Record to ELB

Amazon Route 53 translates friendly domains names like www.example.com into IPaddresses like 192.0.2.1. Amazon Route 53 responds to DNS queries using a globalnetwork of authoritative DNS servers, which reduces latency.

When someone enters your domain name in a browser, a DNS request is forwardedto the nearest Amazon Route 53 DNS server in a global network of authoritativeDNS servers. Amazon Route 53 responds with the IP address that you specified.

Each domain has an associated hosted zone which contains the resource recordspointing to each layer of the application.

A private hosted zone is a container that holds information about how you want toroute traffic for a domain and its subdomains within the Amazon Virtual Private Cloud(Amazon VPC). To begin, you create a private hosted zone and specify the AmazonVPCs that you want to associate with the hosted zone. You then create resourcerecord sets that determine how Amazon Route 53 responds to queries for yourdomain and subdomains within and among your Amazon VPCs.

Route53 provides special record type called Alias that allows creation of an A recordfor the root domain and points it to the fully qualified domain of the Elastic LoadBalancer (ELB) associated with the web-server layer or Amazon CloudFront.

In the same way records for all other layers should be created in order to allowflexibility in the application design and not hard-code the FQDN of a resource.


• Create a hosted zone for YourDomain.com:aws route53 create-hosted-zone --name <your_domain.com> --caller-reference<any_string>


Allow connectivity to the VPC InternetGateway (IGW) and associate theRouting Table with Web tier ELB subnet(by default route (0.0.0.0/0))

A route table contains a set of rules, called routes, that are used to determine wherenetwork traffic is directed.

Each subnet in your VPC must be associated with a route table; the table controlsthe routing for the subnet. A subnet can only be associated with one route table at atime, but you can associate multiple subnets with the same route table.

The default route (0.0.0.0/0) should be pointing to the Internet Gateway in order toprovide internet connectivity for the Web tier ELB.


• For the above route tables, if the default route (0.0.0.0/0) exists but it doesn'thave an IGW configured as gateway:aws ec2 replace-route --route-table-id <route_table_id> --destination-cidr-block0.0.0.0/0 --gateway-id <vpc_igw>

• For the above route tables, if the default route (0.0.0.0/0) doesn't exist:aws ec2 create-route --route-table-id <route_table_id> --destination-cidr-block0.0.0.0/0 --gateway-id <vpc_igw>


Use a Web-Tier ELB Security Group toaccept only HTTP/HTTPS

A security group acts as a virtual firewall for your instance to control inbound andoutbound traffic. When you launch an instance in the AWS Virtual Private Cloud(VPC), you can assign the instance up to five security groups. Security groups act atthe instance level, not the subnet level. Therefore, each instance in a subnet in yourVPC could be assigned to a different set of security groups. If you don't specify aparticular group at launch time, the instance is automatically assigned to the defaultsecurity group for the VPC.

For each security group, you add rules that control the inbound traffic to instances,and a separate set of rules that control the outbound traffic.

The SG associated with the Web tier ELB should allow connectivity from any sourceIP (0.0.0.0/0) only for the HTTP (TCP 80) and HTTPS (TCP 443) ports.


• First remove all the ingress rules for the security group associated with the Webtier ELB:aws ec2 describe-security-groups --group-id <security_group_id> --query"SecurityGroups[0].IpPermissions" > /tmp/IpPermissions.json

aws ec2 revoke-security-group-ingress --group-id <security_group_id> --ip-permissions file:///tmp/IpPermissions.json

• create locally the below json file containing ingress rules for any source IP(0.0.0.0/0) only for the HTTP (TCP 80) and HTTPS (TCP 443) ports and name itIpPermissions.json:[ { "PrefixListIds": [], "FromPort": 80, "IpRanges": [ { "CidrIp": "0.0.0.0/0" } ], "ToPort": 80, "IpProtocol": "tcp", "UserIdGroupPairs": [] }, { "PrefixListIds": [], "FromPort": 443, "IpRanges": [ { "CidrIp": "0.0.0.0/0" } ], "ToPort": 443, "IpProtocol": "tcp", "UserIdGroupPairs": [] }]

• Add to the security group associated with the Web tier ELB the above ingressrules:aws ec2 authorize-security-group-ingress --group-id <security_group_id> --ip-permissions file:///PathTo/IpPermissions.json


Do not use Web tier ELB Security Groupin the Auto Scaling launch configurationof any other tier (Web, App)

When you use the AWS Management Console to create a load balancer in a VPC,you can choose an existing security group for the VPC or create a new securitygroup for the VPC. If you choose an existing security group, it must allow traffic inboth directions to the listener and health check ports for the load balancer. If youchoose to create a security group, the console automatically adds rules to allow alltraffic on these ports.

Be sure to review the security group rules to ensure that they allow traffic on thelistener and health check ports for the new load balancer. When you delete your loadbalancer, this security group is not deleted automatically.

If you add a listener to an existing load balancer, you must review your securitygroups to ensure they allow traffic on the new listener port in both directions.

The web-tier ELB is the only one that is public facing and should have rules to allowinbound traffic to the application ports (ex: HTTP and HTTPS) from any IP source(0.0.0.0/0).

The outbound security group rules for the web-tier ELB should be restricted to onlythe backend web-server instances for the appropriate application ports.

Associating the web-tier ELB security group to any other instances that shouldn't bepublicly accessible exposes them to unauthorized access.


• Create new launch configuration using the correct security groups for Weband/or App tier:aws autoscaling create-launch-configuration --launch-configuration-name<web_tier_launch_config> --image-id <web_tier_ami> --key-name <your_key_pair> --security-groups <web_tier_security_group>/<app_tier_security_group --instance-type <desired_instance_type> --iam-instance-profile<web_tier_instance_profile>/<app_tier_instance_profile>


Create the App tier ELB Security Groupto only accept HTTP/HTTPS

A security group acts as a virtual firewall for your instance to control inbound andoutbound traffic. When you launch an instance in the AWS Virtual Private Cloud(VPC), you can assign the instance to up to five security groups. Security groups actat the instance level, not the subnet level. Therefore, each instance in a subnet inyour VPC could be assigned to a different set of security groups. If you don't specifya particular group at launch time, the instance is automatically assigned to thedefault security group for the VPC.


The SG associated with the App tier ELB should allow connectivity from the securitygroup associated with Web tier instances only for the HTTP (TCP 80) and HTTPS(TCP 443) ports.

The defaults for HTTP and HTTPS are used as an example, any other ports wouldapply depending on the application design.


• First remove all the ingress rules for the security group associated with the Apptier ELB:aws ec2 describe-security-groups --group-id app_tier_elb_security_group --query"SecurityGroups[0].IpPermissions" > /tmp/IpPermissions.json

aws ec2 revoke-security-group-ingress --group-id app_tier_elb_security_group --ip-permissions file:///tmp/IpPermissions.json

• create locally the below json file containing ingress rules for HTTP (TCP 80) andHTTPS (TCP 443) ports only from and name it IpPermissions.json:[ { "PrefixListIds": [], "FromPort": 80, "IpRanges": [], "ToPort": 80, "IpProtocol": "tcp", "UserIdGroupPairs": [ { "UserId": "<aws_account_number>", "GroupId": "<web_tier_security_group" } ] }, { "PrefixListIds": [], "FromPort": 443, "IpRanges": [], "ToPort": 443, "IpProtocol": "tcp", "UserIdGroupPairs": [ { "UserId": "<aws_account_number>", "GroupId": "<web_tier_security_group>" } ] }]

• Add to the security group associated with the App tier ELB the above ingressrules:aws ec2 authorize-security-group-ingress --group-id app_tier_elb_security_group --ip-permissions file:///PathTo/IpPermissions.json


Create the App tier Security Group toallow inbound connections from App tierELB Security Group for explicit ports

A security group acts as a virtual firewall for your instance to control inbound andoutbound traffic. When you launch an instance in the AWS Virtual Private Cloud(VPC), you can assign the instance to up to five security groups. Security groups actat the instance level, not the subnet level. Therefore, each instance in a subnet inyour VPC could be assigned to a different set of security groups. If you don't specifya particular group at launch time, the instance is automatically assigned to thedefault security group for the VPC.


This is required for both the configured port and protocol for the listener on the back-end instance and the port and protocol used for the health check.

This protects the App-server tier from unauthorized access, it is recommended toadd inbound security group rules that allow traffic for the specific application protocoland ports by referencing as source the security group associated with the App tierELB.


• First remove all the ingress rules for the App tier security group (use the"AppTierSecurityGroup" element from Audit procedure):aws ec2 describe-security-groups --group-id app_tier_security_group --query"SecurityGroups[0].IpPermissions" > /tmp/IpPermissions.json

aws ec2 revoke-security-group-ingress --group-id app_tier_security_group --ip-permissions file:///tmp/IpPermissions.json

• Add an ingress rule for a specific port, using --source-group option to specify theApp tier ELB security group as the source of the connections:aws ec2 authorize-security-group-ingress --group-id app_tier_security_group --protocol tcp --port specific_port --source-group app_tier_elb_security_group


Create the App tier ELB as Internal

An internal load balancer routes traffic to your EC2 instances in private subnetsusing private IP addresses.

Create an internal load balancer and register the database servers with it. The webservers receive requests from the Internet-facing load balancer and send requestsfor the database servers to the internal load balancer. The database servers receiverequests from the internal load balancer.

When an internal load balancer is created, it receives a public DNS name with thefollowing form:

internal-name-123456789.region.elb.amazonaws.com

The DNS servers resolve the DNS name of your load balancer to the private IPaddresses of the load balancer nodes for your internal load balancer. Each loadbalancer node is connected to the private IP addresses of the back-end instancesthat are in its Availability Zone using elastic network interfaces.

Creating the App tier ELB as internal will prevent access to the app tier from theInternet and will allow access from the Web tier instances.


• Create new internal ELB for your App tier:aws elb create-load-balancer --load-balancer-name app_tier_elb --scheme internal --listeners listener_config --subnets app_tier_subnet1 app_tier_subnet2 --security-groups app_tier_elb_security_group

• Register App tier instances with the new App tier ELB:aws elb register-instances-with-load-balancer --load-balancer-name app_tier_elb --instances <app_tier_instance1> <app_tier_instance2> <app_tier_instance3>

Create subnets for the Web Tier ELB

You can create a VPC that spans multiple Availability Zones. After creating a VPC,you can add one or more subnets in each Availability Zone. Each subnet must resideentirely within one Availability Zone and cannot span zones. Availability Zones aredistinct locations that are engineered to be isolated from failures in other AvailabilityZones. By launching instances in separate Availability Zones, you can protect yourapplications from the failure of a single location. AWS assigns a unique ID to eachsubnet.

When you create a subnet, you specify the CIDR block for the subnet. The CIDRblock of a subnet shouldn't be the same as the CIDR block for the VPC (for a singlesubnet in the VPC). The allowed block size is between a /28 netmask and /16netmask. If you create more than one subnet in a VPC, the CIDR blocks of thesubnets must not overlap.

Some AWS regions have more than 2 availability zones and it is recommended touse more than 2 where possible.

At least 2 subnets in 2 different availability zones (AZ) should be created in order tohave fault tolerance and high availability from the perspective of resourcedeployment.


• Create subnets for Web tier ELB, and note the subnet id:aws ec2 create-subnet --vpc-id application_vpc --cidr-block desired_cidr

• Tag the above subnets with the Web tier ELB tags:aws ec2 create-tags --resources web_tier_elb_subnet1 web_tier_elb_subnet2 --tagsKey=public_tier_tag,Value=public_tier_tag_value


Component: MySQL

Name Description

Use prepared statements for alldatabase queries

Database injection attacks, such as SQLi (SQL Injection) rely on sending taintedclient-side data which is used in dynamic SQL queries at the server-side in an unsafemanner. For example, creating queries by concatenating strings using untrusted datamay result in vulnerable code , for example an attacker may append an 'OR'statement through the provided customerName parameter passed to the followingcode to bypass the checks and return additional data from the database:

• String query = "SELECT user FROM users WHERE name = '"+ request.getParameter("customerName")+"'";Using prepared statements with carefully controlled and validated input conditionsmitigates against SQLi and related attacks.

• Database queries should always be made using prepared statements orparameterized queries. • Queries through an Object-Relational mapper should also be treated as taintedinput, and made using prepared statements to mitigate the threat.

Apply required security patches to theservice

Vendors and other maintainers of software release patches in response to securityflaws and other bugs in their products. The longer a system is exposed with a knownsecurity vulnerability, the easier to compromise it is as the exploit became public,they get included into automated exploitation suites like Metasploit and a wideraudience is able to exploit them.

• Apply patches and other software updates in a timely manner to preventunexpected failures or exploitation. • Clearly define an approach for testing and applying patches, in particularsecurity patches, with expected timescales. There is often a small window betweenrelease of a patch, and potentially malicious actors reverse-engineering the patch toidentify and exploit the flaw. • Use a threat intelligence, vulnerability scanning, or other alerting service toensure the project team is aware of issues within the project or its componentspromptly.

Access the data store from an accountwith the least privileges necessary

Use an account with only the minimum set of permissions required to access thedata store. The account should not be able to perform operations that are notexplicitly required by the component that performs these operations.For example, if a web application needs to read data from certain tables and insertand update data from others, then a database account with only those specificpermissions should be used by the application server.

Restrict access to the service at thenetwork layer to reduce exposure

Access to services should be restricted to expected sources, limiting exposure of theservice and its attack surface; and the likelihood of a malicious actor gaining accessto the system.

• Apply network layer security controls so that only the necessary and expected IPaddresses are permitted access to connect to the service.


Appendix A: Countermeasure DetailsThis appendix shows all of the countermeasures mitigating the threats found in the project.

Component: API GW

Name DescriptionId State Result

Implement applicationand network ratelimiting

A number of attacks rely on brute-forcetechniques to send large volumes of requests toenumerate or attempt to exploit flaws in anapplication, for example, sending commonpasswords to multiple target accounts within anapplication. By profiling normal traffic volumes,and applying rate limiting, the application can bebuilt to actively mitigate such attacks.

• Connection rate-limiting based on thesource IP address can be used to restrict attacksagainst the authentication or registrationsystems. Multiple failures (or attempts) from asingle IP should result in temporarily blocking ordropping traffic from the source. Note howeverthat some corporate and ISP environment mayplace multiple valid and discrete clients behindthe same IP address, resulting in false-positives. • Attackers may use botnets and other IPmasking techniques to deliver attacks frommultiple sources to avoid IP based rate-limiting.To mitigate this class of attack, Indicators ofCompromise should be monitored (for example ahigher rate of login failures than usual), andappropriate actions taken. For example, whenthe application detects active brute-force attacks,a Web Application Firewall (WAF) or otherintermediate devices could be used to blockattacks sharing a signature from patternmatching or deep packet inspection (e.g. HTTPheaders or common passwords across multipleaccounts). Similarly, the application couldrespond by requiring a CAPTCHA, cookie, orJavascript challenge when an attack is detected.

Remediation:Implement the mechanisms to lockout accounts:

• When the application detects a set numberof failure login attempts, the account shall belocked for a certain time period. • When the application detects that anaccount is locked more times than usual, thisaccount shall be disabled. A disabled accountshall only be restored by an administrator. • When the application detects active brute-force attacks, the application shall require aCAPTCHA, cookie, or JavaScript challenge.

CWE-799 Rejected Not Tested

Detect and notify theusage of automatedtools or unusualbehavior

Don't allow users to manipulate a system orguess its behavior based on input or outputtiming and detect the usage of automated toolsor unusual behavior, such as actions notperformed in reasonable "human time" or otherabnormal time patterns.

When the usage of automated tools is detected,the application shall respond with denying theaccess and notifying the security group.

OTG-BUSLOGIC Rejected Not Tested


Prevent unauthorisedaccess to source codethrough the service

Access to the source-code for the applicationcan aid an attacker in determined bugs orvulnerabilities in the code or logic. For closed-source projects it is therefore important to controland restrict access to the source. Applicationservices may unexpectedly expose code, forexample a service providing files to a user couldbe manipulated to access source code ifimplemented insecurely.

• Ensure that source code is not inadvertentlydisclosed through misconfiguration orvulnerabilities in the service. • Check that configuration files are notdownloadable directly from the service, andcannot be read and viewed through the serviceitself. • Ensure backups, operating system, andversion control artifacts do not expose code.

CWE-541 Recommended Not Tested

Log details of useractions within thesystem

To maintain proper accountability, logs should bemaintained with sufficient information to trackuser actions within the system. These logsshould be forensically sound, non-repudiable,and contain comprehensive details aboutactivity. While the exact data for an event mayvary, the following should be captured at aminimum:

• Timestamps against a proven externalsource (e.g. an NTP server) • Origin, with this field we mark if the logs areprovided by a trusted or untrusted source. • Event, status, and/or error codes (withsensitive data masked as appropriate or notintroduced in logs) • Service, command, application or functionname and details • User or system account associated with anevent • Devices used (e.g. source and destinationIPs, terminal session ID, web browser, etc)Source: https://security.berkeley.edu/security-audit-logging-guideline

CDS-USER-TRACK Required Not Tested

Log and reject all datavalidation failures

Data validation failures, together with accesscontrol violations, are symptomatic of maliciousactivity where an attacker is attempting tosubvert the protections in place. It is thereforelikely that unexpected input detected by theapplication relates to an attack. Rejecting andlogging such activity, and ideally terminating thesession, increases the likelihood of detecting andinhibiting structured attacks against theapplication.

• Log all validation failures when rejectingrequests. • Ensure logged data is appropriatelysanitized and encoded to prevent attacks againstthe logs and subsequent access to them. • Terminate the offending user session toinhibit further attack. • Ensure errors returned to the client-side aregeneric to prevent an attacker enumerating thedefenses in place or gaining knowledge aboutthe back-end.

CSD-VAL-LOG Required Not Tested




Encrypt data betweenthe client andserver/service

Data passed between the client and servershould be protected by encryption in transit.

• Implement cryptographically strong TLSend-to-end encryption between the client andserver, terminating within a secure environmenton the server-side. • Consider use of client certificates to preventinterception of (or man-in-the-middle attacks on)the encrypted connection. • Alternatively, asymmetric (public-key)encryption could be utilized, although arecognized, proven, and testedimplementation/library should be used

CWE-319-TRANSPORT Required Not Tested

Use a synchronisedtime source

In order to correlate logs and data from differentinternal and external systems, and to preserveforensic quality of the logs, it is important aunified and trusted synchronized time source isused throughout the environment.

• Servers should be synchronize to an internalor external NTP server • The centralized source should in turn use(or be) a trusted central time source.This control is critical in identifying applicationevents (including attacks) through logging, and inconduction post-event analysis, in particular totrack the whole user (or attacker) journeythrough the system should it be compromised.

It is good practice to use the concept ofIndicators of Compromise (IoC) should be usedto detect possible situations in which the systemhas been compromised and to give anappropriate response. IoCs are often trackedthrough logs, and accurate time is oftenessential.

CWE-662 Required Not Tested


Validate all datareceived from the clientside

All data received from the client-side should beconsidered tainted and a potential risk,regardless of the source or transport method. For example, while hidden form fields, cookies,or other headers may be obfuscated from a user,along with parameters passed in ViewStates orother encapsulated forms, these can be modifiedby the user at the client-side in memory, or intransit on the network. Similarly, data passedfrom binary or compiled components can bemodified in situ or in transit.

Furthermore, encryption only secures the data intransit between the two ends of the encryptedtunnel (one end of which is typically controlled bythe client); data passing through the link may stillbe malicious.

As such, all data from the client side must besubjected to strict validation, sanitization, andencoding against expected syntactic andsemantic criteria.

• Define a specification of the data that isexpected at each input; both the syntax (e.g.alphanumeric only) and semantics (e.g. a wordof between 1 and 25 characters, or a specificlist). As an example of business rule logic, "boat"may be syntactically valid because it onlycontains alphanumeric characters, but it is notvalid if the input is only expected to containcolors such as "red" or "blue." • Implement a 'known good' or white-listapproach, where only inputs that meet the strictcriteria for each input are accepted, and reject,transform, or encapsulate any non-compliantdata. • While useful for identifying maliciouscontent, do not rely on looking for specificmalformed or attack payloads (blacklists). It isalmost impossible to maintain a comprehensiveand accurate blacklist due to the complexity andevolving nature of attacks, opportunities toobfuscate payloads, and changes to the code'sexecution environment. As noted, blacklists canbe useful for detecting and logging potentialattacks, or determining which inputs are somalformed that they should be rejected outright. • Validate all data received from the client,including values such as HTTP headers andcookie values if these are used as input on theserver side, X- headers, and other platformspecific data objects passed between the clientand server.

DATA-VAL Required Not Tested

Log the backend TLSconnection failures

Implement functionality to record backend TLSconnection failures and include these in the logs.

LOG-TLS-FAILURES Required Not Tested

Ensure the integrity ofthe logging system

Ensure Log integrity for the applicationgenerated logs, such as storing logs on write-once media, forwarding a copy of the logs to acentralized SIEM or generating message digestsfor each log file.

LOGS-INTEGRITY Required Not Tested

Limit the number ofaccounts withprivileges allowingmodification and/ordeletion of audit logsfiles

Limit the number of account with privileges tomodify and/or delete audit logs files.

RESTRICT-NUMBER-ACCOUNT-TO-LOGS

Required Failed

Ensure that the client-side and the server-side are using thesame encoding style

Ensure that the client-side and the server-sideare using the same encoding style.

SAME-ENCODING-STYLE

Required Not Tested


Escape meta-characters from un-trusted data

If untrusted data, including any data receivedfrom the client side of a connection is directlywritten to a log file, then this data could containnewline or other meta-characters that wouldallow an attacker to forge log entries.Such meta-characters should first be escaped orremoved before the data is written to the loggingsystem.

ASVS-8.8 Implemented Passed

Do not write secrets tothe log files

The logs may be accessed by attackers and inorder to protect sensitive data, no such sensitivedata should be included in the logs

CWE-532 Implemented Not Tested

Develop a log retentionpolicy

Develop a log retention policy to identify storagerequirements for device logs and implementprocedures to ensure that the audit logs areavailable for a security response in the case ofincident or investigation.

The audit logs must be collected for the last 30days in easily accessible storage media. Olderlogs should be archived in a protected storageand should be accessible in the future asrequired for incidents or investigations.

LOG-RETENTION Implemented Not Tested

Restrict actions ofusers that followunusual patterns.

Restrict actions that users can do outside of theapproved/required business process flow.

This is important because without this safeguardin place attackers may be able to bypass orcircumvent work-flows and checks allowing themto prematurely enter or skip required sections ofthe application potentially allowingaction/transaction to be completed withoutsuccessfully completing the entire businessprocess, leaving the system with incompleteback-end tracking information.

OTG-BUSLOGIC-006

Implemented Not Tested


Component: ELB - Elastic Load Balancer


Use the PerfectForward Secrecyfeature

For greater communication privacy Elastic LoadBalancing allows the use of Perfect ForwardSecrecy. This feature provides additionalsafeguards against eavesdropping on encrypteddata, through the use of a unique randomsession key, and therefore prevents thedecoding of captured data, even if the secretlong-term key is compromised.

To begin using Perfect Forward Secrecy:Configure your load balancer with the newlyadded Elliptic Curve Cryptography (ECDHE)cipher suites.

Hydras-AWS-ELB-01 Recommended Not Tested

Select the Server OrderPreference option

Within Elastic Load Balancing ensure the use ofnewer and stronger cipher suites whenestablishing a new connection supporting theServer Order Preference option. When thisoption is selected, the load balancer selects thefirst cipher in its list that is in the client's list ofciphers.

Remediation:To enable Server Order Preference:

• Open the Amazon EC2 console. • Under LOAD BALANCING, choose LoadBalancers.

• Select your Load Balancer.

• On the Listeners tab, for Cipher, chooseChange.

• On the Select a Cipher page, select CustomSecurity Policy.

• For SSL Options, select Server OrderPreference.

• Click Save.

Hydras-AWS-ELB-02 Recommended Not Tested


Use HTTPS listener forWeb Tier ELB

A load balancer takes requests from clients anddistributes them across the EC2 instances thatare registered with the load balancer (alsoknown as back-end instances).

A listener is a process that checks for connectionrequests. It is configured with a protocol and aport for front-end (client to load balancer)connections

Note: an HTTPS listener configured on the ELBis not mandatory if you are terminating SSLconnections directly on the Web Tier EC2instances, and using a TCP listener on the ELB(TCP pass-through)

Using an HTTPS Elastic Load Balancer listenerwill make sure the application traffic between theclient and the Web Tier ELB is encrypted overthe SSL\TLS channel.

Remediation:Using the Amazon unified command lineinterface:

• If the ListenerDescription field is missing,add a new HTTPS listener configured with aSSL\TLS certificate (the listener forwards trafficto the backend instances on port 80, but this canbe modified by editing InstancePort=80):aws elb create-load-balancer-listeners --load-balancer-name <web_tier_elb> --listenersProtocol=HTTPS,LoadBalancerPort=443,InstanceProtocol=HTTP,InstancePort=80,SSLCertificateId=ssl_certificate_arn

aws-tier-1.1 Recommended Not Tested


Configure the latestSSL Security Policiesfor Web Tier ELB

Elastic Load Balancing uses an Secure SocketLayer (SSL) negotiation configuration, known asa security policy, to negotiate SSL/TLSconnections between a client and the loadbalancer. A security policy is a combination ofSSL/TLS protocols, ciphers, and the ServerOrder Preference option.

Elastic Load Balancing supports configuring yourload balancer to use either predefined or customsecurity policies.

Secure Sockets Layer (SSL) and TransportLayer Security (TLS) are cryptographic protocolsthat are used to encrypt confidential data overinsecure networks such as the Internet. The TLSprotocol is a newer version of the SSL protocol.In the Elastic Load Balancing documentation, werefer to both SSL and TLS protocols as the SSLprotocol.

Note: an SSL certificate configured on the ELBand an SSL Security Policy is not mandatory ifyou are terminating SSL connections directly onthe Web Tier EC2 instances, and using a TCPlistener on the ELB (TCP pass-through)

Making sure the latest ELB SSL Security Policyis used will ensure the SSL/TLS connection willbe negotiated using only the appropriatecryptographic protocols deemed safe with noproven vulnerabilities.

Remediation:Using the Amazon unified command lineinterface:(Note that you should replace <web\_tier\_elb>with your Web-tier ELB name, and_<latest\_ssl\_policy>_ with the proper policyname)

aws elb set-load-balancer-policies-of-listener --load-balancer-name <web_tier_elb> --load-balancer-port 443 --policy-names <latest_ssl_policy>



Add SSL/TLSCertificate to App TierELB

When you use HTTPS for your front-end listener,you must deploy an SSL/TLS certificate on yourload balancer. The load balancer uses thecertificate to terminate the connection and thendecrypt requests from clients before sendingthem to the back-end instances.

The SSL\TLS protocol uses an X.509 certificate(SSL\TLS server certificate) to authenticate boththe client and the back-end application. An X.509certificate is a digital form of identification issuedby a trusted certificate authority (CA) andcontains identification information, a validityperiod, a public key, a serial number, and thedigital signature of the issuer.

You can create a certificate using a Third PartyCertificate Authority, AWS Certificate Manager ora self signed certificate like OpenSSL.

Note: an SSL certificate configured on the ELB isnot mandatory if you are terminating SSLconnections directly on the App Tier EC2instances, and using a TCP listener on the ELB(TCP pass-through)

All the application traffic between the Web Tierinstances and the App Tier ELB nodes should beencrypted using an SSL\TLS certificate.Remediation:

Using the Amazon unified command lineinterface:

• Adding a HTTPS listener configured with aSSL\TLS certificate (the listener forwards trafficto the backend instances on port 80, but this canbe modified by editing InstancePort=80):

aws elb create-load-balancer-listeners --load-balancer-name <app_tier_elb> --listenersProtocol=HTTPS,LoadBalancerPort=443,InstanceProtocol=HTTP,InstancePort=80,SSLCertificateId=ssl_certificate_arn



Configure the latestSSL Security Policiesfor App Tier ELB

Elastic Load Balancing uses an Secure SocketLayer (SSL) negotiation configuration, known asa security policy, to negotiate SSL/TLSconnections between a client and the loadbalancer. A security policy is a combination ofSSL/TLS protocols, ciphers, and the ServerOrder Preference option.

Elastic Load Balancing supports configuring yourload balancer to use either predefined or customsecurity policies.

Secure Sockets Layer (SSL) and TransportLayer Security (TLS) are cryptographic protocolsthat are used to encrypt confidential data overinsecure networks such as the Internet. The TLSprotocol is a newer version of the SSL protocol.In the Elastic Load Balancing documentation, werefer to both SSL and TLS protocols as the SSLprotocol.

Note: an SSL certificate configured on the ELBand an SSL Security Policy is not mandatory ifyou are terminating SSL connections directly onthe App Tier EC2 instances, and using a TCPlistener on the ELB (TCP pass-through)

Making sure the latest ELB SSL Security Policyis used will ensure the SSL/TLS connection willbe negotiated using only the appropriatecryptographic protocols deemed safe with noproven vulnerabilities.


• (Note that you should replace<app\_tier\_elb> with your App-tier ELB name,and <latest\_ssl\_policy> with the proper policyname)aws elb set-load-balancer-policies-of-listener --load-balancer-name <app_tier_elb> --load-balancer-port 443 --policy-names <latest_ssl_policy>



Use HTTPS listener forApp Tier ELB

A load balancer takes requests from clients anddistributes them across the EC2 instances thatare registered with the load balancer (alsoknown as back-end instances).

A listener is a process that checks for connectionrequests. It is configured with a protocol and aport for front-end (client to load balancer)connections.

Note: an HTTPS listener configured on the ELBis not mandatory if you are terminating SSLconnections directly on the App Tier EC2instances, and using a TCP listener on the ELB(TCP pass-through)

Using an HTTPS Elastic Load Balancer listenerwill make sure the application traffic between theclient and the App Tier ELB is encrypted over theSSL\TLS channel.


• If the ListenerDescription field is missing,add a new HTTPS listener configured with aSSL\TLS certificate (the listener forwards trafficto the backend instances on port 80, but this canbe modified by editing InstancePort=80):aws elb create-load-balancer-listeners --load-balancer-name <app_tier_elb> --listenersProtocol=HTTPS,LoadBalancerPort=443,InstanceProtocol=HTTP,InstancePort=80,SSLCertificateId=ssl_certificate_arn



Add SSL/TLSCertificate to Web TierELB

When you use HTTPS for your front-end listener,you must deploy an SSL/TLS certificate on yourload balancer. The load balancer uses thecertificate to terminate the connection and thendecrypt requests from clients before sendingthem to the back-end instances.

The TLS protocol uses an X.509 certificate(SSL/TLS server certificate) to authenticate boththe client and the back-end application. An X.509certificate is a digital form of identification issuedby a trusted certificate authority (CA) andcontains identification information, a validityperiod, a public key, a serial number, and thedigital signature of the issuer.

You can create a certificate using a Third PartyCertificate Authority or AWS Certificate Manager.

Note: an SSL certificate configured on the ELB isnot mandatory if you are terminating SSLconnections directly on the Web Tier EC2instances, and using a TCP listener on the ELB(TCP pass-through)

All the application traffic between the clients andthe Web Tier ELB nodes should be encryptedusing a SSL/TLS certificate.


• Adding a HTTPS listener configured with aSSL/TLS certificate (the listener forwards trafficto the backend instances on port 80, but this canbe modified by editing InstancePort=80):aws elb create-load-balancer-listeners --load-balancer-name <web_tier_elb> --listenersProtocol=HTTPS,LoadBalancerPort=443,InstanceProtocol=HTTP,InstancePort=80,SSLCertificateId=ssl_certificate_arn



Associate each Auto-Scaling Group to ELB

Elastic Load Balancing automatically distributesincoming application traffic across multipleAmazon EC2 instances within a VPC.

It enables greater levels of fault tolerance in yourapplications, seamlessly providing the requiredamount of load balancing capacity needed todistribute application traffic across 1 or moreAvailability Zones within a VPC.

Elastic Load Balancing must be integrated withAuto Scaling Groups to ensure that you haveavailability of compute resources in the event ofa failure.

Integrating Auto Scaling Groups with an ElasticLoad Balancer will help provide high availabilityand back-end EC2 instance scaling.

Through Auto-Scaling Group configuration youcan define:minimum / maximum number of EC2 instancesto be launched by the Auto-Scaling GroupAvailability Zones / subnets used



or

• Create new load balancer:aws elb create-load-balancer --load-balancer-name <elb_name> --listeners <listener_config> --subnets <application_subnet> --security-groups<application_security_groups>

• Attached load balancer from previous stepsto autoscaling group:aws autoscaling attach-load-balancers --load-balancer-names <elb_name> --auto-scaling-group-name <autoscaling_group_name>



Set a HTTPSconnection from allCloudFrontDistributions to theWeb Tier ELB origin

Configure the Origin Protocol Policy for the Webtier ELB origin either to require that CloudFrontfetches objects from your origin by using HTTPSor to require that CloudFront uses the protocolthat the viewer used to request the objects. Forexample, if you choose Match Viewer for theOrigin Protocol Policy and the viewer usesHTTPS to request an object from CloudFront,CloudFront also uses HTTPS to forward therequest to your origin.

In order to use HTTPS, an SSL\TLS certificatemust be attached.

To ensure that objects are encrypted from edgelocations to the Web-Tier ELB origin according tothe data classification policy, use Match Viewer.


• For configuring "OriginProtocolPolicy"firstsave locally the current distribution config:aws cloudfront get-distribution-config --idapplication_cfn_distribution_id --query"DistributionConfig" > /tmp/cf-distribution.json

Edit and replace "OriginProtocolPolicy"elementin /tmp/cf-distribution.json with the below section:"OriginProtocolPolicy": "https-only",

• Retrieve the current ETag of yourCloudFront distribution:aws cloudfront get-distribution-config --id<application_cfn_distribution_id> --query "ETag"

• Update the CloudFront distribution using theedited config and the above Etag:aws cloudfront update-distribution --id<application_cfn_distribution_id> --distribution-config file:///tmp/cf-distribution.json --if-match<application_cfn_distribution_etag>



Associate Web TierAuto-Scaling Group toELB







• List existing load balancers:aws elb describe-load-balancers --query'LoadBalancerDescriptions[*].{ELBName:LoadBalancerName}'or

• Create new load balancer:aws elb create-load-balancer --load-balancer-name <web_tier_elb> --listeners<listener_config> --subnets<web_tier_elb_subnet1><web_tier_elb_subnet2> --security-groups<web_tier_elb_security_group>

• Attached load balancer from previous stepsto autoscaling group:aws autoscaling attach-load-balancers --load-balancer-names <web_tier_elb> --auto-scaling-group-name<web_tier_autoscaling_group_name>



Associate App TierAuto-Scaling Group toELB








or

• Create new load balancer:aws elb create-load-balancer --load-balancer-name <app_tier_elb> --scheme internal --listeners <listener_config> --subnets<app_tier_subnet1> <app_tier_subnet2> --security-groups <app_tier_elb_security_group>

• Attached load balancer from previous stepsto autoscaling group:aws autoscaling attach-load-balancers --load-balancer-names <app_tier_elb> --auto-scaling-group-name<app_tier_autoscaling_group_name>



Configure HealthCheck for Web TierELB

By default, an Auto-Scaling Group periodicallyuses the results of the EC2 instance statuschecks to determine the health status of eachinstance. If an instance fails the EC2 instancestatus checks, Auto-Scaling marks the instanceas unhealthy and replaces the instance.

However, if you have attached one or moreElastic Load Balancing (ELB) load balancers toyour Auto-Scaling Group and the instance failsthe ELB health checks, Auto-Scaling does notreplace the instance.

Amazon ELB will periodically sends pings,attempt connections, or sends requests to testthe EC2 instances, these tests are called healthchecks.

The status of the instances that are healthy atthe time of the health check is InService.

The status of any instances that are unhealthy atthe time of the health check is OutOfService.

The load balancer performs health checks on allregistered instances, whether the instance is in ahealthy state or an unhealthy state. The loadbalancer routes requests only to the healthyinstances. When the load balancer determinesthat an instance is unhealthy, it stops routingrequests to that instance. The load balancerresumes routing requests to the instance when ithas been restored to a healthy state

Ensure availability of back-end EC2 instancesassociated with an Amazon ELB throughapplication layer health check (ex: http) insteadof TCP health checks.


• Create a JSON file containing the attributesyou want to modify and save it locally as/tmp/ELBhealthcheck.json:{ "Target": "<string>", "Interval": <integer>, "Timeout": <integer>, "UnhealthyThreshold": <integer>, "HealthyThreshold": <integer>}

• Modify Web tier ELB to include appropriatehealth check:aws elb configure-health-check --load-balancer-name <web_tier_elb> --health-checkfile:///tmp/ELBhealthcheck.json



Configure HealthCheck for App Tier ELB

By default, an Auto-Scaling Group periodicallyuses the results of the EC2 instance statuschecks to determine the health status of eachinstance. If an instance fails the EC2 instancestatus checks, Auto-Scaling marks the instanceas unhealthy and replaces the instance.

However, if you have attached one or moreElastic Load Balancing (ELB) load balancers toyour Auto-Scaling Group and the instance failsthe ELB health checks, Auto-Scaling does notreplace the instance.

Amazon ELB will periodically sends pings,attempts connections, or sends requests to testthe EC2 instances, these tests are called healthchecks.

The status of the instances that are healthy atthe time of the health check is InService.

The status of any instances that are unhealthy atthe time of the health check is OutOfService.

The load balancer performs health checks on allregistered instances, whether the instance is in ahealthy state or an unhealthy state. The loadbalancer routes requests only to the healthyinstances. When the load balancer determinesthat an instance is unhealthy, it stops routingrequests to that instance. The load balancerresumes routing requests to the instance when ithas been restored to a healthy state

Ensures availability of back-end EC2 instancesassociated with an Amazon ELB throughapplication layer health check (ex: http) insteadof TCP health checks.


• Create a JSON file containing the attributesyou want to modify and save it locally as/tmp/ELBhealthcheck.json:{ "Target": "<string>", "Interval": <integer>, "Timeout": <integer>, "UnhealthyThreshold": <integer>, "HealthyThreshold": <integer>}

• Modify App tier ELB to include appropriatehealth check:aws elb configure-health-check --load-balancer-name <app_tier_elb> --health-checkfile:///tmp/ELBhealthcheck.json



Enable the ELB logging

Elastic Load Balancing automatically distributesincoming application traffic across multipleAmazon EC2 instances in the a VPC. It enablesyou to achieve greater levels of fault tolerance inyour applications, seamlessly providing therequired amount of load balancing capacityneeded to distribute application traffic.

AWS Elastic Load Balancers (ELBs) can recordall incoming requests sent to the load balancerand store within logs on S3. This allows fordiagnosing application failures and analyzingweb traffic and security analysis of incomingtraffic


• Create a JSON file containing the attributesyou want to modify and save it locally as/tmp/ElbLogs.json:{"AccessLog": { "Enabled": true, "S3BucketName": "string", "EmitInterval": integer, "S3BucketPrefix": "string" }}

• Update the Load Balancer attributes:aws elb modify-load-balancer-attributes --load-balancer-name <elb_name> --load-balancer-attributes file:///tmp/ElbLogs.json



Set Root Domain AliasRecord to ELB

Amazon Route 53 translates friendly domainsnames like www.example.com into IP addresseslike 192.0.2.1. Amazon Route 53 responds toDNS queries using a global network ofauthoritative DNS servers, which reduceslatency.

When someone enters your domain name in abrowser, a DNS request is forwarded to thenearest Amazon Route 53 DNS server in aglobal network of authoritative DNS servers.Amazon Route 53 responds with the IP addressthat you specified.

Each domain has an associated hosted zonewhich contains the resource records pointing toeach layer of the application.

A private hosted zone is a container that holdsinformation about how you want to route trafficfor a domain and its subdomains within theAmazon Virtual Private Cloud (Amazon VPC). Tobegin, you create a private hosted zone andspecify the Amazon VPCs that you want toassociate with the hosted zone. You then createresource record sets that determine howAmazon Route 53 responds to queries for yourdomain and subdomains within and among yourAmazon VPCs.

Route53 provides special record type calledAlias that allows creation of an A record for theroot domain and points it to the fully qualifieddomain of the Elastic Load Balancer (ELB)associated with the web-server layer or AmazonCloudFront.

In the same way records for all other layersshould be created in order to allow flexibility inthe application design and not hard-code theFQDN of a resource.


• Create a hosted zone for YourDomain.com:aws route53 create-hosted-zone --name<your_domain.com> --caller-reference<any_string>



Allow connectivity tothe VPC InternetGateway (IGW) andassociate the RoutingTable with Web tierELB subnet (by defaultroute (0.0.0.0/0))

A route table contains a set of rules, calledroutes, that are used to determine wherenetwork traffic is directed.

Each subnet in your VPC must be associatedwith a route table; the table controls the routingfor the subnet. A subnet can only be associatedwith one route table at a time, but you canassociate multiple subnets with the same routetable.

The default route (0.0.0.0/0) should be pointingto the Internet Gateway in order to provideinternet connectivity for the Web tier ELB.


• For the above route tables, if the defaultroute (0.0.0.0/0) exists but it doesn't have anIGW configured as gateway:aws ec2 replace-route --route-table-id<route_table_id> --destination-cidr-block0.0.0.0/0 --gateway-id <vpc_igw>

• For the above route tables, if the defaultroute (0.0.0.0/0) doesn't exist:aws ec2 create-route --route-table-id<route_table_id> --destination-cidr-block0.0.0.0/0 --gateway-id <vpc_igw>



Use a Web-Tier ELBSecurity Group toaccept onlyHTTP/HTTPS

A security group acts as a virtual firewall for yourinstance to control inbound and outbound traffic.When you launch an instance in the AWS VirtualPrivate Cloud (VPC), you can assign theinstance up to five security groups. Securitygroups act at the instance level, not the subnetlevel. Therefore, each instance in a subnet inyour VPC could be assigned to a different set ofsecurity groups. If you don't specify a particulargroup at launch time, the instance isautomatically assigned to the default securitygroup for the VPC.

For each security group, you add rules thatcontrol the inbound traffic to instances, and aseparate set of rules that control the outboundtraffic.

The SG associated with the Web tier ELB shouldallow connectivity from any source IP (0.0.0.0/0)only for the HTTP (TCP 80) and HTTPS (TCP443) ports.


• First remove all the ingress rules for thesecurity group associated with the Web tier ELB:aws ec2 describe-security-groups --group-id<security_group_id> --query"SecurityGroups[0].IpPermissions" >/tmp/IpPermissions.json

aws ec2 revoke-security-group-ingress --group-id <security_group_id> --ip-permissionsfile:///tmp/IpPermissions.json

• create locally the below json file containingingress rules for any source IP (0.0.0.0/0) onlyfor the HTTP (TCP 80) and HTTPS (TCP 443)ports and name it IpPermissions.json:[ { "PrefixListIds": [], "FromPort": 80, "IpRanges": [ { "CidrIp": "0.0.0.0/0" } ], "ToPort": 80, "IpProtocol": "tcp", "UserIdGroupPairs": [] }, { "PrefixListIds": [], "FromPort": 443, "IpRanges": [ { "CidrIp": "0.0.0.0/0" } ], "ToPort": 443, "IpProtocol": "tcp", "UserIdGroupPairs": [] }]

• Add to the security group associated withthe Web tier ELB the above ingress rules:aws ec2 authorize-security-group-ingress --group-id <security_group_id> --ip-permissions



Do not use Web tierELB Security Group inthe Auto Scaling launchconfiguration of anyother tier (Web, App)

When you use the AWS Management Consoleto create a load balancer in a VPC, you canchoose an existing security group for the VPC orcreate a new security group for the VPC. If youchoose an existing security group, it must allowtraffic in both directions to the listener and healthcheck ports for the load balancer. If you chooseto create a security group, the consoleautomatically adds rules to allow all traffic onthese ports.

Be sure to review the security group rules toensure that they allow traffic on the listener andhealth check ports for the new load balancer.When you delete your load balancer, thissecurity group is not deleted automatically.

If you add a listener to an existing load balancer,you must review your security groups to ensurethey allow traffic on the new listener port in bothdirections.

The web-tier ELB is the only one that is publicfacing and should have rules to allow inboundtraffic to the application ports (ex: HTTP andHTTPS) from any IP source (0.0.0.0/0).

The outbound security group rules for the web-tier ELB should be restricted to only the backendweb-server instances for the appropriateapplication ports.

Associating the web-tier ELB security group toany other instances that shouldn't be publiclyaccessible exposes them to unauthorizedaccess.


• Create new launch configuration using thecorrect security groups for Web and/or App tier:aws autoscaling create-launch-configuration --launch-configuration-name<web_tier_launch_config> --image-id<web_tier_ami> --key-name <your_key_pair> --security-groups<web_tier_security_group>/<app_tier_security_group --instance-type <desired_instance_type> --iam-instance-profile<web_tier_instance_profile>/<app_tier_instance_profile>



Create the App tierELB Security Group toonly acceptHTTP/HTTPS

A security group acts as a virtual firewall for yourinstance to control inbound and outbound traffic.When you launch an instance in the AWS VirtualPrivate Cloud (VPC), you can assign theinstance to up to five security groups. Securitygroups act at the instance level, not the subnetlevel. Therefore, each instance in a subnet inyour VPC could be assigned to a different set ofsecurity groups. If you don't specify a particulargroup at launch time, the instance isautomatically assigned to the default securitygroup for the VPC.


The SG associated with the App tier ELB shouldallow connectivity from the security groupassociated with Web tier instances only for theHTTP (TCP 80) and HTTPS (TCP 443) ports.

The defaults for HTTP and HTTPS are used asan example, any other ports would applydepending on the application design.


• First remove all the ingress rules for thesecurity group associated with the App tier ELB:aws ec2 describe-security-groups --group-idapp_tier_elb_security_group --query"SecurityGroups[0].IpPermissions" >/tmp/IpPermissions.json

aws ec2 revoke-security-group-ingress --group-id app_tier_elb_security_group --ip-permissionsfile:///tmp/IpPermissions.json

• create locally the below json file containingingress rules for HTTP (TCP 80) and HTTPS(TCP 443) ports only from and name itIpPermissions.json:[ { "PrefixListIds": [], "FromPort": 80, "IpRanges": [], "ToPort": 80, "IpProtocol": "tcp", "UserIdGroupPairs": [ { "UserId":"<aws_account_number>", "GroupId": "<web_tier_security_group" } ] }, { "PrefixListIds": [], "FromPort": 443, "IpRanges": [], "ToPort": 443, "IpProtocol": "tcp", "UserIdGroupPairs": [ { "UserId":



"<aws_account_number>", "GroupId": "<web_tier_security_group>" } ] }]

• Add to the security group associated withthe App tier ELB the above ingress rules:aws ec2 authorize-security-group-ingress --group-id app_tier_elb_security_group --ip-permissions file:///PathTo/IpPermissions.json

Create the App tierSecurity Group to allowinbound connectionsfrom App tier ELBSecurity Group forexplicit ports

A security group acts as a virtual firewall for yourinstance to control inbound and outbound traffic.When you launch an instance in the AWS VirtualPrivate Cloud (VPC), you can assign theinstance to up to five security groups. Securitygroups act at the instance level, not the subnetlevel. Therefore, each instance in a subnet inyour VPC could be assigned to a different set ofsecurity groups. If you don't specify a particulargroup at launch time, the instance isautomatically assigned to the default securitygroup for the VPC.


This is required for both the configured port andprotocol for the listener on the back-end instanceand the port and protocol used for the healthcheck.

This protects the App-server tier fromunauthorized access, it is recommended to addinbound security group rules that allow traffic forthe specific application protocol and ports byreferencing as source the security groupassociated with the App tier ELB.


• First remove all the ingress rules for the Apptier security group (use the"AppTierSecurityGroup" element from Auditprocedure):aws ec2 describe-security-groups --group-idapp_tier_security_group --query"SecurityGroups[0].IpPermissions" >/tmp/IpPermissions.json

aws ec2 revoke-security-group-ingress --group-id app_tier_security_group --ip-permissionsfile:///tmp/IpPermissions.json

• Add an ingress rule for a specific port, using--source-group option to specify the App tier ELBsecurity group as the source of the connections:aws ec2 authorize-security-group-ingress --group-id app_tier_security_group --protocol tcp --port specific_port --source-group



Create the App tierELB as Internal

An internal load balancer routes traffic to yourEC2 instances in private subnets using private IPaddresses.

Create an internal load balancer and register thedatabase servers with it. The web serversreceive requests from the Internet-facing loadbalancer and send requests for the databaseservers to the internal load balancer. Thedatabase servers receive requests from theinternal load balancer.

When an internal load balancer is created, itreceives a public DNS name with the followingform:

internal-name-123456789.region.elb.amazonaws.com

The DNS servers resolve the DNS name of yourload balancer to the private IP addresses of theload balancer nodes for your internal loadbalancer. Each load balancer node is connectedto the private IP addresses of the back-endinstances that are in its Availability Zone usingelastic network interfaces.

Creating the App tier ELB as internal will preventaccess to the app tier from the Internet and willallow access from the Web tier instances.


• Create new internal ELB for your App tier:aws elb create-load-balancer --load-balancer-name app_tier_elb --scheme internal --listenerslistener_config --subnets app_tier_subnet1app_tier_subnet2 --security-groupsapp_tier_elb_security_group

• Register App tier instances with the newApp tier ELB:aws elb register-instances-with-load-balancer --load-balancer-name app_tier_elb --instances<app_tier_instance1> <app_tier_instance2><app_tier_instance3>



Create subnets for theWeb Tier ELB

You can create a VPC that spans multipleAvailability Zones. After creating a VPC, you canadd one or more subnets in each AvailabilityZone. Each subnet must reside entirely withinone Availability Zone and cannot span zones.Availability Zones are distinct locations that areengineered to be isolated from failures in otherAvailability Zones. By launching instances inseparate Availability Zones, you can protect yourapplications from the failure of a single location.AWS assigns a unique ID to each subnet.

When you create a subnet, you specify the CIDRblock for the subnet. The CIDR block of a subnetshouldn't be the same as the CIDR block for theVPC (for a single subnet in the VPC). Theallowed block size is between a /28 netmask and/16 netmask. If you create more than one subnetin a VPC, the CIDR blocks of the subnets mustnot overlap.

Some AWS regions have more than 2 availabilityzones and it is recommended to use more than 2where possible.

At least 2 subnets in 2 different availability zones(AZ) should be created in order to have faulttolerance and high availability from theperspective of resource deployment.


• Create subnets for Web tier ELB, and notethe subnet id:aws ec2 create-subnet --vpc-id application_vpc --cidr-block desired_cidr

• Tag the above subnets with the Web tierELB tags:aws ec2 create-tags --resourcesweb_tier_elb_subnet1 web_tier_elb_subnet2 --tagsKey=public_tier_tag,Value=public_tier_tag_value



Component: MySQL


Restrict access to theservice at the networklayer to reduceexposure

Access to services should be restricted toexpected sources, limiting exposure of theservice and its attack surface; and the likelihoodof a malicious actor gaining access to thesystem.

• Apply network layer security controls so thatonly the necessary and expected IP addressesare permitted access to connect to the service.

RESTRICT-SERVICE Recommended Not Tested

Use preparedstatements for alldatabase queries

Database injection attacks, such as SQLi (SQLInjection) rely on sending tainted client-side datawhich is used in dynamic SQL queries at theserver-side in an unsafe manner. For example,creating queries by concatenating strings usinguntrusted data may result in vulnerable code , forexample an attacker may append an 'OR'statement through the provided customerNameparameter passed to the following code tobypass the checks and return additional datafrom the database:

• String query = "SELECT user FROM usersWHERE name = '"+ request.getParameter("customerName")+"'";Using prepared statements with carefullycontrolled and validated input conditionsmitigates against SQLi and related attacks.

• Database queries should always be madeusing prepared statements or parameterizedqueries. • Queries through an Object-Relationalmapper should also be treated as tainted input,and made using prepared statements to mitigatethe threat.

CWE-89-PREPARED Required Not Tested

Apply required securitypatches to the service

Vendors and other maintainers of softwarerelease patches in response to security flawsand other bugs in their products. The longer asystem is exposed with a known securityvulnerability, the easier to compromise it is asthe exploit became public, they get included intoautomated exploitation suites like Metasploit anda wider audience is able to exploit them.

• Apply patches and other software updates ina timely manner to prevent unexpected failuresor exploitation. • Clearly define an approach for testing andapplying patches, in particular security patches,with expected timescales. There is often a smallwindow between release of a patch, andpotentially malicious actors reverse-engineeringthe patch to identify and exploit the flaw. • Use a threat intelligence, vulnerabilityscanning, or other alerting service to ensure theproject team is aware of issues within the projector its components promptly.

PATCH-SERVICE Required Not Tested


Require authenticationbefore presentingrestricted data

The application should ensure users haveundergone an Identification and Verification(ID&V) process before allowing access to secret,sensitive or otherwise restricted data. For lesssensitive but still restricted data, simpleverification of the location of the user may suffice(e.g. IP restrictions).

• For non-sensitive but non-public data,access could be restricted by IP address, forexample limiting access to internal networks,workstations, or gateways • For more sensitive data, TLS client-sidecertificates may be appropriate • Where secret or other sensitive data ishandled, a full authentication process to identifyand validate users with single or multi-factorauthentication may be required

CWE-306-SERVICE Implemented Failed

Access the data storefrom an account withthe least privilegesnecessary

Use an account with only the minimum set ofpermissions required to access the data store. The account should not be able to performoperations that are not explicitly required by thecomponent that performs these operations.For example, if a web application needs to readdata from certain tables and insert and updatedata from others, then a database account withonly those specific permissions should be usedby the application server.

RESTRICT-ACCESS-DATABASE

Implemented Not Tested

Date post:	17-Jul-2020
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times

Technical Countermeasure Report · to preserve forensic quality of the logs, it is important a...

Documents