Official Representation
of TÜV Austria in Ukraine.

04053, Kyiv, Ukraine
Sichovih Strilciv st, 50, of. 2b
on map
Ph: 380 44 344 9526 Fax: 380 44 344 9526

Developing a Risk Analysis Strategy Framework for Impact Assessment in Information Security Management Systems: A Case Study from the IT Consulting Industry. Part 2

Part One. This article is a free translation of the work of Fotis Kitsios, Elpinica Hatzidimitriou and Maria Kamariotou.

4. Methodology

A strategic framework was developed to support Venus in the development of the SMIB. Figure 1 represents the process used by Venus to implement and evaluate the SMIB. In the first step, the company established a security rule and related measures and controls. It then drafted a scope statement explaining why authorities were preferred over others. The company identified assets and requirements, assessed risks, and chose a method of evaluation. In the second step, the company implemented security policies and procedures, implemented controls, and managed operations. In the third phase of the process, the company evaluated and measured performance and reported the results to management. In the last phase, the company took appropriate preventive, predictive, and improvement actions to maintain and improve the media security.

Figure 1: The ISMS process

Risk is the negative impact of any vulnerability and threat that may arise in Venus information systems and assets. Risk management is the systematic identification, assessment, and implementation of steps and actions to reduce risks to an acceptable level. In the next few paragraphs, we define and evaluate a methodology for assessing and processing information risks to determine an adequate level of risk in accordance with relevant security standards (ISO/IEC 27001: 2013), and provide guidance for developing effective risk management. program within the Venus infrastructure.

Risk assessment, risk handling, and supporting controls and processes are applied to all Venus premises for all information and operational risks for all assets that may be used internally and may affect information security. Controls and processes apply to all information security risk assessments conducted within Venus Media Security, including all company business processes and assets. Risk assessment and processing policies apply to all Venus business entities (e.g., employees, partners, contractors, local delivery partners, suppliers, members of the public).

Risk management is a process within the company’s media security structure designed to systematically identify, assess and handle risks, and to ensure an acceptable level of information security within the media security framework. The objectives of risk assessment and risk processing in the context of information security are: developing a clear assignment of responsibilities, developing consistent methods to identify risks, identifying risks, clearly documenting risks with risk assessment, implementing more effective security measures in Venus information systems; better risk assessment solutions; providing information for cost-effective security measures; developing physical, procedural and technical rules agreed upon with information asset owners;

Venus established the business and technical basis for the information system being evaluated and made sure that the business objectives were covered by all internal and external aspects that controlled the recognized risks. Regarding the business context, the identification of the business owner of the information system, including information classification, supported business processes, system users, security and compliance requirements was considered. Regarding the technical context, the identification of Venus as the information system service owner was reviewed, as was the ability of Venus users to support and maintain the information system, logical architecture, and system components.

The risk assessment examined the importance of Venus’ information systems and assets. For that particular information asset, a comprehensive risk assessment was conducted if its objectives were vital to Venus’ business objectives or if the assets were determined to be high risk. This included in-depth documentation and verification of the assets, which provided a business impact assessment of vulnerabilities and risks to those assets.

The risk assessment identified, quantified and prioritized risks in line with Venus’ objectives and established criteria for an acceptable level of risk. The results of the risk assessment helped company management select appropriate actions and appropriate prioritization to administer information security risks and implement appropriate controls to protect against those risks.

The risk assessment procedure included a systematic assessment of the risk scale (risk analysis) and a method of mapping risk to risk conditions to determine the importance of risks (risk assessment). An occasional risk assessment was conducted to account for changes in security prerequisites and risk conditions (e.g., assets, threats, susceptibility, consequences, and other significant changes). It was conducted systematically and could produce similar and repeatable results several times depending on the part and criticality of the Venus or the information systems under study.

The risk assessment should be conducted with access and understanding of the business processes associated with the risk of impact on business assets, the technical systems in place to support business needs, legislation and regulations to which the company is subject, etc. current vulnerability and threat assessments. A risk assessment should be conducted at least for each new information processing system, after the introduction of a new information asset and after modifications to systems or processes. Modifications that may change the nature of threats and vulnerabilities may be required if the review has not been conducted for a relatively long period (e.g., three years).

