T1557 Adversary-in-the-Middle

This diagnostic statement provides for implementation of methods to block similar future attacks via security tools such as antivirus and IDS/IPS to provide protection against threats and exploitation attempts.

This diagnostic statement focuses on protecting data-at-rest by implementing encryption and other security measures such as sandboxing, authentication, segregation, masking, tokenization, and file integrity monitoring.

This diagnostic statement describes the implementation of least privilege principle, which can be applied to limiting permissions through role-based access controls, file and directory permissions, and the execution of systems and services. Limiting users' access to resources over network can help mitigate these techniques. Limit access to network infrastructure and resources that can be used to reshape traffic or otherwise produce AiTM conditions.

The use of network intrusion detection and prevention systems can identify and possibly bock traffic patterns, indicative of AiTM activity. If so, these patterns can be mitigated at the network level.

This diagnostic statement is associated with employing encryption methods to mitigate unauthorized access or theft of data that protect the confidentiality and integrity of data-at-rest, data-in-use, and data-in-transit. To address adversary-in-the-middle threats, the organization ensures that all wired and wireless traffic is encrypted appropriately, employs best practices for authentication protocols such as Kerberos, and protects web traffic containing credentials using SSL/TLS.

This diagnostic statement protects against Adversary-in-the-middle through the use of revocation of keys and key management. Employing key protection strategies for key material used in identity management and authentication processes over networks, limitations to specific accounts along with access control mechanisms provides protection against adversary-in-the-middle

This diagnostic statement prevents adversaries from being able to steal data in transit between networks. There may be some similarities to NIST 800-53 SI-12 Information Management and Retention. This may provide mitigation of data access/exfiltration techniques.

This diagnostic statement is for the implementation of network segmentation which helps prevent access to critical systems and sensitive information. Isolate infrastructure components and blocking network traffic that is not necessary can mitigate, or at least alleviate, the scope of AiTM activity.

This diagnostic statement describes how the organization establishes and manages baseline measures of network activity. Supported by network monitoring tools and other controls to detect events and identify incidents. Mitigating mechanisms may include: Data Loss Prevention (DLP); Filtering Network Traffic; Limit Network Traffic; Network Intrusion Prevention Systems (NIPS); and Network Segmentation for these type of network-based techniques.

This diagnostic statement provides protection through secure network device configurations (e.g., firewall rules, ports, and protocols) aligned to security baselines. Using network appliances to block or filter network traffic that is not necessary within the environment can prevent leveraging for AiTM conditions.

This diagnostic statement protects against Adversary-in-the-Middle through the use of secure network configurations, architecture, implementations of zero trust architecture, and segmentation.

This diagnostic statement provides protections for production environments. Measures such as network segmentation and access control reduce the attack surface, restrict movement by adversaries, and protect critical assets and data from compromise.

This diagnostic statement prevents adversaries from being able to steal data in transit between networks. There may be some similarities to NIST 800-53 SI-12 Information Management and Retention. This may provide mitigation of data access/exfiltration techniques.

This diagnostic statement is associated with employing strong encryption methods to mitigate unauthorized access or theft of data that protect the confidentiality and integrity of data-at-rest, data-in-use, and data-in-transit. To address adversary-in-the-middle threats, the organization ensures that all wired and wireless traffic is encrypted appropriately, employs best practices for authentication protocols such as Kerberos, and protects web traffic containing credentials using SSL/TLS.

This diagnostic statement protects against Adversary-in-the-Middle through the use of limiting access to resources to only authorized devices, management of personal computing devices, network intrusion prevention, and the use of antimalware.

This capability can protect against adversary-in-the-middle attacks by ensuring encryption is baked into the DevOps process of applications.

This control can be used to limit access to network infrastructure and resources that can be used to reshape traffic or otherwise produce MiTM conditions.

This control provides partial protection for this technique's sub-techniques resulting in an overall Partial score.

This control can mitigate Man-in-the-Middle attacks that manipulate network protocol data in transit.

This control may mitigate against Adversary-in-the-Middle by providing certificates for internal endpoints and applications to use with asymmetric encryption. This control may also provide authentication for user identity for VPN or zero trust networking.

