Expressing Security Requirements to Enable
In organizations in which stakeholders have influence on a decision (whatever the decision-making style), conflict will inevitably arise between the security requirements and all the many other things that must be accomplished in building and maintaining systems. Issues such as resource constraints quite directly influence whether security requirements will get met, when they will be met, and how long the implementation will take. There are several key approaches to expressing security requirements that can help ease the implementation as well as foster risk-based decision making for prioritizing security requirements among the many competing needs for a system.
Finding the Right Level and Granularity
One of the key skills that can help is writing requirements at the correct level at which the requirements will be consumed. This is often a difficulty for engineers who are used to expressing a technical matter in as much detail as possible. For any but an inexperienced or unskilled implementer, this will be a mistake. There has to be enough specificity that the security requirement can be implemented somehow, that the goal of the requirement can be met. But generally, a requirement shouldn’t be written such that it hamstrings the implementers to exactly one particular and narrow implementation.
For example, if we were specifying network restrictions from one web layer to another, how should this be done? One could specify the precise IP address from the web termination to an application server IP address. One would usually specify the port and protocol. One could specify the exact piece of networking equipment that should be used. One could even specify the exact access control list (ACL) that should be placed in the configuration file of the networking equipment. One could even take the entire list of ACL (however those are presented for the particular piece of networking equipment) and show precisely where that line should go in the list for proper ordering. In a situation in which the implementer does not have enough skill to understand how to write and test ACLs, the above list of specifications might actually be necessary.
The IT networking teams with which I’ve worked have been considerably more skilled than that. The foregoing might have seemed somewhat patronizing, perhaps insulting, to these teams. And patronizing smart people is usually not a very relationship-building approach.
