Information Security is not a proposition where you come in on a Monday morning brimming with confidence that you have or will solve all the problems at hand. Its true that Infosec has a lot more visibility up and down the enterprise and we win a lot more arguments than we did in the past, even though 2015 feels like the year the security dog caught the car (my friend Carlos says that we did not so much catch the car as we are strapped to the roof), there is a lot of catch up to play. Like a decades worth.
At the same time, its important to avoid the "its perfect or its broken" trap that derails so many security efforts. There've been so many security decisions over the last decade, bets that have been made, that now have to be revisited in light of the current, shared understanding of the threat landscape. So our job in part is not only dealing with new threats, its also which of the older decisions do we now need to overturn, fix, and at what cost? Is it time to unflatten the network? Take a real run at AppSec assurance processes? Threat modeling?
For example, Privileged user has been a problem in infosec for at least three decades, now post-Snowden people are scrambling to tool up. Five years back, you would see CyberArk deployed in financials for a tiny handful of high risk use cases. Now every company is not only try to deploy, but they are also attempting to scale privileged user management widely across their organizations. In the process they are dusting off use cases (and risks) that have been resident in the organization for a very long time. Now we have companies who have a tiny fraction of security budget and team trying to tackle complex use cases and deployment beyond which they have been pushed in the past.
Bottom line is that we're in a new world of Infosec, companies trying to push the envelope on what security tools can accomplish. Four factors play a role in navigating the new world in a practical way that yields forward progress - Decentralization, Testing as Input, Rational Budgeting, and Integration.
Decentralization
Governance can be used to mean many things. I like to keep things simple, I think of governance as who does what. Security is a chain of responsibility, so its critical to understand who is responsible to design the event message format, write the log sensors, integrate the log sensors, test the log sensors, manage the repository, write the reports, tune the log sensors, operate the log system, and respond to the events. Even for something seemingly simple like logging there's a wide range of activities to wrangle into a cohesive structure. Its a lot more than "who owns SIEM?"
Decentralization is a major factor going forward. We have been trying to raise awareness for so many years in this business that now that we actually have some executive mindshare, the knee jerk reaction is to build the security department of your dreams and centralize everything. Problem is that centralization doesn't scale, and in terms of cleaning up the years of previous infosec decisions scale is a major factor.
Effective decentralization is not abdication or giving people enough rope to hang themselves. Instead its about clear technical guidance, specific security checklists for mistake avoidance, training, and tuning testing to close the process loop. Don't try to do too much, do less and help others do it better.
Testing as Input - Design Like an Attacker
John Lambert wisely counseled that defenders think in lists and attackers think in graphs, as long as those happen the attacker wins. If you think about the DMZ, its sort of the one area of the enterprise that security was allowed to design. The normal rules don't apply to the DMZ, at the same time pretty much nothing functional gets deployed there. You would think that would give security architects pause, but mostly it hasn't.
A normal defender has a list of say 15 things they do security-wise in the DMZ, firewall, WAF, IPS, bla bla, and if you ask them their goal for the next year they say well I want to 17 or 18 things in the DMZ. Now think about getting to the chewy center from an attacker point of view. All that time and money to go from 15 to 18 capabilities in the DMZ, the defender list gets longer. What about the attacker? One hop to the DMZ plus one hop to the chewy center. Its still a two hop graph
One problem in the defender list analysis is the input is the defender's mental model of the system, the distilled essence of the whiteboards, Visios, power points, repositories, and such. Instead the input should be based on scans, tests, and an attacker graph based view of the system. This is not about having your opponent determine your security goals, but it is about having the available attack vectors determine the security focus.
Rational Budgeting
Simply put, the while the numbers have gotten larger the relative percentage allocation of security budgets are mostly stuck in a network security era. The main threats have to do with data, identity and applications, yet the majority of spend still goes to infrastructure security. Infrastructure security obviously matters, but it does not trump the value of assets like data, identity and application functionality. Many of the long standing problems in the security are in these layers, how long have we tried to get rid of passwords or strengthen authentication, or share identity in a secure way, or have a fine grained access control system or even just classify data? Tackling problems like these (and they won't just go away on their own) requires more oomph.
Integration
We do not have security problems for the most part. We can look at an asset, look at the threats and vulnerabilities and figure out the countermeasure(s). Where we really struggle is - how in the world to integrate the countermeasure? Will we break the app? Will the CSRF nonce break the stateless model of the app? Will we break the user experience?
On top of that the security countermeasures themselves do not play all that well together. Strong auth is an island unto itself, so is regular auth, so is VPN, so is authorization (Well actually that's embedded in the spaghetti code), so are roles, so is logging. Security capabilities have to do way better at first mile (user) and last mile (resource) integration and we have to improve how the security capabilities integrate with each other, otherwise we don't get the scale and coverage.
These four factors are not a complete set of things sufficient to win, but they are frequently overlooked factors that should be present to make an effective security team with a fighting chance to compete with the challenges that systems face.
Comments