Data has no wings - Part 1

Updated: Aug 20

We live in a world where data leak is exploding in terms of the number of breaches and volume of data leaked. Let's go to the first principles to understand what causes these leaks and how to prevent them.


In this two-part post, we will cover

Part 1 - How hackers compromise and exfiltrate data through apps

Part 2 - How to Think Differently and turn this problem Upside down


Most recent breaches have entailed gigabytes of data getting exfiltrated from companies. For example, Marriott recently lost 500 million customer records, or Equifax lost 143 million customer records. These significant breaches make the majority of people believe that data just magically leaks or gets exfiltrated. In reality, it is much more complicated, which brings us to the idea of breaking a security breach into its primary components, also known as the cyber kill chain. At a high level, the kill chain has six parts:

  1. Intrusion - the creation of file or tool (e.g., malware-infected file, or coupling it with a backdoor) delivered via the internet, USB, etc.

  2. Exploitation - exploiting a known vulnerability to execute code in the system.

  3. Reconnaissance - the attacker will scan and gather information on the target's infrastructure.

  4. Privilege Escalation - getting installed on the target asset and getting privilege access using brute-force, reconnaissance, or zero-day exploits.

  5. Command & Control - manipulate and control of the breached asset.

  6. Exfiltration - encrypt and exfiltrate data on DNS or other open ports to circumvent DPI.

Fig. 1 - Kill chain in action


In the real world, adversaries are continually scanning your infrastructure to exploit any vulnerability in your front end or accidentally exposed servers (Fig. 1). Once they find a machine, they compromise it, and it becomes node zero or the latch point. From here, the attacker will patiently scan to see what elements of the network are open. In traditional perimeter-based infrastructure, most of the internal communication is open, giving the attacker a broad surface. Besides, the attacker will also look for a way to escalate privilege because that allows them to install other tools and exploits. The attacker will patiently repeat this cycle till they get to other internal servers and finally, their priced target, the database. They might run a client to query and dump data, move it to one location, encrypt it, and exfiltrate. The application layer is where all the action takes place, which brings us to the title - data has no wing, but applications are vulnerable that leads to data leak.


The above makes us think of why security was put into the network (firewall), endpoint (DLP) vs. the application itself? Historically developers were more focused on developing applications, and the security team came in at a later stage to secure the assets. By that time, it made the most sense to put security on the network, as all applications accessed networking, becoming the common denominator. Also, general-purpose CPUs could not run at the line rate requiring dedicated hardware to deliver security at a high network rate. This model also ensured that developers and security could work independently without blocking each other. This model worked wonderfully well in a world behind the enterprise perimeter with little to no insider threat and in the absence of organized criminals and state-sponsored attackers.


With the advent of IaaS and SaaS, this approach started falling apart as workloads and employees were no longer behind the firewall. To solve this problem, security innovators got AI/ML got into the mix, looking for other substitutes vs. going after the application layer itself. This network-based heuristic approach led to false positives and alert fatigue. In recent years there has been a wave "Shift-Left," which is focusing on application development urging to bring security into application writing itself. While this sounds correct and promising, it might be hard to motivate all developers to become security practitioners. If all developers start working on security, it might be tough to achieve consistent policy across the organization, especially the larger ones.


The hope is not all lost. The new cloud-native paradigm of application development is opening ways to rethink security. In the last four years, general-purpose processors have allowed apps to run at line rate without burning the entire CPU. It urges security practitioners and entrepreneurs to go back to first principles to reimagine a distributed security paradigm (Fig. 2) that is application scoped, and not rely on other proxies. In this model, network security functions embrace modern software architecture to deliver speed, agility, and simplicity.



Fig. 2 - Distributed security paradigm


30 views