Integration: Sticky Standards
The Sticky Standards project allows you to enable and manage applying standards in a "sticky" manner. This means that, once you select a standard to be sticky, it is applied whenever a new component is added to that project's diagram.
- Determine standards to include (optional)
- Run script(s) to enable sticky standards against a tenant
- This can include all standards or the subset determined in the first step
- Custom fields (UDTs) are created at the project level for each standard
- Finally, a library containing custom-created rules is uploaded to the instance
- Configure which standards are to be "sticky" by selecting them in a project's architecture questionnaire
There are three scripts included in this project:
- output_standards.py: outputs all the standards in a particular instance
- enable_sticky_standards.py: enables sticky standards in an instance
- delete_udts.py: deletes automatically-created UDTs
They all share dependencies and are similar in how they are called, though each script has its own parameters and actions. The requirements to run them are found in the file requirements.txt. Install the requirements as follows:
python3 -m venv .venv # OPTIONAL: create a virtual Python environment
source ./.venv/bin/activate # OPTIONAL: activate the Python environment
python3 -m pip install -r requirements.txt
You can see the available options for each script by invoking help on them:
python3 output_standards.py --help
python3 delete_udts.py --help
python3 enable_sticky_standards.py --help
Two parameters are always necessary: the key parameter and either the subdomain or the
domain parameter. The former is the API key that grants you access to the IriusRisk instance
on which you wish to enable sticky standards. The subdomain parameter indicates the subdomain
of a SaaS instance of IriusRisk. So for example, if your instance's URL is acmecorp.iriusrisk.com,
you could use --subdomain acmecorp to specify it. Use the domain parameter for non-SaaS instances,
for example --domain acmecorp.example.com.
It is also possible to store these parameters in configuration files in order to maintain the values between calls. Read the help output of a script to learn more.
By default, all standards contained in a tenant will be included in the enablement. There can be 60 or more standards in a tenant, potentially making sticky standard selection difficult. If you know that certain standard aren't used in your tenant, or simply want to make a subset of standards available to be marked as sticky, then perform the following steps:
Output the standards to a file
API_KEY=a123-b456-c789-d0ab # replace with actual key
SAAS_SUBDOMAIN=acmecorp. # replace with actual subdomain
python3 output-standards.py --key $API_KEY --subdomain $SAAS_SUBDOMAIN --output standards.csv
This outputs all the standards from the IriusRisk instance to the file standards.csv in CSV (tab delimited) format. You then need to delete those rows (lines) containing standards that you do not want to include in the sticky standards.
The next step is to create the UDTs and Rules necessary to enable sticky standards in your instance. This is achieved by calling the script enable_sticky_standards.py against your instance. This will create an architecture questionnaire containing all the indicated standards, allowing project owners to choose which standards should apply.
First, the script creates UDTs at the project level that enable the rules to function properly. The UDTs are not editable, but are visible if you wish to inspect the current settings. They act as a per-project configuration, indicating which standards should be applied whenever a change is made to the diagram. Ultimately, the values of the UDTs are altered by making changes to the appropriate questionnaire.
The second thing done by the script is to generate rules required for the standards chosen. Each standard requires four rules. This means that, if all standards are included, more than 240 new rules will be created. This won't have an effect on performance, as the rules are created with JBoss Drools best-practices in mind.
All the rules are then bundled in a library and uploaded to the instance. The library is named sticky-standards-autogen, and shouldn't be edited or added to manually. If this script is run again, it will replace that library, destroying any manually-added changes.
The script requires the parameters indicated above, plus an action. The action is a key word or words on the command line following the name of the script. There are two actions:
- fields: create the UDTs for the desired sticky standards
- rules: create the rules for the UDTs and upload them in the library as indicated
You can indicate both actions if you wish. For example, if you wish to create the infrastructure to allow all standards to be marked as sticky, the following call would suffice:
python3 enable_sticky_standards.py rules,fields --key $API_KEY --subdomain $SAAS_SUBDOMAIN
You can also do this in stages, first by outputing the standards, removing those to ignore, creating the UDTs, and finally creating the rules that perform the actual work.
The example below relies on a project-local configuration file to store parameters between scripts. You can also create user-specific configuration files, or workstation-global configuration files. More details are available in the script help output.
The following commands will create all the UDTs and rules necessary for activating sticky standards on an IriusRisk instance. The subdomain value should be replaced with a valid SaaS subdomain and the key with an API key for that instance.
cat << EOF > iriusrisk.ini
[DEFAULT]
key = a123-b456-c789-d0ab
subdomain = acmecorp
EOF
python3 output_standards.py > standards.csv # output all standards as CSV
vi standards.csv # edit out the undesired standards
python3 enable_sticky_standards.py fields -i standards.csv # create the UDTs for the indicated standards
python3 enable_sticky_standards.py rules # create the necessary rules and upload them
Note that the final call that creates the rules doesn't need the list of standards, since it will only create rules necessary for extant UDTs, created in the previous step.
One sticky standards are enabled, project owners in the instance can activate those standards on
a project-by-project basis. To do so, they simply need to choose the desired standards on the
architecture questionnaire, under the "Sticky Standards" tab:
Once activate, any countermeasure associated with a sticky standard will automatically be marked as "required" in the system. Note that this cannot be undone automatically, but deactivating a sticky standard means that future countermeasures won't automatically be marked required.