You can lead a horse to water, but you can't make it drink.As I've recently noted, the information security industry seems to be stagnated. We've come a long way from the old days of "security==firewall" - and yet, it strikes me that we still aren't really getting all that much done. As a consultant, it can be very frustrating to realize one's own mortality; we aren't able to play Superman in all situations. When we succeed in moving a mole hill cum mountain, we're hailed as heroes. When we get something done, our invoices/salaries get paid. Surely there must be more.
Someone recently asked on a mailing list what people thought of the impact of PCI DSS on software security (the current v1.1 of the standard has requirements to follow OWASP practices in secure coding). In thinking about the effectiveness of PCI, I concluded that it, like SOX, has reached a point of equilibrium as ineffectual. Businesses still seem to universally fail to grasp the value of most security practices, and thus resist the up-front costs required to undertake a truly transformational program.
Where SOX and PCI vary is in the level of the organization targeted. SOX is aimed at the business, with a particular leaning toward integrity and anti-spoiliation practices. Unfortunately, it's so ambiguous that the business has found a way to manage it (generally) through tightly controlled scope and minimal direct investment. Most security fixes tend to come through derivative practices within IT that are attached to SOX via a dotted line.
In contrast, PCI is very tech-specific, providing very prescriptive measures to improve security. These measures come as an essentially direct response to demonstrated vulnerabilities and incidents. However, they're quite operationally focused, meaning that the business can generally bury its head in the sand, providing a little seed money as necessary to make improvements.
The point here is that, while SOX attempts to work top-down and PCI attempts to work bottom-up, both reach the same conclusion: the business does not engage, and significant long-term improvements are not made. This situation of a disengaged business is, unfortunately, nothing new. In fact, I first started trying to tackle it in early 2000, as demonstrated in the following "3-tier Model (v2)" (this is a revised artifact from 2000).
I provide the above diagram as an example of my thought processes at the beginning of this decade. As you can see, even then I was trying to advocate a strategic approach that involved comprehensive policy, ET&A (education, training, and awareness), etc. The TEAM model builds on that momentum in trying to establish programs in the consciousness of the business.
What I find particularly interesting about this security plateau today is that we seem to be in stasis. Evolutionary processes seem to have stopped having effect, with the business persisting in a generally disengaged state. The next curve to which we need to jump, I believe, is a fully security-conscious business that integrates security practices (ideally lightweight) into everything it does. But how do we get there?
Historically, we've seen certain tricks applied, all with results, but clearly nothing with long-term appeal or effect. In the post-SOX era, one of the more popular methods is intimidation, such as through use of the compliance "stick" or audit results. In addition to flogging "compliance" requirements, I've also seen a reliance at times on pure FUD and terrorism ("if you don't implement X, then you will get hacked and lose millions!"). The truth is perhaps not as scary. Threatening the business may work in the short-term, but over time people become accustomed to the threats and learn to ignore them.
Another approach that I've long advocated has been to address security from a quality and continuous improvement perspective. Through this approach, one focuses on improving engineering or business processes so that the incorporate security. This method is important, and a good goal. However, there is almost always a startup cost and an increase in overhead (even if ever-so-slight), that businesses may have a hard time accepting it. Look at how quality assurance teams are generally treated, and how often they become one of the first groups axed when times get tight.
A similar angle to leveraging quality is to look at continuous improvement from an optimization and cost-reduction perspective. The best example is to develop metrics and benchmarks that can be used to gauge the costs associated with security incidents over time. In engineering, it has been demonstrated that spending more time on a better design will save money over the long run, such as in maintenance costs. I've seen a similar effect in integrating security professionals into the design process, as well as leveraging security resources for testing in parallel with QA (if not out-right integrated with QA). Fixing a broken product before release is considerably more cost-effective than trying to reel it back in after it's gone out the door (especially with web apps).
In the modern environment, a different type of approach has become more prevalent in trying to address security to the business. That approach falls under the general heading risk analysis, risk management, risk strategy, and/or trade-off analysis. Fundamentally, you want the business to set a strategic direction for handling risk. In order to handle the risk, you need to be able to assess it and analyze it. Ultimately, these processes will culminate in the business making a value judgement that leverages trade-offs and compromise. A control that costs far more than the asset being protecting will hopefully be discarded, or even eliminated.
Overall, this more recent approach can be effective in engaging the business; or, at least it can help keep the business engaged once it engages. However, I still see problems with getting the business through the door and at the table. How do we, as security professionals, get the business to engage? Without its engagement, we cannot hope to achieve transformational change.
A couple approaches come to mind in trying to nudge the business in the desired direction. First, I believe more can be done with education, training, and awareness in order to bring the business up to speed on the concerns of the times. Dr. Peter Tippett actually advocated this approach at the Computer Forensics Show this past February. According to an article on Dark Reading:
Security awareness programs also offer a high rate of return, Tippett said. "Employee training sometimes gets a bad rap because it doesn't alter the behavior of every employee who takes it," he said. "But if I can reduce the number of security incidents by 30 percent through a $10,000 security awareness program, doesn't that make more sense than spending $1 million on an antivirus upgrade that only reduces incidents by 2 percent?"
Dr. Tippett is absolutely correct in his reasoning. ET&A, when done well, can be very cost-effective. And, more importantly, education and awareness can lead to improved practices. The main challenge is in selling those programs and getting the business to buy into them. If you're planning to try this approach, make sure you develop baseline metrics and a method for generating performance metrics over time to gauge/demonstrate the effectiveness of your program over time.
One bad apple spoils the lot.Finally, there is one more approach, which I hesitate to even mention because it can be draconian and counter-productive. That approach is to implement strict accountability with defined and enforced consequences. It's one thing to provide an environment where mistakes can be made, a la Jack Welch. It's another thing to not maintain an environment of responsibility and accountability, where security incidents do not result in follow-up and potential disciplinary action. If you have policies in place, and have been conducting training and awareness, and yet people still manage to do the wrong things, then they need to be held to account. If developers are required to follow coding standards to limit the incursion of common errors like cross-site scripting (XSS) and SQL injection, and they get sloppy and expose the company to new threats, then some sort of action must be taken. Rules that aren't enforced will not be taken seriously, which will erode the impact of the security program as a whole.
It is my sincere hope that there are other options available to us in the infosec community to help bring the business to the table. The problem is quite serious, and it is at least partly to blame for the stagnation that we've seen. There are no silver bullet solutions. There are no magic "SOX in a box" appliances that can be plugged into your network to magically make you "secure."
We are well beyond the period of time where "security==firewall" and thus need to start acting like it. This reality means creating business security programs that have the power and support to initiate transformational change. Through such change the corporate culture can be modified over a reasonable period of time to holistically integrate good security practices. Now we just need to figure out how to make that happen.
