cloud egress control

It is essential to understand the egress points present in a typical Cloud deployment for an effective Data Loss Prevention strategy. Exfiltration risks that remain unmitigated with conventional data in use tools to the best of their abilities are mitigated with data in motion policies.

OUTBOUND ALLOW ALL​

The otherwise helpful implied default firewall rule, when provisioning in the Cloud, that lets any VM instance send traffic to any destination leaves gaping holes in the information security stance of a deployment. To better understand this risk, let's distinguish between the response to a request vs only a request ways of data exfiltration.

RESPONSE TO REQUEST​

In such a transaction of data flow, sensitive data may be sent to an unauthorised destination in response to a legitimate request. Think of an HTTP response to an HTTP request, where the request was semantically legitimate but its origins unauthorised. This vector is usually well guarded with sane inbound defaults of Cloud firewalls, authentication and authorisation layers presented to the Client, and an array of WAF and similar tools on the wire.

It should be pointed out that most firewalls are stateful; therefore they will allow the outbound flow of data in relation to an allowed inbound request, regardless of explicit allow/deny rules being present in the outbound rules.

PAYLOAD IN REQUEST​

In this scenario, sensitive data may be sent to an unauthorised destination in a request itself, such as in an HTTP POST or cleverly crafted DNS queries.

The ability to raise a request from a system where data in use was laying exposed (decrypted), in memory perhaps for processing, could be gained by a malicious internal actor, or by an external actor by exploiting a Remote Code Execution (RCE) vulnerability. The SSRF attack vector is a classic exploit in the Cloud. These requests originate from within the secure perimeter and should be scrutinised on their way out!

DATA LOSS PREVENTION​

Chaser's DiscrimiNAT Firewall, when placed on the egress of your VPC, allows applications access to only secure and allowlisted endpoints on the internet. Each side of a connection is validated transparently for adherence to modern cryptography standards (such as allowing TLS 1.2, TLS 1.3 and SSH v2 only) and claims made by the Client-side on the intended destination. Any forgery fails to match deductions made by the firewall itself and would be denied a connection.

Changes to firewall configuration are logged to the platform logging backend automatically for compliance auditing and reporting, and data flows are logged for forensics and incident response. Any of these may be selected for forwarding to the organisation's SIEM with the deployment platform's standard architecture.