TMOps ‐ Managing Enterprise Content

Introduction

Managing content across the enterprise is challenging on several levels. Those challenges include creating a sufficient catalog of threats and countermeasures to assess systems while also minimizing the volume of false positives or noise. To that end, it is helpful to categorize the controls of the organization into several categories and then apply automation to auto-implement those inside threat modeling software or risk analysis applications.

Types of Controls

Always on Controls - 30%

Always on controls refer to mitigations or controls that are always on because they are applied to shared resources that are used by different parts of architecture or infrastructure in scope for a series of threat models. For example, AWS Environment and AWS Virtual Private Cloud components have a set of mitigations that have already been applied and can be presumed implemented for any downstream project that incorporates those components.

Create a list of shared resources

Review Threats and Countermeasures and leverage the rules engine to “Mark Threat as” or “Mark Countermeasure as” to remove those threats from the threat model or to mark those countermeasures as implemented when they are on the project.

A useful naming convention for these rules is “ - Pre-Assessed Controls” or “ - Implemented Controls” which might look like this - “VPC - Pre-Assessed Controls” when applied to this use case.

Repeat for each Component that exists as a shared resource between multiple threat models. The full set of threats and countermeasures for each component can be exported through the API for viewing using the “All Countermeasures” script at IriusRisk-Central/Integrations/All Countermeasures Report at main · iriusrisk/IriusRisk-Central

Sometimes on Controls - 30%

Sometimes on controls exist in an implemented state when you have additional conditions that need to be considered. For example, some countermeasures would be implemented IF it were in a certain trust zone or IF it was inside of another component. For example, if an AWS WAF existed within a custom component called “Production VPC” it could have several countermeasures marked as implemented. Additionally, we could ask questions about that component using the component questionnaire to determine when those threats or countermeasures apply or are mitigated.

Create a list of shared resources that have countermeasures or threats are dependent on some scenario.

Determine the scenario that auto-applies the rule set (“Component is in Trust Zone” or “Component is inside of ” et al AND “Component is )

Use the rules engine to create this scenario.

Additional conditions that could trigger this include - “Answer Selected” which would then use the answer to a questionnaire to determine which threats are marked as NA or which countermeasures are marked as implemented.

A similar naming strategy could be used for these types of rules.

Not yet on Controls - 40%

Not yet on Controls are the controls that need to be assessed and prioritized within each project. During traditional threat modeling, these are the secure design or security controls that need to be considered. These controls and threats will be generated by the rules engine or by the threat modeling practitioner.