Security Series: Threat Modeling 3 — Documentation and Deployment
Security has quite a few paths and a lot of challenges. This series aims to help you find your path, learn step by step and bring transparency to the mountain of design choices. It will teach you principles, not formulas. There will be some simple, but also complex case studies to further extend your understanding.
Why does documentation matter and what should we document?
“Institutional knowledge is mostly gathered during the design and development.”
The Problem
Uncertainty on impact: Any later changes to fix vulnerabilities or apply patches might affect other system parts that have dependency on the vulnerable to be patched part. This creates a situation where you are unsure on the impact.
Team dynamics: If the team membership changes, then any knowledge that is not documented can be lost.
Audit-ability: Critical systems are often demanded by law to be audited and checked on regular basis. If no proper documentation is available, then the audit process might take extended time.
The resolution — Why
Well documented threat model can help new team members to pick up the ongoing progress, prevent double work and create transparency for incident management and disaster recovery activities. Furthermore, it can be the key enabler to future projects because a well-established structure can be reused as a template for many more related projects and increase the overall efficiency.
The resolution — What
Important points worth mentioning are obscure data points and justification and general thought process.
“Why do we do it like this here”.
Any decisions to overcome constrains are good candidates. This does not only apply for designing, but also for the deployment. In general there is not the one and only methodology or template for documentation. But here are some relevant points:
DATA AND USERS
In order to understand the likelihood of an attack and the relevant impact, you must understand what you want to protect. Usually it is data. This means you need to select a data classification. Then you should evaluate the intended audience to have access to the data (users and roles) and the level of access (privilege) to them (read / write). This can be collected into a Role Based Access Matrix (RBAC). This is only the start. After defining the RBAC you need to invest thoughts on user access management (UAM) which involves the process of creating and removing users, required approvals, auditability and enforcement details.
NETWORK AND DATA FLOWS
An inventory of network ports, their protocols are important to collect and integrate on an overview of the data flow in the system. Concerns on firewall configuration, authentication and authorization should also be included. Usually this can be included into the High Level Design (HLD) or Network Diagram (NWD) with addition to the Communication Matrix (CommsMatrix).
PROCESS AND MANAGEMENT
A reference to inventory of third-party components and libraries, inventory of security controls, how they are kept up-to-date (patch management), efforts for hardening including details such as owners and responsibility holders, disaster recovery plan and any assumptions on the configuration and a shared responsibility model for complex systems.
Documentation is a continuous process.
In general, there is no complete documentation, because as the system will further develop over time and so should also the documentation when done properly. A good documentation is the one that describes relevant points in a simple manner while not losing on details. I’d recommend to ask yourself: Does this picture, diagram or written text help? Will I still remember this small but impactful detail couple of months later? Am I the only one to have this knowledge?
Documentation is helpful.
Now that we understand the importance of documentation, it is time to further expand. We will continue on the next blog-post on this series. Stay safe, and continue the learning soon.
If you enjoyed the key points, you might also consider reading the book Threat Modeling — A Practical Guide for Development Teams by Izar Tarandach & Matthew J. Coles, which this series is based on.
Documentation and Deployment 3— Fin.