For each of the risks identified after the risk assessment, management had to decide on the appropriate risk treatment method. Possible risk-handling options included implementing appropriate controls to mitigate risks, accepting risks while meeting the conditions and criteria for accepting risks, avoiding risks by avoiding actions that could cause threats, and transferring related risks to other parties (such as insurers or suppliers).

The risk decision with appropriate controls included the selection and implementation of controls as required by the risk assessment. The controls selected must ensure that risks are minimized, taking into account the conditions and limitations of national and international law and policies, contractual obligations with customers and suppliers, business requirements and objectives as described above, operational needs. and regulations, the costs of applying and operating the controls to risks that are mitigated and the remaining risks, depending on the conditions and limitations of Venus, the importance of balancing investments in the execution and operation of cp The identification of all assets was the initial step in the ISMS risk assessment process (impact of assets on confidentiality, integrity, availability of company information). Assets included documents in physical or electronic form, applications and databases, IT equipment, infrastructure, people, and external and outsourced services. In addition, asset identification consisted of the owners of each asset (responsible personnel, organizational unit). The identification of vulnerabilities and threats for each asset was the next step in the risk management methodology. Several vulnerabilities and threats could be associated with each asset.

5. Results

5.1 Risk Assessment Process

Venus considered all potential system-specific vulnerabilities and risks, whether internal or external, natural or human, accidental or intentional. Information on vulnerabilities and threats was obtained from relevant Venus users and, in some cases, professional security consultants, local and national law enforcement, security facilities, and contacts. Table 1 shows the threat categories identified for Venus.

TheftTheft, Vandalism
Software bugSoftware bug
Software bugMalware
Software errorUnauthorized access
DisconnectPower outage
DisconnectDisconnection of communication
Network errornetwork attack
Natural disasterearthquake
Natural disasterFlooding
Natural disasterFire
LegalBreach of contractual relationship
LegalBreach of law
Human errormisuse of information
Human errorOperator error
Human errorabuse of privileges of the user
Human errorDestruction of records
Human errorHardware error
Hardware errorcable damage
Access errorLocked
Software errorService error
Hardware errorequipment malfunction
Human errorunauthorized installation of software
Device disposalnon-hazardous media removal
Hardware reuseUnsafe reassignment of the equipment
Removable mediaUse of unencrypted removable media

Table 1. Threat categories defined for Venus.

Risks associated with Venus’ information systems, information and operations can be classified into the following categories; any user can identify threats relevant to the assets under investigation. A comprehensive list of events that could prevent or delay the achievement of Venus’ business objectives has been documented. Risks not included in this list may not be assessed and mitigated. Threats from existing repositories can be added after appropriate searches. A clear description of the risks was implemented for review and evaluation. Finally, risk identification included potential impacts to information systems and assets. Any potential risk that could affect the confidentiality, integrity, and availability of information systems, information, operations, and assets was documented in the risk assessment process. Risk assessment criteria were established to provide a common understanding of these security measures that minimized the potential impact to an acceptable level. The level of damage and the value caused by the threat defined the exposure criteria. Table 2 presents the impact criteria that were identified.

Impact criteria

Loss of financial valueEffects on correlated procedures
Direct financial consequencessecurity incidents, attacks
Indirect, long term financial consequencesViolation of legal, regulatory requirements
Failure of plans and deadlinesPrivate agreement issues
Obstruction of corporate proceduresPrivacy issues
Loss of business valuecompetition issues
Loss of opportunityConfidential and personal data damage the reputation
Business disruptionsPublic privacy issues

Table 2. Impact Criteria.

To determine the likelihood of future events and risks that could potentially harm Venus’ information systems and assets, an analysis was conducted with identified vulnerabilities and security measures. The impact of loss of confidentiality, integrity, and availability was evaluated according to the impact criteria. Probability of occurrence was a risk factor based on an analysis of the likelihood that a particular threat could exploit a particular (or set of) vulnerabilities. Risk is the result of the probability of a specific threat from a potential vulnerability and the subsequent impact (likelihood) on Venus information systems and assets.

