If the Capital One sysadmin had just changed the WAF password…
In the final part of our blog series on the Capital One breach, I want to discuss the conclusions reached based on the vulnerabilities and exploits used, and determine how, if at all, they could have prevented it from happening. (If you missed them, here are part one and part two.)
At a high level, if access to the data-sensitive secure enclave had been properly isolated and segmented (e.g. utilizing data diodes for a communications air-gap) with data query more controlled (ehem, with data diodes) in concert with stronger RBAC, dual authentication, or even finer grained attribute-based access control (ABAC), command execution and data exfiltration would not have been possible.
In addition, network security event data (successful sign-on), syslog, operational and performance data should have been captured (via SIEM) and securely returned to Capital One’s SOC environment via data diode where inappropriate access (via user entity behavior analytics) and excessive data exfiltration from an administrator’s account could have been identified.
Shameless Plug for Data Diodes (But I’m Not Wrong)
As previously mentioned, data diodes could be used effectively as that “additional layer of security,” or air-gap, between the WAF and AWS; they cannot be reconfigured or exploited over the internet. The isolated source and destination network sides are configured during installation and cannot be changed during operation, for added security.
One-way data diode devices do not allow command and control within the same communications connection (there is no “phone-home” return path), unlike firewalls of any type. While firewalls can be configured to operate in only one direction, as we have seen from the Capital One example, misconfiguration is not only a possibility, but a common occurrence.
Data diodes terminate bidirectional connection on the source network via an on-board proxy, with protocol break and complete network anonymity to the outside world (or internet). They then transfer data one-way via a hardware-enforced mechanism, and then re-establish bidirectional communication on the destination network side, via an on-board proxy.
Financial institutions could easily use Owl data diode solutions as a secure data transfer mechanism:
- to help segment/isolate sensitive server and storage networks holding extremely sensitive customer data from general access
- to create secured computing zones ingress and egress for data set analysis and external data reporting
- in the data query path with existing applications, using multi-channel ingress with each channel authenticating to that device with delivery of the response across the hardware configured and enforced back channel
- in the data query path in new or modified applications where the client query and the server/storage result follow separate ingress and egress paths; this provides maximum, air-gapped level security
Highlights of this last data query methodology is contained in a ZDNet article “Australian Department of Health using blockchain for medical research records”
“The secret sauce is that if a researcher submits an experiment against that data, we take that query, through a data diode, down deep into the Vault datacentre, execute the query … pull back that answer to that query, for the researcher, but not ever expose the data itself…”
All things being equal, with the proper segmentation, hardened security technologies such as data diodes, and better monitoring in place to protect the data sets, this breach would not have been possible. Then again, maybe if the Capital One sysadmin had just changed the WAF password, that also might have been enough to stave off this breach.