If you do any travel at all, it’s likely that you are a member of a hotel rewards program. As a Marriott Rewards member myself, I was a part of the recent data breach affecting over 500 million consumers. As I sifted through countless how-to-protect-yourself-in-case-you’re-hacked articles, I couldn’t help but think: Is there anyone left to hack?
As we near the end of 2018, we take a look at some of the biggest breaches of the year on the podcast: Software Ate My Homework. There's Marriott, Quora, Facebook, Under Armor and many, many more. If you stop to consider everyone affected by those beaches, it comes out to 2.3 billion people. When you extrapolate that to include the last 24 months, it’s 5.5 billion people affected by a data breach.
According to Statistica, there are 6.5 billion active email addresses, and there’s likely many millions (if not billions) more that are dormant or locked-out. So we’re at 5.5 billion out of the 6.5 billion unique email addresses that are in use every day. You can listen to our full pod episode here:
Hacker Hype vs. Data Breach Reality
So what’s the real cost of a data breach? The 2013 Target hack cost the company in the hundreds of millions of dollars. As recently reported, Marriott might be the first global company to be exposed to a GDPR fine as a result of the breach, which is upwards of 4% of the company’s annual global revenue. That’s a major hit.
So why does this keep happening, and as consumers, should we panic?
The software development discipline has been around since the mid-1900s, and application security as a discipline has skyrocketed in importance over the past 10-20 years. We have a lot of brilliant minds working on making security even better, but many times developers, business leaders and consumers are still left wondering what the truth is about the stability of the software systems we use every day – the ones that control access to our bank accounts, rewards programs, help us book flights, etc.
In 2018, overall corporate spending on information security was about $115 billion. That’s a healthy budget, but when you dig into the details, the sad fact is that most of that money is spend on infrastructure and network security, leaving application security as a tertiary and sometimes lower priority. This is surprising, particularly given the fact that Gartner shows 85% of cyber attacks happen at the application layer.
If that's the case, why in the world is 10 times the money being spent on infrastructure and network security when that is not where the attacks are happening?
This is where most security vendors are pushing the narrative. Sure, there's a lot of validity in securing your perimeter, but the overall investment in security needs to be balanced. If you talk to any CISO, and you see the scope of what they need to consider, it's significant and complex. Organizations certainly take a top-down approach where they are bringing in a CISO to decide policy, governance and training, but what's missing is investment in the folks that have their hands in the applications.
How many CISOs have a direct connection to application development teams? DevSecOps is really where the convergence between security policy and security thinking is starting to take place in application development.
Understand the Vulnerabilities in Your Software
So much software is built on open source frameworks these days – pretty much everything. In order to understand your true software risk exposure, you must also understand the way in which an open source framework or component is used throughout your software portfolio. And that's hard to do.
Understanding OSS risk really requires system-level analysis, or contextual understanding of how those frameworks and components are being utilized by the application. For example, you might be using a framework that has known vulnerabilities, but the portion of the framework you’ve used might not have bad code in it. So, you’re not actually using it in a way that makes you vulnerable.
Without that bigger context, on how the framework is being accessed, it’s impossible to know how secure and robust your apps really are. Not to mention, without proper tooling, it will take countless man hours to sift through the source code manually, and that’s just not realistic.
The adoption of DevSecOps is trying to help change this and make it easier for teams and IT leadership to have continuous visibility into risk exposure and how to fix it fast. If you're building and releasing, then you should have a process running in parallel that's checking code continuously for new vulnerabilities added. At the very least, these scans should check leading security standards like OWASP Top 10, CWE, MITRE, CISQ and more.
Know Your Software Better
At the end of the day, protecting yourself from a data breach is all about knowing your software better and admitting that we can all do a better job of protecting ourselves from falling victim to hacks. It doesn’t work when we try to “boil the ocean” and do everything at once. We’re all getting smarter on how hackers are pulling this off. So let’s take a simple and focused approach to stopping them.
Use this simple mantra: “Know Your Software Better.” There are easy ways to do that. It may take some time to get it right, but the time to start is now.