The steps that led to the implementation of the risk assessment included the following activities: threat identification, vulnerability identification, control analysis, probability determination, impact analysis, risk determination, control recommendations, and results from documentation. The first exercise assessed the probability of a potential threat occurring. The threat probability (threat level) was described as the likely occurrence of an event. In establishing the probability of threat, Venus had to consider the reasons for the threat, the possible susceptibility, and the controls in place. In the second exercise, threat analysis of the information system included a vulnerability analysis of the Venus environment-an assessment of vulnerability levels for the threat scenario. Application controls were tested. Next, the implemented controls were reviewed and they attempted to minimize or eliminate the likelihood of a threat that could arise from a system vulnerability. During the fourth action, Venus considered the following significant factors: the impact of the (natural) threat source, and the availability and effectiveness of the current controls. The probability of a threat occurring was entered, and the outputs of the event probability for a particular threat were the threat level and the susceptibility level. In the fifth exercise, the impact of a security event was described in terms of loss of confidentiality, integrity, and availability. The probability of occurrence and impact values were then combined to estimate each asset’s risk level for the identified threat. The adequacy of the company’s planned and existing security measures was also included to assess the level of risk. During the seventh action, security measures that could mitigate and address the identified risks were aligned with operations. The recommended controls were to ensure that the level of risk was maintained at a manageable level. Finally, after the risk assessment was completed, the results were documented in a formal report. Risk levels were assessed against established criteria and appropriate actions were taken. the results were documented in a formal report. The risk levels have been assessed against the established criteria and appropriate measures have been taken. the results have been documented in the official report. Risk levels have been assessed against established criteria and appropriate actions have been taken. Figure 2 shows a flow chart of the actions performed during the risk assessment process.

In the case of risk, it was necessary to assess the corresponding consequences for each vulnerability and threat separately for an individual asset. The probability of that risk had to be estimated for each of the Venus assets. The severity of the risk was an overall estimate of both how likely it was to occur (probability) and the impact it would have if it did occur (impact). The potential vulnerability and/or threat was described as (near certain, probable, possible, unlikely, rare). The impact of a security incident was defined in terms of loss of confidentiality, integrity, and availability. Quantification of impact was based on NIST SP 800-30, Revision 1. The risk level was based on NIST SP 800-30, revision 1. Table 3 shows the probability and frequency levels, and Table 4 shows the exposure levels.

Level of ProbabilityProbability Description
Almost certainMore cases are expected
ProbableLikely to happen most of the time
PossibleCould happen someday
UnlikelyNot expected, but conceivable, could happen someday
RareNot expected and may only happen under certain circumstances

Table 3: Probability probability and frequency levels.
Level of impactDescription of impact
High(H5,H4,H3,H2,H1)Loss of availability, confidentiality or integrity has a significant, critical and/or immediate impact on the company’s cash flow, operations, functionality, legal, contractual obligations and/or its reputation.
Medium(M5,M4,M3,M2,M1)Loss of availability, confidentiality, or integrity could result in costs and have medium to negligible impact on legal, contractual obligations and/or its reputation.
Low (L5,L4,L3,L2,L1)Loss of availability, confidentiality, or integrity has no impact on the company’s cash flow, legal, contractual obligations, and/or reputation.

Table 4: Exposure Levels.

The company has developed a risk scale and risk level matrix to measure the recognized risk. The final measurement of risk is obtained by multiplying the rating assigned to the probability of the threat and the effect of the threat. Full risk ratings can be established based on inputs from the threat probability and threat effect groups. The risk level matrix (Table 5) is a 5 × 15 matrix of threat probability (near certain, probable, possible, unlikely, rare) and threat impact (high 1-5, medium 1-5, low 1-5) and shows how overall risk levels are determined. The determination of these levels of risk or estimates can be subjective. The basis for this explanation can be expressed in terms of the probability assigned to each threat probability level and the value assigned to each exposure level. For each Venus asset, all possible threats have been assigned.

Table 5:
Risk Level Matrix.

The scale for assessing exposure levels (in terms of confidentiality, integrity, and availability) was established as a 15-point rating scale from L1 to H5: L1, L2, L3, L4, L5, M1, M2, M3, M4, M5., H1, H2, H3, H4, H5. These criteria are based on ISO 27005. The rating scale for probability levels is set as a 5-point rating scale: 0.20 – rare, 0.40 – unlikely, 0.60 – possible, 0.80 – probable, 1.00 – almost certain. The risk limit is set at 2.9.Table 5 presents a matrix of risk levels. The matrix of risk levels with its ratings represents the level of risk to which an information system, asset, and/or Venus process may be exposed with known susceptibility and threat. Table 6 shows the consequences, and Table 7 presents the levels of consequences.

