The Relegation of Security to NFR Status

In this post I wish to continue exploring some of the points raised by Marcus Ranum in his recent piece The Anatomy of Security Disasters, commenting on what I see as security being relegated to the status of a non-functional requirement (NFR). That is, a potentially perplexing yet necessary task that needs to be done by some group of specialists to complete a project.

The Ranum disaster cycle looks like this. Management comes up with a new idea with significant business benefits that requires support from IT to be deployed. For sake of argument, let’s say the idea is to bring a customer application online through a web interface that has traditionally only been accessed by internal staff as a back office function. Typically the project has one or several champions, convinced of its importance and certain success, who with their “can do” track records will see the project through.

IT (let alone IT Security) is often not involved in the early stages of developing the project business case and deployment timeframe. By the time IT security does get sight of the project they are nonchalantly requested to “make it secure”. In this manner IT security has become a non-functional requirement (NFR) - not worth explicitly stating - because we have security people and their job is to, well, make IT secure.

From the point of view of the project manager securing the solution is not qualitatively different from ensuring that there is sufficient network capacity, that the servers are adequately sized for peak loads, help desk support is created, back-up and recovery is deployed, the web interface is friendly, and so on. There are specialists who perform these tasks and they will be called upon by the project manager as and when an NFR requires attention.

Once a project (or just its idea) gains a minimum amount of support it becomes very difficult to abort it based on purely technical objections. Ranum speaks of zombie projects that, despite repeated technical strafing, still manage to stagger towards design and deployment. At this point the power of veto over the project for technical reasons is effectively rescinded, and the security people need only resign themselves to “making it secure”, or even perhaps “making it PCI secure”. Ditto for the other NFR specialists. So what is delivered is the best solution under the circumstances – Just-In-Time Security.

The observation here is that the security function is no longer called upon to critically underwrite the security risks of a project, with the option to reject. Their assumed role is to support the delivery of an appropriate solution for the stated business purpose - just like everyone else. Ranum makes the point that bringing IT systems and associated data online carries tremendous inherent security risks - risks which management appear to have lost sight of, and security practitioners have effectively lost their voice to surface.

Ranum predicts that only an epic failure on the scale of the 1986 Space Shuttle Challenger disaster will close the reality gap between management and IT, and save security from being banished into NFR limbo. Ranum hopes that he is wrong, as we all do.

Related Posts

• Marcus Ranum and the Points of No Return