The 7 Layer Approach to Security
So far this year we’ve seen malicious actors breach the California DMV, T-Mobile, Experian, CVS Health, Facebook, and many others. Today it is not a matter of “if” but rather “when” a breach occurs, with an emphasis on limiting access and mitigating potential damages.
After all, even seemingly harmless data breaches can result in millions in lost revenue, damages, and fines. And perhaps that’s the problem, is that there is no such thing as a harmless data breach because once someone has access to your system they’re often granted free rein.
Take for example breaches into Sony and Target’s network. Once in the malicious actors were able to move almost undetected and with nearly limitless access to confidential documents, business plans, assets, and even personal data such as credit cards. These two breaches cost Sony $15 million and Target $18.5 million.
Understanding attack surface
Part of the challenge is that malicious actors have numerous ways of attacking your business. First there is through social engineering or taking advantage of your employees’, vendors’, and customers’ trust. A seemingly harmless call to recover “lost” account information, a replica of your website portal login, a call “from your company” where they get the 2FA password reset code, or simply leaving malicious software on a USB stick that’s laying around.
And then there is your software and network itself. It’s important to remember that security needs to extend beyond your app itself, which while being the most obvious layer is not the only layer a malicious actor can attack. To better understand your attack surface take a look at the OSI Model and the 7 layers that comprise your architecture:
- Layer 1: Physical machines (computers, servers)
- Layer 2: Data link (ethernet, PPP, switches, bridges)
- Layer 3: Network (Packets, IPs)
- Layer 4: Transport (UDP, TCP)
- Layer 5: Sessions (Sockets)
- Layer 6: Presentation (SSH, SSL)
- Layer 7: Application (HTTP, FTP, DNS)
This means that as you build out your security to prevent the majority of attacks and mitigate damages from a breach you need to plan for each layer, and take steps to protect each layer.
For example, implementing physical security and firewalls to prevent human and outside network access to your machines/ company network. But that also means implementing a zero-trust solution inside of your network to prevent a malicious actor who gains access from having nearly unlimited mobility inside of your network.
One solution vulnerable to such an attack (although it has become hardened over the years) is Kubernetes. This popular container orchestration solution initially allowed a malicious actor to breach the network through a pod and gain access to other pods and applications in the network. Thankfully solutions like Istio, Envoy, and Calico provide ingress and egress rules across layers 3, 4, & 7 to help mitigate these risks.
But this is a simple example of how even the most popular solutions come with security risks, and need to be evaluated to ensure you have the proper security mechanisms in place. It’s also the difference between random actors and sophisticated, malicious attacks.
The most attacked surface
While many sophisticated attackers will attack all 7 layers with much more sophisticated approaches (think of energy plants being hacked), the majority of attacks are performed by random actors who look to target known security vulnerabilities in apps or app code.
Your app is the most visible layer of your infrastructure, and typically the most prone to the easiest security vulnerabilities
These are the hackers who take advantage of remote access vulnerabilities that existed in Windows, or vulnerabilities that exist in open source tools. Many simply write bots that utilize the most common security mistakes made by developers — such as forgetting to sanitize input before running a SQL query, or forgetting to ensure access roles are enforced on obscure actions — to being lazy and thinking no one will discover that .xml or .ini file with user credentials sitting in a public directory.
These tools run relentlessly spidering files and testing file names to see if they can uncover hidden files, while also attempting to perform cross-site scripting (XSS), injection (primarily SQL), and other attack vectors via brute force.
This is why it is so critical to understand these common mistakes that these hackers try to take advantage of, and ensure that while you pay attention to security across your entire infrastructure, you likewise spend ample time to ensure your app is secure — because if you do not find your security vulnerabilities, there is a good chance these malicious actors will.
You can find OWASP’s list of top 10 app security vulnerabilities here, or join me Thursday August 26th as we go through the top 10 and other security concerns (including PCI concerns) at our August RingCentral Developers meetup.
