Have you every tried to understand the risk level of a service? Ever wanted to provide assurance to someone that “it’s been well designed, is secure from common threats, likely risk scenarios and is securely operated” etc.? have you ever tried to conduct testing against a service that is relatively unknown? Ever needed to actually do more than throw some packets at the front door? Guess what, I have. Most orgs don’t have a decent level of documentation on service architecture and security controls. And as the NSA nicely put, the way they get into networks is to know them better than you do! So in my travels I see lots of different orgs and largely there’s one common similarity, most of them aren’t well documented (docs are boring right!) and if we then make another huge sweeping generalisation, about 90% of orgs have security postures you wouldn’t want to have to defend as a blue teamer, but you might fancy if you were a nation state actor or cyber criminal!
So I feel like I’ve written a document like this once too many times, services aren’t cookie cutters so there’s often a requirement to create artifacts that are useful to the context, scenario and specific service architecture, however, I figured I’d make a template to share with the world to make people see and think about the kinds of thing I look at when trying to:
- Understand a service
- Understand it’s architecture (it’s components and how they fit together (people, process and tech/sec)
- Understand it’s controls
- Understand it’s quality
- Understand it’s business context and broad requirements
So without further rambling, here’s a template, feel free to adopt/adopt and well do what you like with it really but please give credit if you use it