Automatically score Vulcan assets

[jroimartin]

This proposal is a first step towards extending Vulcan to score assets automatically. It proposes an implementation that extends the data model of the Vulcan Assets to include the Blast Radius Score calculated by the Security Graph. This implementation also covers the services required to keep this score up-to-date. It takes into account that, in the future, we will integrate automatic scores from other data sources.

It is out of the scope of this proposal:

• Redesigning the current manual scoring implementation used by Vulcan.
• Extending Vulcan to take automatic actions based on a combination of manual and automatic scores.

[jroimartin]

Design document: https://github.com/adevinta/graph-proposal/blob/auto-score/design/1-auto-score.md
Pull request: #2

[manelmontilla]

I like the proposal. I think that, although we still have a lot of uncertainty about how we are going to use the automatic scores, the proposal handles well that uncertainty by storing an array of "automatic" scores. In any case, I have minor comments regarding the details of the solution:

• Related to the process implemented in the cron job

  • Between the time we get an asset to be updated and the time we effectively update its score, that asset could have been removed from some or all its teams and we will have to just discard the update. That's not a deal breaker because, in any case, we can't guarantee that after the process runs, all the assets in the vulcan-api will have a blast radius score, but I'm mentioning this here because maybe it's worth adding to the proposal how we are going to address this problem.

  • I also think we should document in the proposal that our aim in the future is to continue having just one process updating all the scores stored in the AutoScore field. That's because if in the future we want to have one component for updating the blast radius and, for instance, one component for updating other automatic score, the coordination between them is going to be hard as they are going to update the same field. I'm okey with this trade off, I just think we should document it.

• I think we should reflect in the design document that we accept that, in the future, we could need to add other columns related to scores if we want to use these scores to sort the results of queries. That's because the data stored in the field can't not be directly used to sort results because is not just a number but something more complex. By now, as we only plan to sort the findings in the UI by the blast radius of the asset it affects just as a secondary criteria (the first one will continue to be the criticality) it won't be a problem.

[jroimartin]

Archived repository.