It is important to understand 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 database misconfiguration that leaked”
The otherwise helpful implied default firewall rule, when provisioning in the Cloud, that lets any instance send traffic to any destination leaves gaping holes in the information security stance of any deployment. To better understand this risk, lets distinguish between the response to a request vs simply 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 of 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 authorization layers presented to the Client, and an array of WAF and such tools on the wire.
It should be pointed out that most firewalls are stateful, therefore they will allow outbound flow of data in relation to an allowed inbound request, regardless of explicit allow 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 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.
Data Loss Prevention
Chaser's discrimiNAT firewall, when placed on the egress of your VPC, allows Applications access to only secure and whitelisted endpoints on the Internet. Each side of a connection is validated transparently for adherence to modern cryptography standards (such as allowing TLS 1.2 and TLS 1.3 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.