What is a “component” in COB.RA?

A “component” in the context of COB.RA is a collection of (intentional and accidental) threats and the corresponding controls for a scope you have defined. Some simple examples:

  • A component for web applications could list threats like cross-site scripting, malicious file uploads or direct browsing. Typical controls could be a web application firewall, input and output validation, malicious code protection and an effective access control mechanism.
  • A component for your VPN could list threats like denial of service (DoS), eavesdropping or exploitation of software vulnerabilities. The corresponding list of controls would likely include DoS protection, an enforced policy on traffic encryption and vulnerability and patch management.
  • A component for your buildings could list threats like fire, water, failure of the power supply, or unintentional breaches of laws or regulations relevant for offices. Relevant controls could be suitable alarm systems, a USP, and compliance with applicable laws in your jurisdiction.

Since a component is nothing else but a collection of controls and threats for a given scope, you can define components for anything you deem an important part of your risk assessments.

Apart from just listing controls and threats, the component also shows how well the controls can protect you against the listed threats. This is called the control strength. In practice, the controls, threats and control strength values of a component are combined in a matrix:

All numeric values in the matrix are relevant for the calculation of the risk of your IT system in the next steps. A built-in assistant will help you to choose suitable values, if you decide to prepare new components based on your own ideas for controls and threats.

 

Selecting components for your risk assessment

The selection of components entirely depends on the threats and controls you would like to be part of your risk assessment. By choosing a set of components, you can emphasize technical or procedural elements, and you define the level of detail of your assessment. Let’s assume that you want to host the previously used example “ACME corporate website” on AWS. In this case, you could decide to use components for your risk assessment which are based on the following sets of controls:

  • COB.RA – CIS AWS Foundations benchmark – storage
  • COB.RA – CIS AWS Foundations benchmark – logging and monitoring
  • COB.RA – OWASP web application

You might have noticed that two external control frameworks are mentioned, a CIS benchmark and the OWASP. In fact, you can use any control framework to enrich your catalogue of components to exactly meet your needs. One of our customers indeed decided to use CIS benchmarks on the OWASP, and our selection of components for the ACME corporate website would look as follows in their instance of COB.RA:

 

Depending on the control framework(s) you want to rely on, your risk assessment could cover a different scope, for instance:

  • Assuming you are a user of ISO27001, you could use one component for each of the four main areas of ISO27001 (organizational controls, people controls, physical controls, technological controls) to assess your ISMS with COB.RA.
  • If you want to rely on the German BSI Grundschutz, you would have a repository of 104 components (containing 1682 controls) at your disposal.
  • The CIS benchmarks are extremely useful collections of controls, and you could define more or more components for each.

We can support you with the components and we can keep the components up to date for you. However, you would have to ensure that you hold any licenses potentially required for the control framework you choose to rely on.

 

What next?