Pending:
- when building mappings we realised their overlap is incredibly loose, the mapping concept is a complete joke, but people wants this stuff so we give them the loose definitions with a big warning
Ref: https://docs.google.com/spreadsheets/d/1DhpJ83zpejFttD4MN2h8q6XHOGm9ucN5D8w1Fy-pAIo/edit
-
after different approaches, the quickest way and that is likely to give you better results is to identify one or more policies for each requirement, TBC
-
If the Package/Requirement will be needed for templates in the future, perhaps we can already use it for Templates and simplify the mapping feature.
-
for templates of controls and policies, we can not rely on those mappings because they are too loose, we need to know what package they are working and provide templates against the package/requirement item
-
we need to go requirement by requirement and define controls and policies, these will be re-used many times across packages
-
we need to provide templates that include the relations mentioned above
-
Mappings Base DB: ISO 27001:2022 (on it), SOC2, NIST CSF 2.0, Critical Security Controls 8.1, GDPR, HIPAA, DORA, NIS2
Currently Mapping Functionality
- you have to define the source and destination
- whatever is mapped to the source, automatically goes to the destination
- the destination can not have a mixed asociation of automatically mapped items and custom items
- the destionation can not map to other packages
- fields defined on the source (list below) are automatically assigned to the destination:
- Controls
- Policies
- Exceptions
- Audit Findings
- All three Risks
- these fields, on the destination, are “blocked”, meaning you can not edit them
You can tell what will be sync, when you edit the “source” you see the sync icon:
Once the asociation of solutions to problems has been made, you see the following columns on the filter (source and destination):
if i try editing the destination, items are disabled:
If i remove the mapping, what was mapped stays mapped:
Proposed New Mappings
we want to eliminate the hierarchy mapping (one in front of others) and make a flat mapping association, this eliminates the dependency of a “main package” and allows you to map things easier:
- Similar compliance requirements are “Grouped” by something we call “Mapping Groups”
- We will ship with a number of “Mapping Groups” and users can add custom ones if they wish
- Our compliance packages will already include associations with these “Mapping Groups” making these seamless for users
- The “Association” of “Solutions” is sync automatically on those items that share a Group
- We also allow “Override” settings, so items in a group can have custom “Solutions”
Functionality Details
-
Compliance Packages Item Management
-
Compliance Analysis
-
Index and Reporting
Packages Management: what will the new package csv look like?
The standard format for a compliance package will include an additional, optional, column for “Mappings”, this column has the following description: “Optional - Add one or more Mapping Groups, if you need more than one group use the pipe character. For example: Access Management|Physical Controls”
You will define “Mapping Groups” as a “Setting” in “Compliance Packages”. We will ship with a list of “Mapping Groups” that can not be edited or deleted, the user can add new items (and edit them later on). Mapping Groups in use can not be deleted.
Compliance Packages Management: what happens when you add a compliance package item?
The process by which you add a package is the same as today, what changes is that if the package includes mappings or not must be validated (the Mapping Group must exist) at the import or addition time.
NOTE: the addition of a “compliance package item” associated to a “Mapping Group” will FAIL if there are existing LEGACY “Compliance Mappings” defined
NOTE: If the user adds/removes a “Mapping Group” that will trigger “Associations” then we need to warn the user.
The tab “Compliance Package Items” will now have an additional column called “Mapping Groups” with these new fields if applicable.
NOTE: there must be a “Mapping Sync” process executed after the package has been imported
Compliance Packages Management: how you edit a compliance package item?
The user can edit any row and add / remove “Mapping Groups” one by one or using bulk edits.
NOTE: If the user adds/removes a “Mapping Group” that will trigger “Associations” then we need to warn the user.
NOTE: there must be a “Mapping Sync” process executed after the package has been modified
Compliance Packages Management/what happens if you delete a compliance package item?
NOTE: If the user adds/removes a “Mapping Group” that will trigger “Associations” then we need to warn the user.
NOTE: there must be a “Mapping Sync” process executed after the package has been deleted
Packages Management: Mapping Sync Process
You need to run a “Mapping Sync” process when the user manipulates:
- A compliance package in the “Compliance Package” module that involves “Mapping Groups”
- A compliance package item in the “Compliance Analysis” module that involves “Mapping Groups”
The reason for this is because “Compliance Package Items” can (or not) have associated “Related Items”. Today this is visible when you go to “Compliance Analysis” and you “Edit” a row. The list of “Related Items” is:
- Controls
- Policies
- Exceptions
- Audit Findings
- All three Risks
We will describe now all the possible scenarios when this “Mapping Sync” process must run and what the logic should be:
A- When a compliance package item is created and is linked to one or more “Mapping Group”
B- When a compliance package item is edited and is added or removed from one or more “Mapping Groups”
The logic for the “Mapping Sync” is:
- make a list of all “Related Items” of every “Compliance Package Item” associated with each “Mapping Group” involved. Then make sure the newly associated “Compliance Package Items” get associations with all those “Related Items” (avoid duplicates) from the previous step
- make sure that if the newly associated “Compliance Package Items” has any pre-existing “Related Items”, these items are mapped to any “Compliance Package Items” related to the involved “Mapping Groups”.
The following scenario shows what happens before (left) and after (right) “Compliance Package Item” named “800-536.7” is associated to “Mapping Group” by the name of “Group A”
Following the logic described above (3 steps):
- You will associated “Control B” (from previous step) to item “800-53 6.7”
- You will associate “Control A” and “Policy B” to the item “NIST CSF 5.6”
Note: CIS 5.6 and SOC2 4.5 are not involved as they are not associated to the affected “Mapping Group”
Packages Management: What happens if you delete a mapping
When a mapping is deleted from the “Compliance Package” module (see above how that is done) it means that the item is deleted OR it has been disassociated from a “Mapping Group”.
TBD: do we remove solutions mapped or we leave them? today we leave them. we could leave this up to the user
Index and Reporting: How you see mappings on index
Since we now manage a concept of “Groups” it will be useful to display items on modules with an optional “Group By” setting. This setting will be defined per module per field, by default we will just test it on the “Compliance Analysis” module.
The only field we will allow to group by will be “Mapping Groups” field, in theory we should be able to see items on the index as follow:
note: https://docs.google.com/spreadsheets/d/1e9_sWwlRBiHQplDENX_W-Fwu3AACr3416yvqx4vNHrE/edit?gid=0#gid=0
Notice that i show you here on the top as we currently display items and how would be displayed using groups underneath. Sorting and Filters would apply to items the same way as now. If an item has no group by fields, it will show on a default “Not Group” item at the bottom.
Compliance Analysis: Adding or Removing Related Items from Compliance Package Items
Today a user can select one or more (bulk edit) compliance Items and make modifications to the “Related Items” fields AND other fields which are not affected by this functionality (compliance strategy, etc)
When any of the fields “Related Items” changes (add or removes items) in theory, we should trigger the previously mentioned “Mapping Sync” process, but there is a catch. We call them “Override Associations”.
The normal “Mapping Sync” would keep something as shown on the left diagram. We need to give users the chance of editing, for example, “Compliance Package Item” by the name “NIST CSF 5.6” and remove, only for this item, the association with “Internal Control A” WITHOUT affecting “800-53 6.7”. This will be called an “Override Addition” or “Override Deletion” (or something like that). This is represented on the diagram in the middle and on the right.
From a software perspective, there are two types of associations in between “Related Items” and “Compliance Package Items”:
- Automatic (this ones are caused by the “Mapping Sync” process
- Override (this ones are manually created or deleted and excluded from the “Mapping Sync” process
This will require some highlight on the item when we display them on the form and on the View index, somehow people needs to know which ones where sync automatically and which ones where manually put there (the ones they removed do not need to be highlighted)
Index and Reporting: How we report when mappings exist
TBD
Migration for Existing Customers
We define an “existing customer” as one that has defined one or more Compliance Packages/Compliance Mappings, if a customer does not have mappings defined we will simply hide the tab Compliance Packages/Compliance Mappings altogether.
When customers upgrade and they fall under the “Existing Customer” definition we need to make sure this feature wont work until they delete all their existing mappings. I think the easiest way to prevent them from using this feature is by not allowing:
- the creation of new compliance package items that associate to “Mapping Groups” (via CSV or manual clicks)
- the edition/save of existing compliance package items being associated with “Mapping Groups”
Their migration would require:
- Download mappings as CSV
- Delete all mappings
- Define Mapping Groups
- Update compliance package items using bulk edits so they can be associated with those Mapping Groups
If we could find a way to migrate this with code it would be great, but mappings are too subjective to decide how to group legacy mappings into “Mapping Groups”