[RFC] mgmtsystem_risk: Risk Management Platform

[lasley]

This module will provide the base for a risk management platform to comply with things like NIST and HIPAA, among others. There's some proprietary software for this but I would prefer to be using something Open Source & integrated into Odoo.

The high level goal is to provide the ability to perform a risk evaluation and subsequently create necessary management plan and compliance reports. A lot of these concepts seem to exist here in an abstract sense, but putting the pieces together for this context looks a bit rough without some more dev.

Disclaimer - I'm new to this repo, so please let me know if I'm duplicating any concepts or interpreting one of the pre-existing ones incorrectly (particularly mgmsystem.system & how the existing surveys are used). We would then create some data modules to add in the contextual surveys required for the evaluation types (such as HIPAA security questions).

These docs are helpful:

• NIST full guide - http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-30r1.pdf
• NIST Definitions & Calculations - http://hipaacow.org/wp-content/uploads/2012/01/NIST-Definitions-Calculations-01-06-12.doc
• NIST checklist - https://docs.google.com/document/d/1iJmtMDwBhq_FU5bo_8_VSiPognzALRlEbIeZx9GB8V4/edit
• HIPAA Template - https://docs.google.com/spreadsheets/d/1DjvLGkc7w1Vxgu0NMq-CsHxtYc2OtDKHg-CZ4VG7MQc/edit?usp=sharing

There's a great flowchart in the NIST doc that is worth pulling out directly into this issue:

From a system scope level, I think we need:

• A Risk Assessment concept (mgmsystem.risk.assessment) - mainly to encapsulate reports (note some things in this concept are explained in subsequent concepts):
  • Select partners that assessment is being performed for (no selection == all partners)
  • Select the risk surveys to apply to the risk assessment
  • Generate risk assessment reports for systems owned or operated by selected/all partners:
    • System boundary, functions, criticality, sensitivity
    • Threat statement containing aggregation of claims history and intelligence reports relating to involved systems
    • List of potential vulnerabilities for associated systems
    • Leftover items from previous risk assessments
    • Audit improvement opportunities that are still open
    • Nonconformities that are still open
    • Security requirements breakdown for systems
    • Security test results (system hazards => Implementation Tests)
  • List of current and planned controls (system hazards => control measures)
  • Likelihood Ratings
    • Aggregate ratings of origin motivation probability, origin capacity and correlate against controls
  • Impact Rating
    • Aggregate ratings of system criticality and sensitivity against integrity, availability, and confidentiality KPIs
  • Risk Determination - it seems like this might need to be fully manual
    • Likelihood of threat exploitation
    • Impact magnitude
    • Adequacy of current controls
  • Control recommendations - Recommendation of new controls to be implemented against sytems, similar to an audit recommendation
  • Results documentation - Everything above in an immutable package
• Add concept of associated systems to mgmsystem.claim
• Enhanced system concept - basically a full system inventory
  • Add category hierarchy
  • Add type (hardware, software, etc)
  • Add system templates (e.g. "AWS Server" template for use on all servers implementing this AMI, "keyboard" for keyboards, etc.)
  • Add description
  • Add functions
  • Add criticality level
    • Data
    • System
  • Add sensitivity level
  • Data
  • System
  • Add location
  • Add intra-system dependencies
  • Add OS and software versions
  • Add abstract identifications (serial number, make/model, etc)
  • Interfaces in/out
  • Interface functions
  • Security requirements (hazards)
  • Add partners
  • With access, and their role with the system
  • Stakeholders (operator, provider)
  • Owners (such as if it is a server run for a customer)
• A new mgmsystem.intelligence concept allowing to the input of intelligence reports correlating to system or system category
• A new mgmsystem.hazard.capacity concept allowing for the definition of origin capacity ratings
• A new mgmsystem.hazard.motivation concept allowing for the definition of hazard motivation factors, each with their own mgmsystem.hazard.probability rating
• A new mgmsystem.hazard.category concept allowing for the categorization and templating of hazards
  • is_security to indicate that the hazard is a security threat
  • Type
  • Origin
  • Control measures (tab from existing Hazards)
  • Analysis (tab from existing Hazards)
