Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Jump to content

IT risk management

From Wikipedia, the free encyclopedia

Risk management elements

IT risk management is the application of risk management methods to information technology in order to manage IT risk. Various methodologies exist to manage IT risks, each involving specific processes and steps.[1]

An IT risk management system (ITRMS) is a component of a broader enterprise risk management (ERM) system.[2] ITRMS are also integrated into broader information security management systems (ISMS). The continuous update and maintenance of an ISMS is in turn part of an organisation's systematic approach for identifying, assessing, and managing information security risks.[3]

Definitions

[edit]

The Certified Information Systems Auditor Review Manual 2006 by ISACA provides this definition of risk management: "Risk management is the process of identifying vulnerabilities and threats to the information resources used by an organization in achieving business objectives, and deciding what countermeasures, if any, to take in reducing risk to an acceptable level, based on the value of the information resource to the organization."[4]

According to the NIST, "Risk management allows IT managers to balance the operational and economic costs of protective measures with mission goals by securing IT systems and data."[5]

Relationships between IT security entity

The American National Information Assurance Training and Education Center defines risk management in the IT field as:[6]

  1. The total process to identify, control, and minimize the impact of uncertain events. The objective of the risk management program is to reduce risk and obtain and maintain DAA approval. The process facilitates the management of security risks by each level of management throughout the system life cycle. The approval process consists of three elements: risk analysis, certification, and approval.
  2. An element of managerial science concerned with the identification, measurement, control, and minimization of uncertain events. An effective risk management program encompasses the following four phases:
    1. Risk assessment, as derived from an evaluation of threats and vulnerabilities.
    2. Management decision.
    3. Control implementation.
    4. Effectiveness review.
  3. The total process of identifying, measuring, and minimizing uncertain events affecting AIS resources. It includes risk analysis, cost benefit analysis, safeguard selection, security test and evaluation, safeguard implementation, and systems review.
  4. The total process of identifying, controlling, and eliminating or minimizing uncertain events that may affect system resources. lt includes risk analysis, cost benefit analysis, selection, implementation and test, security evaluation of safeguards, and overall security review.

Methodology

[edit]

While specific methods may vary, risk management processes generally include establishing context, conducting risk assessments, and managing risks. Risk management methodologies from standards such as ISO/IEC 27005, BS 7799, NIST SP 800-39, and Risk IT emphasize a structured approach to these processes.[1] The following table compares key processes across leading frameworks:

ENISA: The Risk Management Process, according to ISO Standard 13335
Risk management constituent processes
ISO/IEC 27005:2008 BS 7799-3:2006 NIST SP 800-39 Risk IT
Context establishment Organizational context Frame RG and RE Domains, including IT risk tolerance and risk practices
Risk assessment Risk assessment Assess Processes for risk analysis and evaluation
Risk treatment Risk treatment Respond Selection of risk response options and treatment plans
Risk acceptance Not specified Not specified RG3.4 Accept IT risk
Risk monitoring Ongoing management activities Monitor Independent assurance of IT risk management

Context establishment

[edit]

The first step in the ISO/IEC 27005 framework is context establishment. This step involves gathering relevant information about the organization and defining the criteria, scope, and boundaries of the risk management activities. This includes complying with legal requirements, ensuring due diligence, and supporting the establishment of an information security management system (ISMS). The scope can encompass incident reporting plans, business continuity plans, or product certifications.

The key criteria include risk evaluation, risk acceptance, and impact assessment, influenced by:[7]

  • Legal and regulatory requirements
  • The strategic value of information processes for the business
  • Stakeholder expectations
  • Negative consequences for the organization's reputation

Establishing the organization’s mission, values, structure, strategy, locations, and cultural environment is crucial, along with documenting constraints such as budgetary, cultural, political, and technical factors that will guide the risk management process.

Risk assessment

[edit]
ENISA: Risk assessment inside risk management

Risk assessment, a critical component of IT risk management, is performed at specific points in time (e.g., annually or on-demand) and provides a snapshot of assessed risks. It forms the foundation for ongoing risk management, which includes analysis, planning, implementation, control, and monitoring of security measures.

Risk assessments may be iterative, beginning with high-level evaluations to identify major risks, followed by more detailed analysis in subsequent iterations. The following steps are typically involved:[6]

  1. Risk identification – Recognizing potential loss sources such as assets, threats, vulnerabilities, and business processes.
  2. Risk estimation – Evaluating the likelihood and impact of identified risks, often using either quantitative or qualitative methods.
  3. Risk evaluation – Comparing risk levels to predefined acceptance criteria and prioritizing risks for treatment.

