Compositional Risk Assessment

and Security Testing of Networked Systems

Key area - Legal and compliance assessment

Legal and compliance assessment refers to the overall process employed with the objective of adhering to the requirements of laws, industry and organizational standards and codes, principles of good governance and accepted community and ethical standards.  The overall process should support, to the extent possible, the documentation of compliance.

The compliance assessment is unstructured, does not use a defined compliance process, and compliance decisions are made primarily on an event-driven basis.Level 1 - Ad-hoc compliance assessment

The checklist-based compliance assessment uses a checklist to answer a set of standard questions or to tick checkboxes.Level 2 - Check list based compliance assessment

A systematic compliance assessment follows a structured and planned approach where there is a defined process and structured documentation of compliance. Generally, the process involves the identification of compliance requirements, evaluation of the compliance issues and taking measures to ensure compliance.Level 3 - Systematic compliance assessment

A systematic and risk-driven compliance assessment involves a defined process for risk-driven compliance where compliance requirements are prioritized based on their risks. This approach is supported by a systematic documentation that enables the mapping of different risks and controls to relevant compliance requirements.Level 4 - Systematic and risk-driven

Key area - Risk assessment

Risk assessment is the overall process of risk identification, risk estimation and risk evaluation. Risk identification is the process of finding, recognizing and describing risks. This involves identifying sources of risk, areas of impacts, events (including changes in circumstances), their causes and their potential consequences. Risk identification can involve historical data, theoretical analysis, informed and expert opinions, and stakeholders’ needs. Risk estimation is the process of comprehending the nature of risk and determining the level of risk. This involves developing an understanding of the risk. Risk estimation provides the basis for risk evaluation and decisions on whether risks need to be treated, and on the most appropriate risk treatment strategies and methods. Risk evaluation is the process of comparing the results of risk estimation with risk criteria to determine whether the risk and/or its magnitude is acceptable or tolerable. Risk evaluation assists in the decision about risk treatment.

Risk assessment mainly consisting in answering a sequence of questions or filling in a form.Level 1 - Checklist Assessment

Risk assessment based on qualitative risk values. Value descriptions or distinctions based on some quality or characteristic rather than on some quantity or measured value.Level 2 - Qualitative Assessment

Risk assessment based on quantitative values. Values based on some quantity or number, e.g. a measurement, rather than on some quality.Level 3 - Quantitative assessment

Risk assessment in real-time based on underlying, computerized monitoring-infrastructure.Level 4 - Real time assessment

Key area - Security testing

Security testing is used to experimentally check software implementations with respect to their security properties and their resistance to attacks. For security testing we can distinguish functional security testing and security vulnerability testing. Functional security testing checks if the software security functions are implemented correctly and consistent with the security functional requirements. It is used to check the functionality, efficiency and availability of the specified security features of a test item. Security vulnerability testing directly addresses the identification and discovery of yet undiscovered system vulnerabilities. This kind of security testing targets the identification of design and implementation faults that lead to vulnerabilities that may harm the availability, confidentiality and integrity of the test item.

Unstructured security testing is performed, either by the development team or by the testing team, without planning and documentation. The tests are intended to be run only once, unless a defect is discovered. The testing is neither systematic nor planned. Defects found using this method may be harder to reproduce.Level 1 - Unstructured testing

Planned security testing is performed, either by the development team or by the testing team, after a structured test plan has been elaborated. A test plan documents the scope, approach, and resources that will be used for testing.Level 2 - Planned testing

Security tests are planned and executed, either by the development team or by the testing team and planning of security testing is done on the basis of the security risk assessment (i.e impact estimations or likelihood values are used to focus the security testing and optimize the resource planning).Level 3 - Risk based testing

Continuous risk based security testing is a process of continuously monitoring and testing a system with respect to potential vulnerabilities. Security risk analysis results are still used to focus the security testing and optimize the resource planning. Any evolution of the system, of the environment of the system or of the identified threats, leads to update the security testing so that vulnerabilities could be detected throughout the whole life cycle of the software product.Level 4 - Continuous risk-based testing

Tool support and Integration

Tool support and integration specifies the degree of tool support that is available for the above mentioned key areas.  Typically, tools work on their own data structures that are well suited to the task, which needs to be performed with or by the tool.  Tool integration is the ability of tools to cooperate with other tools by exchanging data or sharing a common user interface.

No tool support in none of the above mentioned key areas is available.Level 1 - None

Tools are available for some of the above mentioned key areas. However, the tools are not integrated thus, they do not exchange data with other tools nor do they share the same user interface.Level 2 - Stand-alone

Tools are available for some of the above mentioned key areas. Tool integration is based on point-to-point coalitions between tools. Point-to-point coalitions are often used in small and ad-hoc environments but have problems when it comes to more tools and larger environments (no scalability).Level 3 - Partially integrated

Tools are available for nearly all of the above mentioned key areas. Tool integration is based on central integration platforms and repositories (e.g. EMF store, Model Bus?, Jazz etc.) that provides a common set of data to be exchanged and respective interfaces. Tool federations better fit to larger tool environments because the existence of a common set of interfaces eases the integration of new tools. However, the definition of a common data set and common interfaces is more complex as defining bilateral point-to-point coalitions.Level 4 - Integrated

In which of the following areas would improvements benefit your organization most ?

Please fill in your Company's Name and the email address where you wish to receive the results. We will not share your information in any identifiable way with anyone.