Reactive mode is no way to run a security infrastructure. Here's how to stop fighting fires.
WHAT CAN HAPPEN
Identifying assets, vulnerabilities, and threats leads us to the infamous probability, or "likelihood," stage. Unfortunately, this is another area where IT risk management efforts need improvement compared with other industries because of, among other factors, subjectivity and a lack of historical data. A more mature approach would be to replace "likelihood," a qualitative guess in most cases, with "frequency," a quantitative and usually data-backed estimate. As an adolescent community in a subset of the area of risk management, IT obviously can't expect to have actuarial data for all our security challenges soon, if ever. Hopefully, frameworks like FAIR and the use of Bayesian technology can help fill some of these gaps, but even if we start with internal efforts to identify critical metrics, events, and losses, we'll be making progress.
Risk management basics aside, here's where the real leap comes in: learning to let more things go. When talking to information security traditionalists, the thought that comes right after "identified risk" is usually "mitigate," with "risk transference" a rare consideration and "risk acceptance" often hotly contested. To be fair, most transference mechanisms are done outside the technical realm through legal and insurance mechanisms, but it's a path that must be explored.
Acceptance, on the other hand, is something we certainly understand and perform frequently, albeit usually only in areas perceived as low risk. But should acceptance occur more frequently? Do we accept risk enough, and in the right areas?
Put into the context of tactical security initiatives, does preventing worm and virus outbreaks outweigh the need for encrypting personally identifiable information? Does detection of network-based intrusions reduce risk more than ensuring that all laptops have full disk encryption? Do we know which systems are the most critical and which are more disposable, and have we carried that into practice? Where does user awareness training fall into the mix, and have we balanced efforts in stopping stupid vs. stopping evil?
If given the choice between protecting everything poorly versus protecting a few assets well, which should IT choose?
History suggests we've preferred the former; the latter might prove a better path moving forward. Without an effective way to measure and communicate risks, we can't hope to have an effective conversation on the topic, much less make educated decisions. Gaining an understanding of risk terms, using them consistently in communications, developing a formal process to identify and quantify risks, and relating risks to assets in terms that make sense to both business and IT folks will give IT teams a better chance of prioritizing in ways that meet the needs of all levels of the organization.
BE SMART ABOUT PROJECT SELECTION ...
When it comes to security initiatives, the "Be proactive, not reactive!" mantra has been preached for some time. Unfortunately, in talking to information security practitioners and officers alike, it's obvious that many organizations continue to prioritize based on incidents that have already occurred.
Of course, reacting to real-world events isn't in itself a bad idea, and neither is business involvement--in fact, that should be encouraged. But beware of letting your security agenda be ruled by the tyranny of post-incident fear. Two notable risks are an imbalance between tactical and strategic efforts and the pain of consistently being a few steps behind evolving threats.
How do we break this cycle? Integrating more risk-management-centric approaches can certainly help weed out anomalous scenarios and bring a rational, methodical, and defensible process to decision making. Another tool is to make sure there's a plan to match all tactical firefighting exercises with a strategic counterpart. For example, mainstream operating system and service vulnerabilities--frequently the root cause of worms, defacements, and the occasional targeted data theft--can be addressed by the modern vulnerability management process, yet application security issues are less well understood. Many organizations have launched application security initiatives only in the past 12 to 24 months, and most are still in their infancy. Typical efforts include the use of Web app scanners; application "penetration tests" ... arguably a misnomer, but an effort nonetheless; code reviews performed by specialized consulting firms; and investments in Band-Aid technologies such as "application firewalls."
While these efforts are steps in the right direction, without strategic counterparts such as developer training, integrating security into the software development life cycle, and holding software vendors accountable for security flaws via contract clauses, security teams continue to treat the symptom while ignoring the cause.
The evolution of application security is just one example, albeit a timely one. Risk-aware organizations will take steps to ensure that all projects receive both tactical and strategic security investments.
The Business of Going DigitalDigital business isn't about changing code; it's about changing what legacy sales, distribution, customer service, and product groups do in the new digital age. It's about bringing big data analytics, mobile, social, marketing automation, cloud computing, and the app economy together to launch new products and services. We're seeing new titles in this digital revolution, new responsibilities, new business models, and major shifts in technology spending.