I work in an environment where there is “implicit” review. That is, if you don’t respond in time during the comments period, you are assumed to sign off on the document. This is very dangerous for someone like me – I have tenuous links to the client organization, and although my hosting contracting organization has professional indemnity insurance to cover me, it only covers me as long as I’m not negligent. For example, not reviewing a document and letting it through.
Now this is where it gets tricky – I feel I have to review the documents with my name in them. However, if I review a document, I’m not about to let a sub-standard document through. I will review it and offer advice not just as the subject matter expert, but also on ways to improve the document and make it better. Often times, these are accepted and all are happy.
However, today I reviewed a truly sub-standard solution architecture document (known as a SAD). SADs normally take the business requirements and maps out in fairly specific non-techo language how a system will work and how it interacts with other systems. The developers take the SAD and turn it into an implementation of the SAD after writing a detailed design (DD). The DD will basically agree with the SAD’s approach, but minor details and extreme technical details will be included.
For example, a well written SAD will have something like this for every feature which is required to be implemented:
User Login Sequence
Scenarios
- User wants to log into the application.
- Attacker may want to brute force the application
Sequence
- User is registered using process defined in 3.2.1.
- User navigates to web site and is presented with a login form (defined in 5.4.3)
- User fills in username and password
- System will take username and password and check to see if the password is correct. The username and password are stored in the user registry, following the security principles outlined in section 1.2.3 (ie no reversible passwords).
- If the credential is correct, move to the foo page (see section 4.3.2)
- If the password has expired, move to the password reset page (see section 1.4.2)
- If the password is wrong, display a generic error message (as per message defined by the business – see Appendix A)
- …
You get the picture.
Unfortunately, the SAD I reviewed today was so wooly that I think it described a system which had between three and five new screens. I’m not sure, you see. So I gave that feedback, along with another 60 mistakes I found. This didn’t go down too well with the author. I had forgotten the prime directive of security consultants – couch your criticism nicely rather than being brutally honest.
However, looking back at it, there is another issue – the author is not qualified to write SADs. No one is – there’s no definitive form that anyone can agree on.
I feel that to ensure high quality software and secure solutions, there needs to be the One True Way to improve on the production of solution architectures. Five years ago, I think I’d be pushing the line that there needs to be a security architecture as well as a SAD, but no, we need solid solution architecture. Security is a key attribute – this is not in doubt, but everyone is responsible for security, not just the security slaves.
That’s why I am writing a Solution Architecture Book rather than a Security Architecture Book.
Leave a Reply