Introducing CRSTIP – Compliance and Risk Security Testing Improvement Profiling
CRSTIP is a scheme that can be used to assess the readiness level of an organization by employing a set of levels within four key areas:
Figure 1- CRSTIP Key Areas and levels
CRSTIP was developed in order to provide a simple, straightforward assessment with regards to the organization’s current positioning together with providing guidelines regarding what is required to further advance its standing. The approach is based on previous work undertaken within the ITEA2 – Diamonds project, where it was used to assess the progress that could be achieved in selected key areas of the security-testing domain. It was further refined within our project in order to serve as a liaison between our project efforts and organizations that would like to improve their standing within key areas addressed within our project. These areas describe major aspects or activities in a security testing process and are chosen in that way that they cover the most relevant innovations within RASEN.
The four levels within each of the key areas provide a straightforward description in order to make it easy for stakeholders to evaluate their own organization. These levels are detailed as follows:
Key Area – Legal and compliance assessment
This 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.
Ad-hoc The compliance assessment is unstructured, does not use a defined compliance process, and compliance decisions are made primarily on an event-driven basis. Check list based The checklist-based compliance assessment uses a checklist to answer a set of standard questions or to tick checkboxes. Systematic 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
Systematic and risk-driven A systematic and risk-driven compliance assessment involves a defined process
for risk-driven compliance where 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
Figure 2 – Levels in Legal and compliance assessment
Key area – Security 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.
Checklist Risk assessment mainly consists of answering a sequence of questions or filling in a form. Qualitative 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. Quantitative Risk assessment based on quantitative values. Values based on some quantity or number, e.g. a measurement, rather than on some quality. Real time Risk assessment in real-time based on underlying, computerized monitoring-infrastructure.
Figure 3 – Levels in Security risk 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 Unstructured security testing is performed either by the development team or the testing team without planning or 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. Planned Planned security testing is performed either by the development team or 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 Risk based 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 using impact estimations or likelihood values to focus the testing process Continuous risk-based 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 resource planning. Any evolution of the system, of its environment or of the identified threats leads to updated security tests so that vulnerabilities can be detected throughout the whole life cycle of the product
Figure 4 – Levels in Security testing
Key Area – Tool support and integration
This area describes the degree of tool support and integration 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 by exchanging data or sharing a common user interface.
None No tool support in none of the above mentioned key areas is available. Stand-alone Tools are available for some of the previously mentioned key areas. However, the tools are not integrated thus they do not exchange data nor do they share the same user interface. Partially integrated 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 as they do not scale. Integrated Tools are available for nearly all the key areas. Tool integration is based on central integration platforms and repositories such as the EMF Store that provide a common set of data to be exchanged together with their respective interfaces. Tool federations better fit 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
Figure 5 – Levels in Tool support and integration
We are currently working to turn this static assessment into an actionable tool on our project website. Any thoughts, suggestion, ideas? – Contact us at firstname.lastname@example.org
1 Sep 2014 / rasen_adm /