Table 6: Probability
– Consequences

Table 7.
Levels of consequences.

5.2 Risk Treatment Plan.

An answer must be defined for each risk identified. The probability and impact of the risk are the basis for recommendations on what actions should be taken to reduce the risk. The treatment option (safety measures) must be determined according to a cost-benefit analysis and appropriate impact criteria. The risk treatment consisted of the following four levels: acceptance, reduction, transfer, and removal. At the first level, risk acceptance was reserved for low-priority risks where other treatment options would cost more than the potential impact. To reduce the identified risk, all risks must include a recommendation for controls and alternative solutions. Venus would accept the identified risk. At the second level, risk mitigation involved minimizing the likelihood and/or consequences of risk threats and vulnerabilities. Proactive measures against risk are always more effective than repairing the damage caused by an identified risk. The company will plan and develop future controls to address the identified risk. At the third level, risk transfer entails transferring the negative effect of the threat or vulnerability. Transferring the risk to a third party (suppliers) does not eliminate the threat or vulnerability. The other party will be responsible for handling the associated risk. Venus will list all options for transferring identified risks to other entities (e.g., insurance providers). At the last level, risk prevention involved changing aspects of the overall business processes or system architecture to eliminate the threat – preventing the risk by terminating the associated business activity. Venus would plan and develop future controls to address the identified risk.

Appropriate control objectives were selected to mitigate identified risks and minimize potential impacts to Venus’ information systems. Security controls have been selected and/or developed in accordance with the rules from the ISO/IEC 27001:2013 Annex to ensure that none are missed. The rules selected for the relevant threats were documented.

A risk treatment plan was developed to manage and mitigate necessary corrective actions. The Risk Handling Plan was developed to mitigate risks to Venus’ critical assets. Any potential risk that may have arisen from identified vulnerabilities and threats was addressed according to the level of impact.

6. Discussion

Following the risk assessment, 309 unique threats were identified. At the end of the risk assessment, a total of 309 sets of controls were applied (one set for each threat: a threat may require more than one control to mitigate the identified risks and minimize the potential impact on Venus information systems). A total of 269 risks were reduced to acceptable levels by applying a set of controls to each threat. A total of 198 threats were reduced to an acceptable level by applying controls already in place prior to risk assessment, and 71 threats needed further treatment by applying new controls or updating existing controls. For 45 of the 71, we had to do a third round of control implementation because the second round was not sufficient. The CEO accepted 32 risks as we were unable to apply, 5 risks were transferred,

There were various obstacles in the implementation. The company had to assign the task of implementing the SMIB to its resources. The resources had to manage and implement the media security, and they had to be qualified employees with an in-depth knowledge of the company’s structure and operations. The role of Chief Information Security Officer (CISO) was assigned to the Director of Development and the role of ISM was assigned to the Operations Manager. The problem was that these two resources already had assigned tasks, so a whole new restructuring had to be done, hiring new people to support the remaining functions. This added additional costs to the company.

As mentioned above, Venus is a project company. Consultants and developers join or leave depending on the needs of the team. It should be noted that an infrastructure is set up for each project, including a code repository, a document library, a directory in the project management tool, mailing lists, containers for development and testing, a problem tracker, and input to the time-management tool.

When the company began implementing changes to protect the information and provide access only to project members, there was a significant level of complexity each time a resource needed to join or leave the team. The process was time-consuming and left room for error. To solve this problem, the company commissioned a dedicated development team to create a new product that automated all the steps involved in access management. This added an additional cost to the company.

A successful implementation of ISO 27001 requires the full support and input of the employees. There were several challenges in implementing ISO 27001. These challenges had to be addressed to gain the trust and goodwill of the employees and to ensure the effectiveness of the SMIB. In particular, employees felt that they had stepped outside their comfort zone because they felt that their work was being examined under a microscope. They were concerned about the time and effort it would take to comply with all the policies and procedures associated with the SMIB. Employees were also unhappy with the time frame for reviewing the relevant documentation for these new policies and procedures. Employees felt the implementation of ISO 27001 was unnecessary and typical because only a small number of people were involved from the beginning.