Cloud VPN enables traffic traveling between the two networks, and it is encrypted by one VPN gateway and then decrypted by the other VPN gateway. This action protects users' data as it travels over the internet. This control may prevent adversaries from attempting to position themselves between two or more networks and modify traffic.

VPC security perimeter mitigates the impact from Adversary-in-the-Middle by creating virtual segmentation that limits the data and information broadcast on the network.

The VPC service's support for the AWS Virtual Private Network (VPN) can be used to encrypt traffic traversing over untrusted networks which can mitigate Man-in-the-Middle attacks that manipulate network protocol data in transit. VPC Peering can also be utilized to route traffic privately between two VPCs which can reduce the Man-in-the-Middle attack surface. VPC Endpoints can also similarly reduce the attack surface of Man-in-the-Middle attacks by ensuring network traffic between a VPC and supported AWS services are not exposed to the Internet.

The following AWS Config managed rules can identify configuration problems that should be fixed in order to ensure SSL/TLS encryption is enabled to protect network traffic: "acm-certificate-expiration-check" for nearly expired certificates in AWS Certificate Manager (ACM); "alb-http-to-https-redirection-check" for Application Load Balancer (ALB) HTTP listeners; "api-gw-ssl-enabled" for API Gateway REST API stages; "cloudfront-custom-ssl-certificate", "cloudfront-sni-enabled", and "cloudfront-viewer-policy-https", for Amazon CloudFront distributions; "elb-acm-certificate-required", "elb-custom-security-policy-ssl-check", "elb-predefined-security-policy-ssl-check", and "elb-tls-https-listeners-only" for Elastic Load Balancing (ELB) Classic Load Balancer listeners; "redshift-require-tls-ssl" for Amazon Redshift cluster connections to SQL clients; "s3-bucket-ssl-requests-only" for requests for S3 bucket contents; and "elasticsearch-node-to-node-encryption-check" for Amazon ElasticSearch Service node-to-node communications. All of these are run on configuration changes except "alb-http-to-https-redirection-check", which is run periodically. Coverage factor is partial for these rules, since they are specific to a subset of the available AWS services and can only mitigate behavior for adversaries who are unable to decrypt the relevant traffic. This control does not provide specific coverage for this technique's sub-techniques, resulting in an overall score of Minimal.

The following AWS IoT Device Defender audit checks and corresponding mitigation actions can identify and resolve configuration problems that should be fixed in order to ensure SSL/TLS encryption is enabled and secure to protect network traffic to/from IoT devices: "CA certificate expiring" ("CA_CERTIFICATE_EXPIRING_CHECK" in the CLI and API), "CA certificate key quality" ("CA_CERTIFICATE_KEY_QUALITY_CHECK" in the CLI and API), and "CA certificate revoked but device certificates still active" ("REVOKED_CA_CERTIFICATE_STILL_ACTIVE_CHECK" in the CLI and API) can identify problems with certificate authority (CA) certificates being used for signing and support the "UPDATE_CA_CERTIFICATE" mitigation action which can resolve them. "Device certificate expiring" ("DEVICE_CERTIFICATE_EXPIRING_CHECK" in the CLI and API), "Device certificate key quality" ("DEVICE_CERTIFICATE_KEY_QUALITY_CHECK" in the CLI and API), "Device certificate shared" ("DEVICE_CERTIFICATE_SHARED_CHECK" in the CLI and API), and "Revoked device certificate still active" ("REVOKED_DEVICE_CERTIFICATE_STILL_ACTIVE_CHECK" in the CLI and API) can identify problems with IoT devices' certificates and support the "UPDATE_DEVICE_CERTIFICATE" and "ADD_THINGS_TO_THING_GROUP" mitigation actions which can resolve them. Coverage factor is partial for these checks and mitigations, since they are specific to IoT device communication and can only mitigate behavior for adversaries who are unable to decrypt the relevant traffic, resulting in an overall score of Partial. This control does not provide specific coverage for this technique's sub-techniques, resulting in an overall score of Minimal.

AWS RDS and AWS RDS Proxy support TLS/SSL connections to database instances which protects against man-in-the-middle attacks. However, given that it does not support any sub-techniques, the mapping is given a score of Partial.