Published: 03 Jun 2013
Security has evolved in the 15 or so years I have been doing it, from a reactive chain of events built around “security mess response,” to a more predictive game with proactive defense based on risk management and forward-looking intelligence. Nowhere is this more evident than in the financial services industry. There, the stakes are high because bits are money; and the notion of adjusting technical infrastructure by weaving controls into the fabric of the organization is de rigueur.
Increasingly in the financial sector, security is about looking forward instead of picking up the pieces in a forensic, mop-up operation. This approach is growing in popularity and gaining relevance in other verticals.
I just moderated a panel on this issue at the FS-ISAC Conference in Florida. Panelists included Chauncey Holden, chief information security officer of Fidelity; Keith Gordon, vice president of information security at Capital One; and Jim Routh, the global head of application security at JP Morgan Chase. Just for the record, the idea for the panel was Keith’s, but we all did our share of thinking about the issue. (Special thanks to Anish Bhimani, chief security officer of JP Morgan Chase, who helped brainstorm, but then had to go off to the White House and miss the fun part.)
Then versus now
Back in the old days, we waited to be attacked and then reacted, often amassing plenty of ex post facto data about how we just got skewered as a side effect. We worried about adjusting firewall rules and patching things up, and took a historical view of data in terms of lessons learned. A vast majority of the attacks in the early days were configuration attacks. (Putting firewalls in place certainly helped with that problem.)
Things moved quickly to real-time monitoring and security operations centers as the most obvious configuration errors were dealt with and automated patching systems were put in place. The attackers moved on to bugs and flaws in our systems themselves. Well, bugs, at least. It’s pretty clear that design flaws are next in the cross hairs.
Then came the most interesting shift of all—one that we are still in the middle of—from real-time monitoring to proactive security.
The idea behind proactive security is simple: build stuff right the first time by following the strictures of software security and security engineering. Leverage the vast pile of security data we have accumulated to design smarter architectures and applications that don’t fall over when brushed by a feather. Institutionalize the approach by rejiggering firm-wide processes so that software development lifecycles are secure, and hardware is properly configured before it comes time to weather the storm.
Embedded controls and the proactive ‘turn’
The key to executing the “turn” to proactive security, properly, is embedding controls directly into everyday business processes so that the business owners (and not the security geeks) can respond and react accordingly. Don’t try to bolt security onto a system by adding security mechanisms and controls to the stuff you’re already churning out. Change the way you build things. And make sure the new process is owned by the business, not by specialists or security geeks.
Essential to this “turn” is an understanding of how the typical business executive’s perspective on security has changed from then to now, and adjusting your tactics accordingly. It’s our job as security professionals to move executives from awareness (and often-irrational fear of the boogeyman) to understanding. You can still fly into the vacuum created by a security event (like the DDoS attacks happening at major banks), but you must do this carefully and present solutions in terms of a security posture for the business going forward. The old days of using smoke-filled, burning disasters to drive security spending are behind us.
A good example of the lean forward approach can be seen in the automated, malicious-code-detection activity introduced with BSIMM4. By recognizing an emerging threat—developers gone rogue in the supply chain, for example—security can position itself ahead of problems before they happen. This fits a proactive posture to a “T.”
Incidentally, one good technique to use while anticipating threats is to discuss business impact directly. It’s far more effective to say, “When this happens, we violate SEC rules for implementing and provisioning a new account” than to discuss the impact of an attack in technical terms that nobody, other than your team, understands.
Where does the money come from?
I hate to admit this, but compliance still drives a majority of security spending in the financial services market. Compliance still matters—and regulators rule the day. The trick to leveraging this fact as you move to proactive security is to design controls that hit compliance wickets—as an intentional side effect. If your code review engine turns out better code and creates regulator eye-candy, you win.
You can always improve the efficiency of your current approach to free up budget for further activity, but you can enhance this effort by looking forward at potential threats to come. Remember the malicious-code-detection thing? When most financial services firms have offshore development teams in countries all over the world, malicious code detection makes a great deal of sense.
Internal and external messaging
Modern CSOs know darn well that being able to discuss their security controls and plans externally is just as important as internal positioning. Look no further than the DDoS attacks that are all over the news. When your business stakeholders begin fielding questions about security, and big customers start asking you to present at their board meetings, your firm will have to step up its game externally.
Proactive security is a massive differentiator, here. It can make both your internal business units and external customers comfortable with the knowledge that you are tackling complicated issues. If you are not in fire-fighting mode, but rather in “we’ve anticipated that and here’s how we set things up for the oncoming storm” mode, you win.
What to measure: KPI → KRI
Any real-world security practice has no shortage of data and metrics. So, how do you give the Senior Ops people at the big table what they need? How do you tailor the message for the audience?
About the [In]security column:
This monthly security column by Gary McGraw started life in print in IT Architect and Network magazines and was originally called “[In]security.” That was back in October 2004. The column then transitioned into Web content at several publications before finding a home at SearchSecurity. You can always find pointers to the complete [In]security series on McGraw’s writing page. Your feedback on the column is greatly appreciated.
Senior executives probably don’t need to know that your server patching efforts are at 35% instead of at 80%. They just need to know why that might be happening. What business decisions are driving your results? What are the tradeoffs?
Key performance indicators (KPIs) help you figure out whether a process you have put in place is healthy, and if it is improving things from an efficiency standpoint. But what the business wants is the key risk indicators (KRIs), not a bunch of tactical readings that really only help you run your part of the machine. Sometimes, notions such as presenting risk geographically or by business unit can be put to work. These metrics often help with regulators, too.
Looking forward with Intel
Presumably, you know which assets are high risks. Proactive CSOs are using the vast amounts of data churned out by modern systems—including security systems— to build predictive models based on big data. Visualization, trending, and advanced analysis can help you get in front of problems before they have fully developed. Think of this as weather prediction for security: Once you have a forecast on what is likely to come, you can set up your controls more efficiently.
When someone asks, “Shall I take an umbrella to work today?” You should know the answer. Proactive security can be your weather prediction system.
About the author:
Gary McGraw, Ph.D., is CTO of software security consulting firm Cigital. He is a globally recognized authority on software security and the author of eight best-selling books on this topic. Send comments on his column to firstname.lastname@example.org.