I tested Eramba to see the recursiveness of asset risks. I have a small issue: if I have asset A linked to asset B linked to asset C, and if I put a asset risk “aa” on “A” and a asset risk “cc” on “C”, nothing is indicated on B. It has no risk. Why?
Shouldn’t it have “aa” in its risks? And shouldn’t C also have “aa”?
This is probably more a feature than a bug in my opinion - keep in mind, there’s really not a hierarchical representation of asset relationships - it’s simply a flat relationship.
Suppose Asset A is an application and Asset B is its underlying infrastructure. You might have risks created specific to the applications and risks specific to infrastructure that you wouldn’t want to auto associate.
You’ll have to explicitly associate the risk to each asset that you want it to be related to - the display query is simply looking at that relationship and not considering the related asset field.
The principle of a feature is that it brings something. In the case of a link between two assets, nothing is brought. Or am I wrong ?
It’s a bad assumption. If my infrastructure is at risk because of a linked application, I obviously want it to be automatically associated. Otherwise, there’s no point in linking the assets together. Why? Because a vulnerability affecting compartmentalization will not be handled the same way on an application, an operating system, and infrastructure. If I have a risk on the application, I patch it; on the OS, I lock down user permissions, firewall, etc.; on the infrastructure, I isolate the VM on the network, etc.
The advantage is that if I have multiple applications, each with several risks, I won’t have to manually sum up the risks of each application. In my case, this can quickly become exponential.
Another advantage is having a vision similar to object-oriented languages with inheritance, which allows for more fluidity in the design of assets