The ISO 27005 framework divides the process into the following stages:[7]

Risk assessment constituent processes
ISO 27005 Risk IT
Risk analysis RE2 Analyse risk, including risk scenario development and peer review
Risk identification Included in RE2.2 Estimate IT risk
Risk estimation RE2.2 Estimate IT risk
Risk evaluation RE2.2 Estimate IT risk

Risk identification

[edit]

This process identifies the assets (both primary and supporting), threats, and vulnerabilities that may affect the organization. Additionally, it involves identifying business processes and existing or planned security measures. The result of this step is a list of risks, threats, and potential consequences related to the assets and business processes.[7]

OWASP: relationship between threat agent and business impact

Risk estimation

[edit]

Risk estimation assesses the likelihood and consequences of the identified risks. Two common approaches are:

  • Quantitative risk assessment – A mathematical calculation based on security metrics, such as Single loss expectancy (SLE) and Annualized Loss Expectancy (ALE).
  • Qualitative risk assessment – Descriptive methods, such as interviews and expert judgment, which are faster and less data-intensive but less precise.[8]

For both methods, risk values are calculated for each asset and the output is documented in a risk register.

Risk evaluation

[edit]

In this step, the results from the risk analysis are compared against the organization's risk acceptance criteria. The risk list is prioritized, and recommendations are made for risk treatment. Risks that are too costly to mitigate may be accepted or transferred (e.g., through insurance).

Risk assessment according NIST SP 800-30 Figure 3-1

Risk mitigation

[edit]

Risk mitigation involves prioritizing and implementing risk-reducing measures recommended during risk assessment. Since eliminating all risk is impractical, organizations must apply the most cost-effective controls to reduce risk to an acceptable level while minimizing the impact on other operations.

The following strategies are typically considered:[5]

  • Risk assumption – Accepting the potential risk and continuing operations.
  • Risk avoidance – Eliminating the risk by avoiding risk-prone activities.
  • Risk limitation – Implementing controls to minimize the impact of risks.
  • Risk transference – Using other options, such as purchasing insurance, to transfer the risk.

Residual risks, those remaining after treatment, are estimated to ensure adequate protection, and further measures may be taken if necessary.

Risk communication

[edit]

Risk communication is a continuous, bidirectional process that ensures a common understanding of risk among all stakeholders. Effective communication influences decision-making and promotes a culture of risk awareness across the organization. One method to achieve this is the Risk Reduction Overview method,[9] which presents risks, measures, and residual risks in a comprehensible manner.

Risk monitoring and review

[edit]

Risk management is an ongoing process that requires regular monitoring and review to ensure that implemented security measures remain effective as business conditions, threats, and vulnerabilities change. Regular security audits and reviews are essential to validate security controls and assess residual risks.[1]

New vulnerabilities, such as zero-day attacks, must be addressed through continuous monitoring, patch management, and updating of controls. Benchmarking against best practices and engaging in professional development activities are important for maintaining state-of-the-art risk management practices.

IT evaluation and assessment

[edit]

To ensure the effectiveness of security measures, controls should be continuously tested and validated, including both technical systems and procedural controls. Penetration tests and vulnerability assessments are common methods for verifying the effectiveness of security controls. Regular reviews and reauthorization of systems are necessary when significant changes are made.[5]

Risk management should also be integrated into the Systems Development Life Cycle (SDLC) to ensure that risks are addressed throughout the life cycle of IT systems. Each phase of the SDLC benefits from specific risk management activities, from initial planning to system disposal.[10]

Integration into the system development life cycle

[edit]

Effective risk management is fully integrated into the Systems Development Life Cycle (SDLC). The SDLC typically involves five phases: initiation, development or acquisition, implementation, operation or maintenance, and disposal. Risk management activities remain consistent throughout these phases, ensuring that potential risks are identified, assessed, and mitigated during each stage.[11]

