During risk treatment, security goals and new security requirements may be derived or known security requirements, relevant for the system may be selected. They may have relevance for different phases of the system, for example design, but also production and post production. Security goals and requirements and their dependencies can be modeled and documented in dedicated requirements models using a tabular or graphical notation. They can be exported and linked into external requirement management systems to track them or imported from those kind of systems or knowledge databases.
Select a package that is designated for requirements modeling and use "New | Requirements Model" to create a new model. The model is initially empty and by default a single new diagram is created and opened.
You can start the creation of security goals and requirements and their dependencies using the graphical editor by dragging requirement from the tool palette. The security goals have an Cybersecurity Assurance Level (CAL) associated that ranges from 1 to 4 and depends on the determined risk during the risk assessment.
Use contributions and sub-requirement relations to express dependencies and containment. A security goal may for example define a general "Security aware system design policy", having dedicated sub-requirements for example to "Apply data minimization and limitation techniques"
The model can be, as an alternative, opened and edited using a tabular editor for both cybersecurity goals and requirements. Select the model in the model browser and use "Open With | List Editor" or remove the diagram completely from the model if graphical notation is not used at all.
Instead of creating a security requirements model from scratch, it can be also imported from an external RM system as DOORS NG, Jama or PTC Integrity. Select a package that is designated for requirements modeling and use "Import | Requirements From X" to import them from an arbitrary system X. There is a detailed description in the user guide about how to map external RM systems to medini.
An example:
There is a set of well-defined security policies in a company, reflecting requirements from the authorities, but also best practices and process requirements. That list is available in a Jama repository and has to be applied to all projects.
The appropriate package/set is imported from Jama, making all requirements and their relations available in medini.
Among them there are two generic requirements named "Security Controls shall be applied to back-end systems to prevent data breaches" and "Access control techniques and designs shall be applied to protect system data/code". The first one (among others) addresses HR security and security awareness with measures like "Appropriate training for staff", while the second (among others) addresses system design principles with measures as "System monitoring" and "Network segmentation"
Both requirements are used to mitigate a risk that was identified by a compromised software backend server, basically caused by an "Abuse of privileges by staff" (insider) attack.
