Requirement engineering calls for continuous possibility to check whether latest changes of significant requirements are met by the target systems. This review is important because the environment of the system, if impacted by changes, may lead to new exposures. Current paper reports on knowledge gained during the attempt to move towards continuous security audit by extending one business process based security requirements identification method with the elements from audit area and the automated business process analysis method for identifying the points for the attention of audit.
Security requirements gain importance for different types of business and public
institutions in the nowadays environment, where practically anything is linked by
certain relations [
Security requirements identification approach that focuses on information flows in business processes was used for information security audit at the business level. Security Requirements Elicitation from Business Processes approach (SREBP) [3], which utilizes 5 security patterns, was chosen as a base approach, because the patterns explicitly focus on particular information flows in the process. However, SREBP approach uses manual pattern identification, which is a complex and time consuming process even for SME. Therefore, we attempted to find a way for searching the patterns of interest in the business process automatically.
The paper is organized as follows. In Section 2 we briefly describe how the SREBP approach was used for auditing purposes. In Section 3 we discuss the method that, to some extent, helps to identify security patterns automatically. In Section 4 brief conclusions are provided. According to Glossary of Terms introduced by Information Systems Audit and Control Association (ISACA) [2], Information Security encompasses protection of information within the boundary of a company against disclosure to unauthorized users, improper modification, and the fact of being unavailable, when required. Hereby the three main information security concepts are indicated: Confidentiality – takes into consideration the aspect of restrictions on disclosure, protection of privacy. Integrity – tackles protection of information against unauthorized changes, also destructive damages to information, preserving non repudiation and authenticity of information. Availability – ensures reliable and timely access to information, in the terms of business continuity.
These three concepts are utilized by SREBP approach that was developed by Naved Ahmed and Raimundas Matulevicius from Institute of Computer Science, Tartu University, Estonia, and afterwards the approach was further elaborated in the international project of Tartu University (Estonia), Riga Technical University (Latvia) and University of Rostock (Germany) [3,4,5]. The approach bridges the needs and knowledge of business process analysts and security engineers by transforming the security objectives into security requirements, whereas attracting security engineering and business analysts, in order to determine and lower down the intentional harm to valuable assets. Therefore, the key issue of the approach is to identify the security criteria and elicit security requirements from a business process model.
SREBP approach deals with limitations of the systematic requirement engineering for addressing security in business processes. Use of the approach encompasses two phases determining five contextual areas for deriving security requirements: access control, communication channel, input interface, network infrastructure, and data store [3,4,5]: Identification of business assets (information assets) and their security objectives Elicitation of security requirements from business process models
The approach focuses on such information security aspects as confidentiality, integrity, and availability, as well as three conceptual groups of security concept (asset related, risk related, and risk treatment related). As a result the following five patterns are utilized [3,4,5]: SPR1 – deals with confidential data by multilevel security approach SRP2 – copes with data transferred between business entities SRP3 – enables data validation methods during input in business process SRP4 – ensures service availability for business assets (information assets) in case of service denial attack SRP5 – tackles data privacy aspects against insiders
The use of SREBP approach prescribes the following activities to be performed regarding the processes: Identify the business assets Identify the key security objectives – confidentiality, integrity, availability Identify SREBP patterns to a definite contextual area Extract SREBP patterns Apply security requirement derivation from security model [3] Assess and analyze risks by identification of risk, risk cause – event, impact, vulnerability, threat, threat agent, and attack method Treat risks and proceed with security requirements – categorize risk treatment, select control, specify security requirement Add security requirements to business process model graphically
The above-mentioned contextual areas are deemed to include the additional information security criteria like identification, authentication, authorization, nonrepudiation, cryptography, auditability.
Based on the information explicated above, the main results that can be expected from SREBP approach are linking business assets to security criteria, then identifying whether certain patterns can be applied, and afterwards proceeding with information security requirements for the certain business activity or several activities within the scope of the definite business process. The approach is more oriented for the use of providing security requirements to the company and as guidelines in the initial phases of information security audit or within the scope of agreed-upon-procedures, therefore not covering the full scope of the information security audit.
For the purposes of identifying requirements from the perspective of Information Security Audit towards SREBP or any other approach that could be used for information security audit of information flows, we considered expedient to base the requirements on one of the most important document that is used in any audit – the Audit Plan [6,7,8,9,10,11,12,13,14].
By analyzing main constituents of the audit plan, we found 37 requirements for information security audit, and grouped them as it is shown in Table 1. The first column of the table reflects the audit requirements, the second column shows the numbers of those requirements that can be met by SREBP approach. The fit ratio regarding number of requirements from information security audit met by SREBP approach was quite low (27%) (last column in Table 2).
We developed the method that, to some extent, can close the indicated gaps derived from requirements of information security audit. The knowledge from OCTAVE Allegro methodology [15], Global Audit Methodology by Big4 Audit Companies [6, 8, 9, 13], Entity Level Control Risk Matrix [16, 17, 18], and Information Demand Patterns [19] were utilized. This knowledge is fused in the main artefact of the designed method (extension for SREB application in information security audit) - Table 3. Table 3 for information security audit of information flows in business processes should be applicable to any activity that is identified within the business process (or sub-process) and involves creation, processing, retaining, transforming, loading, or any other action done to an information asset. The designed Table 3. can be applied to any activity, regardless its type, industry, timing, and executors involved.
The following audit techniques were used for design of Table 3 for purposes of Information Security Audit of Information Flows in Business Processes: visual inspection, observations, analysis of files, technical examination, data analysis, and written questionnaires. Audit Plan Requirement 3.2. Based on business process mapping state whether appropriate controls are designed to cover the risks in the concept of security objectives 3.3. Based on business process mapping check whether appropriate controls are effective to cover the risks in the concept of security objectives 3.4. Define whether additional procedures are required 4. Requirements derived from Conclusion and reporting 4.1. Merge all identified issues 4.2. Compare the indicated issues with risk tolerance 4.3. Prepare suggestions and improvements Identify if any changes occurred after audit 5. Requirements derived from Follow up 5.1. Mark whether the recommendation towards information security are implemented
Thus, based on Table 3, the execution of the designed method involves the following parts (phases) that are placed in a sequence: 1. Mapping the business process (sub-process) using an appropriate notation at the entity and process level. 2. Completing Entity Level Control Risk Preliminary Assessment matrix at the entity and process level [16,17,18]. 3. Applying SREBP approach at the activity level, in terms of business asset (information asset) identification and relating it to security requirement elicitation (for purposes of identifying security criteria), - omitting the security patterns at this stage, because the identification of patterns is better applied after the activities related to definite information assets are processed in Table 3. 4. Proceeding to complete Table 3.
The designed Table 3. starts with identification of General part with the following rationale: 1. Entity level controls preliminary assessment result based on the self-assessment.
The Company can indicate the process that is considered as critical to the Company. The values of Entity Level Control Preliminary Assessment are low, moderate or high, based on the number of assigned points. The identification of the critical process gives substance for selecting the sub-process for deeper analysis. It is advised to select moderate or high risk. 2. Process – the process should be named for the purposes of proper audit documentation.
Fits 4.1. 29% 36% 0% 25%
0 27% 4
Sub-process – the sub process should be named for the purposes of proper audit documentation.
Activity – the activity should be named for the purposes of proper audit documentation.
Table 3 is continued with Data and Information part with the following rationale: 1. Information asset – is identified for the purposes of understanding what should be protected and for the purposes of creating a summary on all further activities that are linked to this information asset, if it is involved in several activities within the scope of a business process or sub process. 2. Information asset owner – is identified for the purposes of creating a summary on all further activities that are linked to this information asset owner, if s/he is involved in several activities within the scope of a business process or sub-process for checking of segregation of duties. 3. Information asset custodian(-s) – is identified for the purposes of creating a summary of all further activities that are linked to this information asset custodian, if s/he is involved in several activities within the scope of a business process or sub-process for checking of segregation of duties. Also, this is used for identification of information demand patterns. 4. Apply assertions/ security criteria – is used as a list, where the related security criteria should be check-marked, in order to understand what kind of security criteria should be applied to this definite information. The basis of selection of the security criteria should be derived from the Information Security policies and procedures that are developed, approved and implemented by the Company. 5. Vulnerabilities related to information asset – are indicated according to the security criteria prescribed to the information asset, the most significant vulnerabilities are marked as potential threats.
Table 3 is continued with Risk Assessment of Information Asset part with the following rationale: 1. What can go wrong – lists the potential threats, that can be transformed into risks and recorded as risks towards the protection of information asset. 2. Risk impact – is assessed as low (insignificant affect), moderate (not significant affect) or high (significant affect) in regards to potential harm that could be done by realization of threats. 3. Risk occurrence – is assessed as low (rarely or never possible), moderate (possible, but not periodic), or high (possible or periodic). 4. Level of risk – is assessed as low, moderate, or high, based on the combination of risk impact and risk occurrence (low impact and low occurrence, low impact and medium occurrence, medium impact and low occurrence results in low level of risk; low impact and high occurrence, medium impact and medium occurrence, high impact and low occurrence result in medium level of risk; medium impact and high occurrence, high impact and medium occurrence, high impact and high occurrence result in high risk level [20]).
Table 3 is continued with Analysis of Significant Risk (non-tolerable) part that deals only with moderate or high level risks with the following rationale: 1. List of recommended controls at place – should determine which controls are at place for the specific information asset. 2. Control effectiveness – should suggest a predefined list of test of controls for specific information asset and evaluate whether the control reaches the security criteria of protection of the information assets. 3. Controls not at place or not effective – should be completed if only controls are not at place or not effective by suggesting a list of recommended substantive procedures and afterwards verify whether there are no indications of the information asset being vulnerable to the risks indicated that are derived from security criteria. 4. Summary of results – indicates key findings. 3. Support for (Semi-) Automatic Identification of Security
Patterns The changes in business processes assume changes application of security measures for information assets. To gain scalability and avoid manual time consuming execution, Table 3. could be partly filled on the basis of security patterns [3]. As manual pattern identification is very time consuming, we tried to automate this process by using the transformation of business process mapped in BPMN to XML format, then comparing XML code of each process to the XML code of known process patterns (see Figure 1).
In this paper we shared our knowledge that we gained by trying to find a way how to establish methods for continuous security requirements engineering. We took as a basis one of security requirement methods SREBP and extended it towards the audit of information assets and towards automatic detection of security patterns. Applicability of both extensions was validated on the procedure descriptions of advanced Latvian middle-sized enterprise. To apply the audit successfully, further IT developments are needed for supporting tools that could give a possibility to save time during the audit procedure. The patterns derivation using XML code is possible, but for two of five patterns expert involvement is still needed.
Acknowledgment: The research presented here is done in part under the grant agreement Nr.10-4/VPP-4/11.