We are currently performing our risk assessment through the Asset Risk Assessment module. In our previous spreadsheet based processes we used to have a lifecycle for certain vulnerabilities, which would be really good to include within Eramba, currently they are a static list.
For example, we have a penetration test on our website and it identifies an out of support library. The risks relevant to our website we would record in the asset based risk assessment. We can select the generic vulnerability “Web application vulnerabilities” but it would also be good if we could select the specific vulnerability identified in that test (as granular or generic as we wish) and that vulnerability has it’s own lifecycle.
So the vulnerability would have at very least a review period assigned to it but if custom fields could also be enabled then even better, we can use it as we wish then.
This would help make the vulnerabilities more explicit where needed and also bring in some management of the vulnerability lifecycle. Appreciate Eramba isn’t a vulnerability management platform, but some slight additions/custom field options would bring alot of flexibility I think.
Same could also be said for Threats, being able to add custom fields to threats would also bring alot of flexibility I imagine and hopefully the code is already there for re-use
i believe that the best way to track something complicated is to use a specific tool that was built for that purpose:
want to track payments? use an accounting software
want to track if endpoint is deployed everywhere? use an endpoint solution
want to track if your linux configurations are ok? use a configuration management tool
want to track if your routers are being maxed out? use a bw monitoring tool
want to track OS vulnerabilities? use a vulnerability tool
want to track website vulnerabilities? use a vulnerability tool
what im trying to say is that everything is a risk, but thinking that is possible to track every risk in eramba (or any single tool) is unrealistic and impractical, because that is why we have specialized industries that address specific issues: tools and people
is tempting to think, a soft. vulnerability is a risk and i will track it in eramba, but the truth is:
a vulnerability is one (of many) attributes of a risk, not a risk on itself
the risk is likely to be, for example: “my website can be hacked” (in eramba, we call that a problem) … the treatment can be an internal control, for example: “vulnerability remediation reviews” , “SLDC deployment reviews” … (in eramba, the solution) …
the controls above, should have a testing methodology, for example: vulnerabilities identified should have been fixed within x weeks and logged in this system this way and that way. releases should have been tested before sent to production, etc
so…in eramba you need a control as above and then test that control … what you test is the PROCESS (sorry for the caps!!) … the number of vulnerabilities found is irrelevant unless your testing methodology includes that metric.
so … no , eramba is not a vulnerability management tool nor we plan to become one in the short term … there are very professional tools to do what you describe in far more automated ways (automated retesting, notifications, automated reporting, CI integration, etc) and far more interesting ways (tenable, acutix, etc) to do it … i would definitely work with those tools.
sorry to be a bummer but we think talking straight is the way to go
From a true Risk Assessment perspective, the risk never goes away - the Analysis and Treatment evaluations change over time. The fact there’s an open vulnerability from a pen test may indicate a lower control effectiveness (or, in Eramba terms, a lower Treatment evaluation) than it would be if you had no findings on that particular penetration test.
So, I’d consider the following for how you document this flow in Eramba -
Year 1, dirty pen test report → Analysis = High, Treatment = High, Associated project = Remediate pen test findings
Year 2, clean pen test report → Analysis = High, Treatment = Medium, Associated project = none (as it was completed).
As @kisero said, you don’t want to go tracking this stuff on a line item by line item basis. If it’s big enough to warrant a project, then go for it, but if it’s just a task to fix one deprecated library from a scan/pen test, that really comes out in the wash with your Treatment evaluation. I also find it unlikely that you’re re-reviewing your risks on a cadence that’s anywhere near the pace that you’re tracking vulnerabilities and the associated remediation.
As a side note, I’ve yet to meet a scan vulnerability tracking tool that I’ve actually liked…
