Purpose 

The purpose of this article to provide some common use cases for when a project component would be a good fit. 

Required permissions

PRODUCT_COMPONENT_CREATE - to create project components

ARCHITECTURE_UPDATE - to add project components to a diagram

Answer 

Project components function as threat models within threat models. By design, project components do not carry any threats of the parent project into the project they are nested in. This is to prevent any duplication of threats or countermeasure and any duplication of work effort from development teams. 

Use Case 1 - I want to reduce scope in my threat model

A project component could be used to reduce the scope in your threat model. By segmenting an application or infrastructure into parts and into multiple threat models and then tying them together using a project component or a series of project components, the threat model can be simplified dramatically. 

Use Case 2 - I want to link different parts of my environment together to demonstrate the exchange of information.

Most environments have many connections between interrelated applications and support functions. Because of this, no threat model generally exists in isolation. To provide for this interconnection, project components can be used to visualize and tag which asset or assets are being transferred throughout the ecosystem. Additionally, dataflows can be tagged with specific protocols which demonstrate how that information is being exchanged between parts of the environment. 

Use Case 3 - I have a shared system that may interact with several threat models but only needs to be threat modeled once and referenced multiple times. 

Some systems which integrate heavily into multiple applications might need to be threat modeled once and then referenced continuously. For example, Azure Active Directory might be threat modeled within a unique threat model but might then be used for authentication and authorization within several additional threat models. By threat modeling Azure Active Directory in one threat model and then using the project component of the Azure Active Directory threat model in the others, it can substantially reduce the effort and complexity of other threat models. Additionally, using the rules engine, additional threats can be added to any threat model where a project component is used. These threats would only include the threats that are relevant when additional integrations or dataflows are added to a project component. 

Example of a rule that only fires when the project component is added to a diagram: 

Example of a rule that only fires when the project component is the source or destination of a dataflow:

Example of a custom drool that could import that same risk pattern if the Project Component was the source or destination. This rule would need to be dataflow module. 

package com.iriusrisk.drools;


import com.iriusrisk.drools.model.*;
import com.iriusrisk.drools.model.riskpattern.*;
import com.iriusrisk.model.*;
import com.iriusrisk.*;
import com.iriusrisk.drools.fact.*;
import com.iriusrisk.factories.DroolsValueConverter;
import com.iriusrisk.utils.EntityWithUDTUtil;
import com.iriusrisk.drools.fact.TagFact;

rule "Project Component - Data Flows"
no-loop
when
$project : ProjectFact()
$dataflow : DataFlowFact()
DataFlowDefinitionFact(componentSourceUniqueId == "sg-project", componentSourceReferenceId==$dataflow.componentSourceReferenceId) || DataFlowDefinitionFact(componentTargetUniqueId == "sg-project", componentTargetReferenceId==$dataflow.componentTargetReferenceId);

then
insertLogical(ImportRiskPatternFactory.importRiskPatternInOrigin("test-library-1", $project.getUniqueId(), "new-risk-pattern", $dataflow.getComponentSourceReferenceId(), 50, $dataflow.getUniqueId()));
end