Security Guidance and Threat Modeling
RV here...
Security Development Lifecycle and other security development processes help developers build secure application and one of the key outputs of these processes is security guidance. You might ask, what is security guidance? From an architect/designer perspective it includes design patterns which secure the application design. From a developer perspective it includes code snippets, libraries and/or application settings which make the application secure. Apart from this, there are other types of prescriptive guidance like checklists, FAQ etc. which play a vital role in different phases of development cycle. In general they are all "Countermeasures".
Usually security policy team generates the list of countermeasures from the security standards or policies or industry regulations. Development teams need updated and application specific countermeasures which can be achieved through design analysis. Threat Modeling helps in this aspect as it is an analysis activity that is performed at design phase to identifies threats and countermeasures. From the first version of Threat Analysis and Modeling (TAM) tool we have been working hard to ensure that relevant countermeasures are identified by the tool. There are some important challenges in achieving this.
- How to ensure that countermeasures are always up to date?
- How to identify context sensitive countermeasures?
- How to make it easy to implement the identified countermeasures?
In TAM v3.0 we tried to address the first problem by centralizing the guidance. TAM v3.0 tool synchronizes with the repository called Common Task List (CTL) during the startup. CTL is maintained by the security team which consolidates countermeasures from policies, standards and regulations. Updated CTL is automatically applied to the existing threat model. Current CTL only contains standard security best practices.
Second problem is much bigger than the first one. In TAM v2.1 we used relevancies which are tied to components, one or more relevancies resulted in an attack and countermeasure respectively. Relevancies were too high level and were only related to components and mapping countermeasures based on Data Classification or Role Authentication was not possible. For example countermeasures such as "Implement SSL" could not be properly identified as they are dependent on data classification. In CTL we introduced Attributes, an attribute describes business or technical behavior of role/data/component. For example Role Authentication and Data Classification fit properly as attributes.
Each countermeasure is mapped to set of attributes, for example SSL countermeasure is mapped to Data Classification : High Impact and Component Type : IIS 6.0. The following screenshot displays the Component attributes.
From a developer perspective attributes define the properties of the system which are more granular and easy to specify. Third question of how to enable easy consumption of countermeasures involves people, process and technology. From technology wise TAM v3.0 allows user to print reports that include step by step instructions for each countermeasure. TAM v3.0 also allows Team Foundation Server (TFS) export which creates TFS work items. Once in TFS development processes ensures that code does not ship without closing the security bugs. Developers (people) need to then implement the countermeasures as per the step by step instructions of the bug.
TAM v3.0 has evolved a lot with respect to providing security guidance. Going forward with introduction of CISF Controls Framework, we will be able to leverage more centralized guidance.
Thanks
Anil