On Tuesday I heard Marcus Ranum talk at the Secure360 show in St. Paul. His general premise, which I won't enumerate fully, was that market consolidation, increase in legislation, and the general lack of relationship between actual attacks and information security spending will lead to the demise of the information security professional as we know it and the introduction of a lawyer-driven regulatory compliance-centric checkbox in its place (more or less).
Despite being a sort of glass-half-empty discussion, there were a couple of points that stuck in my head and warrant some exploration.
First, Ranum asked this question in relation to the increasing legislative environment (paraphrase): "When has more legislation ever made things (better | less complicated | easier)." Despite it's rhetorical nature, I wanted to find an answer. It's easy to think of legislative movements that haven't improved things, but those that are really beneficial are likely to be forgotten. For example, driving. The use of the road system in the United States is extremely varied and regulated, but I can't imagine there are too many people who would argue that the laws surrounding transportation don't benefit the general public. You might want the speed limit increased (or decreased), but one hardly argues for the abolition of drivers licenses. Ok, so it's possible, but that doesn't mean it's likely.
Second, and more importantly, I couldn't help finding myself wondering if the ultimate conclusion that Ranum came to was actually bad. I mean, it was clearly bad news for the techie who wants to keep purchasing and implementing nifty security tools, but given the other conclusion present, namely that all this economic activity hasn't actually had a positive impact on the overall risk that organizations realize, it is really bad for business overall? Is it bad for the public in general? Perhaps I can demonstrate why I don't think it is.
Right now, information security is a losing battle, both functionally and financially. Money and time are spent without a measurable return, either in risk mitigated (loss prevented) or revenue. It's been that way for a while, which has naturally pushed efforts for standardization, especially around metrics (CVSS). As we gain the ability to measure risk, we produce a corollary body of knowledge around risk reduction. This discipline splits into two: secure development and secure configuration. That split mirrors areas of responsibility: developers who are responsible for code and users who are responsible for deployment. The pattern to watch for here is the distance between responsibility and authority. So, efforts like the PACB aim to put the responsibility for secure code into the hands of those who have the authority to change said code. Likewise, efforts like XCCDF, CCE, and CIS aim to put the responsibility for configuring environments securely in the hands of those who have the authority to do so. Where does legislation fit? Well, legislation is useful only if there are valid standards to which it can point. In other words, a 'code securely' law only works if there's a standard for doing so to which it can refer. The same goes for legislation around secure deployment and configuration. This is where the compliance market really develops. A successful piece of legislation specifies a clear standard and validation of adherence to it. The point at which penalties become involved is where the lawyers come in. So, in five or ten years the compliance auditor very well might find herself working for a lawyer and working on a JD. This conclusion is roughly the same as Ranum's, but drawn in a positive light it looks a little bit more rosy.
Information security as a whole moves from a poorly defined, immeasurable cost center to a clearly specified, predictable compliance function. Residual risk is then much easier to transfer via insurance. That's a lot easier to work with from a budget and business standpoint. The FUD gives way to operations, which lets businesses get on with doing business. The information security professional moves into either network/system administration (business enabler) or compliance (business requirement). That doesn't seem like such a difficult situation to me, and it seems like an improvement overall.