Integration of Risk Management into the SDLC
SDLC Phase Phase Characteristics Risk Management Activities
Initiation Defines the need for an IT system and its scope Identified risks support the development of system requirements, including security needs and concept of operations.
Development or Acquisition System design, purchase, or construction Risk assessments help guide security decisions during the system's development, influencing architecture and design trade-offs.
Implementation System is configured, tested, and verified Risk management ensures that security requirements are met and assessed before system operations begin.
Operation or Maintenance The system is operational and updated Continuous risk assessments are performed whenever significant changes occur or at regular intervals for reauthorization.
Disposal The system is decommissioned Risks are managed to ensure secure disposal, including data sanitization and system migration where necessary.

Security in the SDLC

[edit]

Incorporating security into the SDLC is essential to prevent costly vulnerabilities from emerging later in the system’s life. Early integration of security measures during the initiation and development phases can significantly reduce the cost of mitigating security vulnerabilities. It also enables the reuse of established security strategies and tools, resulting in improved security and cost efficiency.[12]

The following security considerations are integrated into the SDLC:

  • Security requirements for information systems: Security needs are incorporated into the system's design from the start.
  • Correct processing in applications: Protecting against errors and ensuring the integrity of data.
  • Cryptographic controls: Ensuring that data is encrypted both at rest and in transit to prevent unauthorized access.
  • Security of system files: Implementing version control, access restrictions, and thorough testing of system files.
  • Technical vulnerability management: Monitoring for vulnerabilities and applying timely patches to protect against emerging threats.

By incorporating these practices, organizations can ensure that their IT systems are secure from the outset, reducing the likelihood of vulnerabilities and costly security incidents later in the system's life cycle.

Critique of risk management as a methodology

[edit]

Risk management as a methodology has been criticized for its subjectivity, particularly in assessing the value of assets and the likelihood and impact of threats. The probabilistic models often used may oversimplify complex risks. Despite these criticisms, risk management remains an essential tool for managing IT risks.[1]

Risk management methods

[edit]

Various methods support the IT risk management process. Some of the most widely used include:[1]

Standards

[edit]

Various standards provide guidance for IT risk management, including ISO/IEC 27000-series and NIST SP 800-30.

See also

[edit]

References

[edit]
  1. ^ a b c d e Katsicas, Sokratis K. (2009). "35". In Vacca, John (ed.). Computer and Information Security Handbook. Morgan Kaufmann Publications. Elsevier Inc. p. 605. ISBN 978-0-12-374354-1.
  2. ^ "ISACA THE RISK IT FRAMEWORK (registration required)" (PDF). Archived from the original (PDF) on 2010-07-05. Retrieved 2010-12-14.
  3. ^ Enisa Risk management, Risk assessment inventory, page 46
  4. ^ ISACA (2006). CISA Review Manual 2006. Information Systems Audit and Control Association. p. 85. ISBN 978-1-933284-15-6.
  5. ^ a b c Feringa, Alexis; Goguen, Alice; Stoneburner, Gary (1 July 2002). "Risk Management Guide for Information Technology Systems". doi:10.6028/NIST.SP.800-30 – via csrc.nist.gov. {{cite journal}}: Cite journal requires |journal= (help)
  6. ^ a b "Glossary of Terms". www.niatec.iri.isu.edu.
  7. ^ a b c ISO/IEC, "Information technology -- Security techniques-Information security risk management" ISO/IEC FIDIS 27005:2008
  8. ^ Official (ISC)2 Guide to CISSP CBK. Risk Management: Auerbach Publications. 2007. p. 1065.
  9. ^ "Risk Reduction Overview". rro.sourceforge.net.
  10. ^ Gulick, Jessica; Fahlsing, Jim; Rossman, Hart; Scholl, Matthew; Stine, Kevin; Kissel, Richard (16 October 2008). "Security Considerations in the System Development Life Cycle". doi:10.6028/NIST.SP.800-64r2 – via csrc.nist.gov. {{cite journal}}: Cite journal requires |journal= (help)
  11. ^ Feringa, Alexis; Goguen, Alice; Stoneburner, Gary (1 July 2002). "Risk Management Guide for Information Technology Systems". NIST. doi:10.6028/NIST.SP.800-30 – via csrc.nist.gov. {{cite journal}}: Cite journal requires |journal= (help)
  12. ^ Gulick, Jessica; Fahlsing, Jim; Rossman, Hart; Scholl, Matthew; Stine, Kevin; Kissel, Richard (16 October 2008). "Security Considerations in the System Development Life Cycle". NIST. doi:10.6028/NIST.SP.800-64r2 – via csrc.nist.gov. {{cite journal}}: Cite journal requires |journal= (help)