As the uptick in breaches continue to dominate headlines and increase the general paranoia around what might happen, there’s often a story lost in the shuffle. It seldom seems like there’s a bulletproof method to stop the invasive tactics of today’s hackers. That’s because really, there isn’t.
You could spend all day trying to determine the multitude of issues that could lead to any sort of data breach or exploit on a specific system. Or, you can throw a technology solution at it – some type of IPS/IDS, a DLP or just try to leverage as many vulnerability scanners as possible.
The bottom line is that breaches will continue happen because criminals profit significantly from being able to sell the coveted sensitive information they set out to steal. However, on the flip side, we’ve seen advanced attacks like Stuxnet designed specifically to infiltrate SCADA-type systems (really a gigantic piece of dangerous malware). Therefore, there isn’t a one-size-fits-all approach to every single exploit.
While costs are a major factor, the security of critical systems can often trump the financial costs associated with breaches. The approach that so many organizations often take has been reactive in nature, and usually results in the decision to deploy a tool – a scanner, a DLP, an IPS, a firewall, etc. Underestimating the importance of deploying securely developed and configured applications in a production environment is perhaps one of the bigger oversights we are seeing.
For example, if a code review on a business application identified some malicious code or even a configuration issue, it is like finding a needle in a haystack – a process many companies don’t want to adopt, especially if they feel there’s an automated tool they can quickly integrate that is supposed to find every vulnerability. That needle could represent a major vulnerability that could have been avoided had that application been developed in the most secure environment before being rolled out into production.
Don’t Play the Blame Game
When it comes to a breach or an exploit, it’s not about who did it or why they did it. It’s about prevention and identifying how it happened so it doesn’t happen again. In the case of the Sony Playstation breach, the company shifted from a closed, embedded systems provider to a Web and Internet services content provider.
The flaw was the team was not properly educated on the differences. This also led to a failure to see how the attack surface had expanded and in what ways the gaming applications were exposed. The right amount of team education through a specific training curriculum could have been a cost-effective and highly efficient way to avoid a breach like this.
It’s easy to throw another firewall or a DLP solution at problem. It’s a reactive measure that is designed to satisfy some immediate needs, most times, after a breach. However, this does nothing to prevent a breach from occurring. Furthermore, it doesn’t map to a defense-in-depth strategy which should include:
- Training all technical personnel on the principles, both fundamental and advanced, on secure software application development.
- Ensuring that all developers have some type of development bible or reference guide where they can leverage knowledge that will help them ultimately write secure code.
- The right mix of people, process and technology – again, you don’t need every security solution on the planet to be secure, and you need employees to adhere to secure practices in their respective roles.
- An effective means of assessment – identifying gaps in the SDLC and understanding where vulnerabilities exist and remediating so they aren’t an ongoing issue.
A proactive security program will invest the time it takes to ensure that applications are developed and configured securely prior to being put into production. This proactive model requires an overhaul of priorities for what an organization’s developers are working on, which means training personnel, consistently testing software applications and having a guidance system that provides a knowledgebase of vulnerabilities.
And oh by the way, the training of developers, designers, architects and even project managers isn’t just something you should do – its mandated by industry regulations like PCI DSS, HIPAA, NIST and many others. (So you have to do it, depending on which regulations are relevant to your business.) Again, it may take some digging in that bale of hay, but when you find that ‘needle,’ the effort will pay off.