• Updates to hazards:
  • A m2o relation with mgmsystem.hazard.category
    • Use an onchange to set the fields that are set in the category, but not in the hazard (type, origin, etc).
  • A m2o relation with mgmsystem.system to define the system that the hazard is related to
  • New field on mgmsystem.hazard.origin m2o to mgmsystem.hazard.capacity
• A new Risk Surveys concept allowing for the definition of risk management questionnaires. I am looking into inheriting from the existing survey concept, but I think that will be more trouble than it's worth here due to the fact that multiple users will need to answer different questions on the same survey. It also may make sense to combine this concept with the pre-existing audit concept.
  • The template should contain a method to create a new survey from it containing one mgmsystem.risk.survey.line for each mgmsytem.risk.survey.question in the mgmsystem.risk.survey.template
  • The following fields are required on the survey template (mgmsystem.risk.survey.template):
    • Survey name
    • Template lines
    • Answered surveys
  • The following fields are required on the survey questions (mgmsystem.risk.survey.question):
    • Policy number
    • Regulation number
    • Category hierarchy (mgmsystem.risk.category)
    • Legal requirements
    • Responsible department
    • Vulnerability / Threat Pair & Description
    • Assessment Question
    • Recommended actions/controls
    • Related policy
  • mgmsystem.risk.survey.line should be inherited from mgmsystem.risk.survey.question and also contain:
    • Current State
    • Current State Comments
    • Likelihood (mgmsystem.hazard.probability)
    • Impact (mgmsystem.hazard.severity)
    • Risk level (calculated TBD)
    • Actions/controls completed
    • Actions/controls remain (computed from the recommended controls minus the completed)

Sorry for the gargantuan RFC, but there are a lot of pieces to this concept. I will probably be making some changes to this as the idea simmers & I play around with pre-existing concepts a bit more.

I would love to hear if anyone has some thoughts, or knows of some concepts that I'm missing & could leverage to simplify things.

cc @LasLabs @max3903

[max3903]

@lasley I am not familiar with NIST but it looks like a methodology to perform the initial risk assessment and provide all the initial data to enter in the mgmtsystem_information_security app and be compliant with ISO 27001 standard. Am I correct?

I went through this process couple years ago with another methodology: EBIOS and we decided not to make any module to support it as we were figuring out the models. Couple spreadsheets did a pretty good job, but based on this experience, a NIST or EBIOS module could provide an Odoo planner to guide the user though the process of the analysis and fill in the data in the right place in Odoo.

What do you think?

[lasley]

@max3903 - Due to the copywritten nature of ISO I'm not totally familiar with that spec, but from the bit I see and the code in mgmtsystem_information_security I would say that you are completely correct.

We also use spreadsheets for our own Risk Assessments at the moment, but things need to get a little more streamlined because my customers are beginning to ask for this service. Realistically I probably should have planned this longgggg before now due to the regulatory environments I love to work in, but I kind of let this one smack me in the face.

Do we have the concept of a Risk Assessment now? While an audit could technically be counted as that, I think that they are two different beasts in terms of context and flavor.

The other big ask here is a system inventory with linked interdependencies. Assuming that I am understanding mgmsystem.system concept correctly, this feature essentially just adds a bunch of fields to that model. But looking at this, a system inventory might actually make sense outside of mgmsystem context. I'm not sure what other repo it would belong in though.

Most everything else is just enhancements to pre-existing concepts in order to provide more granularity and relationships.

[max3903]

@lasley I've never heard of/searched for any risk assessment module.

mgmtsystem_security_event should provide the inventory you are looking for.

[github-actions[bot]]

There hasn't been any activity on this issue in the past 6 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days. If you want this issue to never become stale, please ask a PSC member to apply the "no stale" label.