Security architecture and document reviews

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


  • 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.

How to write a report

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.

Published by vanderaj

Just another security geek

Join the Conversation

1 Comment

  1. There might be One True Way for many things – but humans don’t necessarily work or think in the same way. Also, when designing an architecture there will be many considerations to take and Security is an important one but certainly not the only aspect.
    Therefore, I beg to differ somewhat to the “uber-architectural” approach:
    I”d argue that in a team effort to create an architecture you’ve got to be tough enough to botch communicate clearly and honestly about issues that are critical. However, you may also be prepared to give up on areas that you identify as lesser importance (whether they be less risky/critical issues, or document form/layout) in order to get the main message across.

Leave a comment

Your email address will not be published. Required fields are marked *