Statement of Applicability & Gap Analysis specifications
Draft version.
Purpose
This feature aims to carry thorough mainly a statement of Applicability (SOA) and a compliance level of referential security or any other.
Front End Specifications
Create and risk analysis Views
A risks analysis could pick 1 to n referentials on monarc-common DB. See figures 1,2 and 3.
Figure No 1
.png "Edit_risk_analysis(2).png")
Figure No 2
.png "Edit_risk_analysis(3).png")
Figure No 3
Risk Sheet View
The security referential field could to list the controls releated to risk. Actually, only 3 controls can be linked, so it would be consider to link 0 to n controls. User could detach the controls linked and add new controls. See figure 4.
.png "Risk_sheet(1).png")
Figure No 4
If there are several referentials, those would be arranged if it's possible by tabs (proposal). See figure 5.
.png "Risk_sheet(2).png")
Figure No 5
SOA an GAP Analysis View
It will be a new view to create and will be reachable on 4th step of MONARC (Implementation and monitoring) (Proposal)
This views will show a table like in figure 6 for each referential arranged by tabs.
Figure No 6
Adding an SOA
The customers or the CASES team have to add SOA. Customers for their own use and CASES to share via the common DB. The view for CASES must be implemented in the Back office and for the custommer in the Knowledge Base Management. This view replace the "27002 controls" view.
Link the SOA and the informations risks views
The view to create or modify a risk must be modified to include the measures of the new or existing SOA (like the ISO 27002 measure actually). This link can be done on the risk sheet (figure 4 & 5) but also in the Knowledge Base for the client side.
Export the ANR view
A person who export an ANR can choose, if he wants or not export also the SOA part. So the export view has to be modified too.
Back End Specifications
Prerequisites
To avoid a double charge of work, the modification concerning the database and especially the multilingualism one in MonarcAPPFO#7 has to be done.Indeed the SOA will bring new fields which would be translated.
Modification in the DB (non-exhaustive list)
The ISO 27002 measures (e.g. 27001 Annexe A) must be changed, indeed currently we can only attach 3 measures maximum to one risk (e.g. amvs table). With the new functionality, an N-N table has to be created between the amv and the measures. (the amvs table represents the Knowledge Base).
Following the same principle the table intances_risks which represent the current risk in the ANR has to be linked with the measures (proposed by CASES and added by the user).
A new table must be created to handle the SOA (name etc..)
A new table must be created to handle the link between the SOA and the measures.
The SOA
The SOA is characterised by :
- Its name
- A little description
All this information can be translated in several languages. CASES offer some SOA (including measures) (in the common DB) managed by the Back Office. The client can also add is own referential by analysis (via the knowledge base).
Proposal : can be interesting to add for the whole customer environment ?
The measures
A measure is characterised by :
- A Reference
- A control
- A requirement
The measures can be grouped in different themes which can be imbricated one within the other. For example, in the figure 6, the point 5.1 is imbricated in the point 5 and the 5.1.1 is the control.
All this information can be translated in several languages.
The link between the SOA and its measures
A SOA have to be attached to 0..N measures. A measure can be attached to 0..1 SOA. The deletion of a measure or all the measures don't involve the deletion of the SOA. The deletion of the SOA involved the deletion of the attached measures.
The link between the SOA and the risks
As mentioned in the figures 4 and 5, a link between the SOA and the risks have to be created. A risk can have 0..N measures from 0..N SOA. This link can be done at the "instances" level and at the "AMVs" level (cf tables in DB). Following the same rules that are existing for the risks. A measure added at the "AMVs" level is available for all the analysis. A measure added at the "instance" level is just available for this instance.
The GAP analysis
The GAP analysis takes all the measures grouped by SOA which are present in the current risk analysis. For each measure we can precise diffenrent field :
- A justification
- A list of evidences
- A list of actions to take
- A score who repensents the level of compliance
Priority in the dev.
The project can be cut in different phases which do not have the same priority.
