This chapter is from the book
This chapter is from the book
This chapter is from the book
Specifications
If you’ve done a good job at collecting and synthesizing the security requirements, turning them into specifications—if indeed your process even calls for this step—should be relatively smooth sailing. In essence, the requirements speak to the what, and the specifications speak to the how. We’ve seen many examples of the specifications being rolled into the design of an application itself, and many organizations don’t bother with articulating a separate set of specifications above and beyond the requirements they’ve already gathered.
For our context here, we’re not going to presume any specific development methodology, but we do want to make sure that our readers understand the benefits that can be gained from documenting the project’s specifications.
So let’s consider a few examples from our security requirements given previously.
We described a PCI-DSS requirement (8.3) that says, “Incorporate two-factor authentication for remote access (network-level access originating from outside the network) to the network by employees, administrators, and third parties.” This is already fairly specific language, but we might fine-tune it for our own application by saying something like, “Use [hardware token] and associated authentication server for authenticating all nonlocal application logins.” We also want to ensure that we have a degree of traceability from our requirements to our specifications. Numbering each, and being consistent with the numbers, can be enormously helpful.
Similarly, we cited another PCI-DSS requirement that says, “Render all passwords unreadable during transmission and storage on all system components using strong cryptography.” Here, the specification verbiage, which should be driven by the enterprise’s security standards, could become something such as, “User passwords must be transmitted in TLS 1.1 encrypted sockets using (minimum) 128-bit keys and cipher suite [example] and stored on the LDAP server in hashed format using SHA-384 (minimum).” This example, provided here merely for illustrative purposes, clearly shows how a relatively open requirement statement becomes specific to a local environment.
At a minimum, it is worth going through all the security requirements you’ve collected, and localizing them with specific details on local policies for such things as password lengths and encryption standards.
From a security perspective, we are obviously placing less emphasis on this aspect of the design process. The reason for that is that the core important details typically surface during the requirements phase and not so much in the specifications. That’s not to diminish the value of documenting an application’s specifications. Quite the contrary, details such as those we’ve listed here are important, but they also tend to be a fairly direct and simple mapping from the various requirements guidelines and policies.
There is one important exception to this, however: contradictions. Particularly in heavily regulated or complex environments, it’s not uncommon to find contradictory guidance in various security requirement sources. One source might, for example, indicate using an AES-128 encryption algorithm, whereas another says Blowfish is adequate.
The rule of thumb to follow here is to go with the higher level of security. But that’s not always immediately obvious in all cases, as with the AES versus Blowfish example. In a case like this, it’s probably best to seek policy clarification from the IT security organization, or better yet, a professional cryptographer.