Over the past several weeks I have had the pleasure of reading through a large stack of academic papers (that I could retrieve without cost) on security requirements. As I suspected going into this task there were as many opinions on the proper way to elicit, describe, generate and document such things as there are tastes in chocolate. That said, there were some gems that I  found scattered throughout. It may be that I consider them gems because they happen to agree with my thinking on the subject, but I digress. Why did I go to all of the trouble? In my almost insane quest for continually improving the state and practice of security I knew that there had to be a better way of “doing requirements” and introducing this part of security into a lifecycle (however broken it might be). I’ve seen bizarre checklists, a ream of non-functional requirements appended to a project with almost no budget or critical regions of functionality and unintelligible policy-laden statements trying to masquerade as requirements for engineers and designers. It is a mess. It gets worse. Most of the time requirements of the security variety, in whatever form they appear, may be all that a project team ever sees prior to construction of their widgets. Not only is their an interpretative barrier at times, but the fact that we’ve left requirements at the door without venturing further into the various stages of a life cycle guarantees that things will break.

It really doesn’t end after requirements. Well, it may if your requirements look anything like what I’ve discussed above. After requirements someone has to come along and take that information and turn it into some form of design. It seems to me that security requirements are for the most part existential statements about security *functions*. That’s where some security folks go wrong. We think that requirements are really just a synonym for policies and procedures. Sorry, they’re not. They should be something closer to prescribed functions of a system or constraints on functions dictated by business requirements. A simple example is authorization. We can make some general statements about the existence of an authorization component. Something should be there to grant the appropriate entitlements to a user. This make sense right? What sometimes happens though is that we load in all sorts of other implementation or design requirements into the cart. When we do this we run into all sorts of problems like traceability, complexity and adoption. Should statements about least privilege, compartmentalization or filesystem access control lists be included in requirements? I don’t think so. Those states are either design principles and constraints or implementation details. Maybe if we can think about security expectations more broadly we will realize that those expectations can be articulated in a more contextually useful manner. Here is a very coarse taxonomy of what I’m talking about.

  • Goals
  • Non-Functional Requirements (Security Functions, Attack Resistant Qualities)
  • Design Constraints/Principles
  • Implementation Guidance

Each one of these categories depends in some part on its predecessor. You can see the process here. We’re moving from the general to the specific. What security people typically do is something like this:

  • Requirements = Policies, Standards, Attack Language, Security Functions, Design Statements

It is a wonder that any of this makes its way into a final product. There could be information in that bundle of joy for developers, architects, requirements engineers, business analysts and others. To make things work we have to do a better job of understanding the who consumes our documented expectations. We can’t use the kitchen sink of requirements if we really want our applications to be “secure”.