Solved

Threat Modeling of products that are based on internal "platforms"

  • 21 October 2022
  • 2 replies
  • 52 views
W
Rank
Badge

We have more and more setups where products are built on internally provided “platforms”. For example an AWS-based microservice environment that products can use to build their microservice-based products upon. These platform covers parts of the countermeasures but some of them have to be covered by product.

Another example is that AWS accounts that are used by products are not empty and free configurable accounts but part of our AWS organization where several things are preconfigured and/or enforced by SCP (Service Control Policy). For example the whole CloudTrail logging is configured and enforced centrally.

We looked into IriusRisk templates but according to my understanding this is a one-shot approach and further evolution of he “platform” can’t be synced into the products using it.

We internally now found a solution by using an Excel and a Python script that generates a rules library xml that we import into IriusRisk to trigger rules that set certain countermeasures automatically to “implemented” when a component is in a corresponding trust zone. Ideally this functionality would be available within IriusRisk.

Our questions are:

  • Do you also have such “platform” use cases?
  • If yes - How do you cover them in IriusRisk?
icon

Best answer by JamesR 21 October 2022, 15:57

View original

2 replies

JamesR
Rank
Userlevel 3
Badge

Great question. Inferring contextual relationships between adjacent components is a difficult peak to summit. Some organizations have used the rules engine to create this relationship between an overarching environmental control set and moving countermeasures into an implemented state. 

This could be done by using questionnaires at the component level or even nesting components inside of other components which then allow you to use the rule engine to effectively state that If parent component equals CloudTrail logging, then any countermeasures related to cloud trail logging could automatically be moved into an implemented status. This could also be accomplished by adding a question to the main or component questionnaire.

James Rabe
W
Rank
Badge

Actually we already had/have a solution. The colleagues that owned IriusRisk within our company before I took over, created new trust zones and built rules based on them (e.g. “If an EC2 is in the trust zone ‘Platform 1’ then the countermeasures x, y and z are set to implemented.”. I kept my question open, as I was not sure if our current approach is the best one.

My experience regarding the definition of many rules in IriusRisk is that this is a very cumbersome process via the UI. Because of that I developed a more efficient “workaround solution”. We export the countermeasures that specific components generate in a structured Excel. Then the colleagues that own this platform provide which specific countermeasures they fully cover with their platform in this Excel. This Excel serves as an input for a short Python script that generates an IriusRisk library xml file that contains all the necessary rules. We then import this in IriusRisk. According to our experience this works quite well and reduces the effort for rule creation in IriusRisk by at least 99%. 

Of course it would be better to have this within IriusRisk, i.e. without an IR-external Python script but as long as it works……...

We also use the same solution to import the security requirements from our Information Security Standards in IriusRisk to offer the products the opportunity to track their compliance with these requirements in IR too.

Reply


Terms and Conditions, Community Guidelines and Privacy.Cookie settings
V2