Musings on security architecture

Time for something a little more intellectual than usual. Here's a list of Do's and Don'ts when it comes to Security Architecture. Purely personal opinion. Feel free to argue. Feel free to agree. Feel free to ignore.

Do collect all of your security requirements from your business stakeholders, your regulatory environment, your wider enterprise and industry standards

Don't present me with an endless list of requirements saying the same thing but in slightly different ways. Consolidate your requirements set but maintain traceability by stating where your consolidated requirements originated

Do obtain sign-off from the relevant business stakeholders that the requirements are correct

Don't tell me that the Head of Security has approved the requirements and so we're good to go...

Do perform a comprehensive risk assessment of the system/service in question

Don't come back with a set of risks so abstract as to be useless - "An attacker may gain unauthorised access to my data" - well yes, but what's the business impact? What's the data? Who is the attacker? And are you talking physical or logical access? And are there any relevant attack vectors available to the threat actors you're worried about?

Do obtain business sign-off that the risk assessment is valid and caters for the risks that they care about

Don't tell me that the Head of Security has approved the risk assessment and so we're good to go...

Do define a set of security services based on your requirements and your risk assessment

Don't give me any services that cannot be traced back to a requirement or a risk. We're not doing this for the sake of it... It may be 'best practice' but do you need 'best practice' or is what you have good enough?

Do consider how your security services interact and how they are used by the relevant actors

Don't get bogged down with fully elaborating a security architecture - mental masturbation may be fun, but it's not productive. Do what you need to do to validate that your architecture is appropriate and is as complete as it needs to be.

Do consider any wider enterprise architectures that you are operating within. Your work may just be a view on a wider architecture

Don't simply assume re-use of existing services defined in a wider architecture without validating that they meet your requirements and are available for your use

Do tell other people about your work - an architecture is worthless unless it's used to influence design, build and run. Don't lock yourself away in an ivory tower and then complain that you're being ignored.

Don't exaggerate the importance of your work - architecture is a tool, sometimes a piece of art as well, but most importantly a tool.

Do remember that you're working in the real world. Whatever you're working on most likely has to be deliverable and affordable.

Don't be precious. This is just a general comment :-).

Well, that's my quick brain dump of do's and don'ts typed up as I sit here on a train heading home. I've probably missed lots of really important stuff - I may even have got some stuff wrong. In your opinion. Let me know.