As mentioned above, the circle of ISO implementation was not closed because the internal audit had not yet taken place. We strongly believe that it would be interesting to get an update on how this journey to ISO 27001 ends. What will the results of the audit be? Will there be nonconformances? Non-conformances are considered non-compliance with specific requirements, failure to prevent loss, failure to follow a process, and failure to successfully confront a security incident. What will the company’s response be?

The risk assessment and risk handling took more than 11 months and had to be completed in 16 versions. This added complexity and delays to the company’s processes, and the audit was delayed. In addition, pointing to ISO 27001 compliance, the process is a constant source of change within the organization; thus, it affects the company’s change management. Future studies may encounter all the difficulties and complexities of this particular segment of the company’s life.

7. Conclusions

The purpose of this document was to develop a risk assessment framework that a company could follow in the information technology sector to conduct a risk assessment process in accordance with ISO 27001. This document analyzed how an ISO 27001 certified company has established methods to prevent such incidents in order to be able to assess information security risks and deal with any threats or vulnerabilities, as well as ensure complete and consistent documentation and continuous updates.

One of the most important and time-consuming parts of setting up a company’s media security is the risk assessment – all possible risks must be identified, assessed and classified. Risks differ from other companies, but the desired outcome is to secure information and find the best solution to meet the company’s needs. The company already had many processes in place. However, most of them were not recorded regularly or not recorded at all. In other words, many threats were not identified and therefore not accounted for.

In addition, the company’s rapid growth showed that a standardized information security model could make some aspects of the business more functional. Moreover, it became clear that rapid growth would make the company a target for cyber threats. This became a goal for the company to embark on a more detailed and expanded information security policy. The traditional way of ensuring information security was not sustainable in a fast-growing company. Risks associated with human error increased as the company’s workforce grew. Finally, the company kept getting the same question from numerous customers: “Why should we trust our information with you?” Over the years, it became increasingly difficult to come back to customers with well-documented evidence. Moreover, customers became less tolerant of information security uncertainty, and the information security team was no longer able to respond to customer needs. Thus, this article was the culmination of a long road to implementing ISO 27001 in the company. However, the risk assessment process is not static and will need to be repeated.

The practical contribution of this article is that it provides practitioners with a framework for implementing the risk assessment process in the information technology sector. Companies in the information technology sector are fully dedicated to being productive and solving day-to-day survival problems. They often can’t and don’t want to spend the time and effort to define new processes or improve existing ones. Software engineers are more focused on products, services, or management than on creating new ways of working.

Another contribution of this document is that the implementation of ISO 27001 will, in the medium term, affect the day-to-day operations of the business, resulting in less workload and duplication of effort, as well as streamlining tasks. related to implementing and maintaining recommended best practices will help their implementation. Not only do companies need to know what to do to improve their processes, but they also need to have specific procedures detailing the work they need to do, with a clear set of best practices to help execute them. These procedures should be simple and applicable to the types of projects they typically do.

A limitation of this article is that the risk assessment and processing took over 11 months and 16 versions to complete. As a result, future researchers will be able to estimate the exposure levels and probabilities of each asset for each threat. When the risk level exceeds the risk limit, the company will test all controls in place. A new risk level check will be performed, and risk treatment actions will be evaluated based on the new risk level. For each risk identified, the treatment option should be documented.

In addition, future researchers can gather more information items for Figure 2 by conducting literature reviews and discussing them with information security risk specialists. Some information objects based on ISO 27005 may not be available in this article. Risk descriptions can help companies develop an assessment of the likelihood and impact of risks on media security. In addition, other tools can be used to extend a company’s threats and vulnerabilities to the media security environment. However, this document can be seen as a starting point for people who are involved in the media security assessment and decision-making process in the organization.

Another limitation is that it includes only one case study; selecting examples from a variety of industries could have provided more solid support for identifying specific recommendations in the SMIB. The lessons learned from its application by a large number of software companies will provide valuable guidance for practitioners in the information technology sector.