{"id":4432,"date":"2018-02-28T08:00:53","date_gmt":"2018-02-28T08:00:53","guid":{"rendered":"http:\/\/www.icterra.com\/?p=4432"},"modified":"2021-10-04T14:14:44","modified_gmt":"2021-10-04T14:14:44","slug":"solution-oriented-risk-management","status":"publish","type":"post","link":"https:\/\/www.icterra.com\/solution-oriented-risk-management\/","title":{"rendered":"Solution Oriented Risk Management"},"content":{"rendered":"

Author:\u00a0<\/strong>Fikret Ottekin, Consultant \u2013 Cyber Security<\/p>\n

 <\/p>\n

\"\"<\/p>\n

Introduction: Cyber Security and Information Security<\/strong><\/p>\n

\u201cCyber Security\u201d, which gets more and more coverage on the agenda every single day, is actually a subset of information security. The weight of cyber security in information security keeps increasing due to the integration of businesses with computer networks and intensity of threat agents in the cyber space. Physical security of papers, information systems, facilities and information bearing critical human assets should still be called \u201cinformation security\u201d.<\/p>\n

Definitions of \u201cCyber security\u201d, which are available in standards and legislation are not totally consistent with each other.<\/p>\n

For instance, Cybersecurity is defined as \u201cpreservation of confidentiality, integrity and availability of information in the Cyberspace\u201d in ISO 27032 Guidelines for Cybersecurity [1], whereas it is defined as \u201cProtection of information systems forming cyber space from attacks, assuring confidentiality, integrity and availability of information\/data processed in this environment, detection of attacks and cyber security incidents, activation of counter-response mechanisms and recovering systems to conditions prior to the cyber security incident,\u201d in the 2016-2019 National Cybersecurity Strategy [2]<\/p>\n

Due to the consequences and incidents that take place in the cyber space, cyber security may also be defined as \u201cProtection of information systems which have to work on line from the attacks conducted from the networks.\u201d<\/p>\n

Whether it is called cyber security or information security, all organizations should try to assure the availability and confidentiality of their business from the attacks emerging from the cyber space, with a reasonable budget. The first step towards that goal is conducting a realistic evaluation of the organization\u2019s business, as well as the information and information systems that business depends on.<\/p>\n

Most important objects of information security are safeguarding the availability and confidentiality of information that is generated and\/or used by organizations.<\/p>\n

In that respect, evaluation should be carried out to find out which information and information systems matter more. Value of information is related to the business where that information is used, whereas the value of business depends on contracts, expectation of economic gain, legal obligations and organizational mission and vision.<\/p>\n

Risk Analysis<\/strong><\/p>\n

International standards evolve due to experience gained during their implementation. There are considerable differences between the 2005 and 2013 revisions of \u201cISO 27001 Information Security Management Systems Requirements\u201d standard, too.<\/p>\n

Changes indicate that \u201cvulnerability based\u201d, instead of \u201casset based\u201d risk analysis should be conducted. I believe that correct interpretation and implementation of that change would improve the quality of both risk analysis and information security, which is the scope of this blog entry.<\/p>\n

Two of the changes in the ISO 27001 standard is related to risk management, where the first change is about how risk analysis should be conducted and the second change is about the documentation of risk analysis:<\/p>\n

    \n
  1. While the method to conduct risk analysis is defined in the 2005 revision of ISO 27001 [3]; 2013 revision simply refers risk analysis to \u201cISO 27005:2011 Information Security Risk Management\u201d standard, which differs from the approach of ISO 27001:2005.<\/li>\n
  2. In ISO 27001:2013, documentation of risk evaluation methodology is not mandatory any more. The requirement is rather recording the tasks practiced within the scope of risk evaluation. To sum up, \u201cwhat is done\u201d is recorded instead of \u201chow it should be done\u201d.<\/li>\n<\/ol>\n

    Returning to methodology, I find two statements rather significant in the latest revision of risk management standard, which clearly differ from the definitions made in the previous revisions of ISO 27001 and 27002:<\/p>\n

      \n
    1. Business processes are among the primary assets of the organization [4]. They should be included in the list of assets. Yet, ISO 27002:2005 standard does not include business processes in the inventory of assets [5].<\/li>\n
    2. Information security incidents may effect multiple assets [6] due to presence of assets with similar nature and vulnerabilities. Failing to manage a vulnerability that is present in multiple assets may lead to the compromise of all these assets by a threat with the capability of exploiting that vulnerability.<\/li>\n<\/ol>\n

       <\/p>\n

      Evaluation of Business<\/strong><\/p>\n

      The first step of preparing the inventory of assets is correctly defining the business and the business processes of the organization. Then, the value of these processes should be determined according to objective criteria. The value of a business process is proportional to the consequence that would be observed when that process comes to a halt. In terms of consequence, both material loss and loss of reputation is possible, and should be considered.<\/p>\n

      Business processes and evaluation criteria given below in Table-1<\/strong>,<\/strong> should assist all sorts of organizations and institutions:<\/p>\n\n\n\n\n\n\n\n
      Type of Process<\/strong><\/td>\nConsequence due to Process Failure<\/strong><\/td>\n<\/tr>\n
      a.\u00a0\u00a0\u00a0 Processes running to fulfill legal obligations of the organization<\/td>\nAmount of sanctions defined by the legislation defining the obligation<\/td>\n<\/tr>\n
      b.\u00a0\u00a0\u00a0 Processes running to fulfill obligations defined by a project contract<\/td>\nFinancial loss<\/td>\n<\/tr>\n
      c.\u00a0\u00a0\u00a0\u00a0 Processes running to produce goods and\/or services for the consumer market<\/td>\nFinancial loss<\/td>\n<\/tr>\n
      d.\u00a0\u00a0\u00a0 Support processes (IT, human resources etc.) enabling the execution of the processes defined above<\/td>\nTotal financial loss due to halt of supported processes<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

      Table-1.<\/strong> Types of processes and evaluation criteria<\/p>\n

      Evaluation of Information and Information Technology Assets<\/strong><\/p>\n

      After the business processes are defined and evaluated, assets needed for the execution of these processes should be deduced.<\/p>\n

      Assets needed by a business process are as important as the business process they are facilitating. That situation may also be stated as \u201cAssets\u2019 value are proportional to the importance of the process that depend on them\u201d. Hence, while assets are being evaluated, the total value of the processes those are enabled by the asset should be considered.<\/p>\n

      What\u2019s more, just like business processes, values of software, hardware and other assets should be passed on to the assets they are dependent to [7]. Figure-1<\/strong> depicts that situation.<\/p>\n

      \"\"<\/p>\n

      Figure-1.<\/strong> Evaluation of assets according to the processes they enable<\/p>\n

      Evaluation of Vulnerabilities<\/strong><\/p>\n

      After the evaluation of assets, the vulnerabilities present in the assets should be reviewed.<\/p>\n

      In the context of that blog entry, \u201cvulnerability\u201d should be interpreted as \u201cvulnerability of an asset due to a missing security control (such as authentication, patch management or periodic maintenance)\u201d. That kind of vulnerability may lead to the compromise of multiple assets by a single threat agent, as stated in part 8.3.2 of ISO 27005:2011.<\/p>\n

      While conducting vulnerability analysis in an organization, implementation of a subset of the security controls that are defined in the security standards should be inquired. The subset of controls may be selected from ISO 27002, keeping in mind that the security controls should cover multiple assets or asset families.<\/p>\n

      Vulnerabilities are usually inherent to a specific kind of asset, as depicted in Figure-2<\/strong>.<\/p>\n

      \"\"<\/p>\n

      Figure-2.<\/strong> Vulnerabilities and effected assets<\/p>\n

      Here is a list of security controls and assets secured by that security control through successful implementation of that control. (That list may be used as a checklist to conduct vulnerability analysis in an organization):<\/p>\n

        \n
      1. Secure disposal process assures confidentiality of information in printed documents and hardware, that are about to be disposed.<\/li>\n
      2. Encryption measures assure confidentiality of information belonging to the organization, especially information stored in the cloud and portable memory devices.<\/li>\n
      3. VPN (Virtual Private Network) assures confidentiality of information transmitted through public networks.<\/li>\n
      4. Information backup process assures availability of information belonging to the organization.<\/li>\n
      5. Management of environmental conditions assure availability of information systems, printed documents and the staff.<\/li>\n
      6. Business continuity management assures availability of information systems, especially after natural disasters.<\/li>\n
      7. Capacity management assures availability of services of human resources and information systems, especially network infrastructure and servers.<\/li>\n
      8. Information security awareness assures, through staff activities, availability and confidentiality of information.<\/li>\n
      9. Access control assures the confidentiality and availability of information through \u201cneed-to-know\u201d principle.<\/li>\n
      10. Network access control assures confidentiality and availability of information through network segmentation and peripheral control systems.<\/li>\n
      11. Patch management assures confidentiality and availability of information accessed through COTS software applications.<\/li>\n
      12. Secure software development assures confidentiality and availability of information accessed through software applications developed specially for the organization.<\/li>\n
      13. Secure configuration assures confidentiality and availability of information accessed through well-known information systems, operation systems and applications.<\/li>\n
      14. Antivirus systems assure confidentiality and availability of information in fixed and mobile computing environments.<\/li>\n
      15. Physical access control assures confidentiality and availability of information through assuring the availability of hardware assets, especially against physical attacks, theft and sabotage.<\/li>\n
      16. Inventory asset management assure confidentiality and availability of information through assuring the due coverage of all assets that are subject to security policies and practices.<\/li>\n
      17. Secure maintenance process assures both availability of hardware subject to periodic maintenance (such as printers, copiers, generators, UPS, etc…) and confidentiality of information present in these devices.<\/li>\n
      18. Record management assure confidentiality and availability of information through generation of evidence against unauthorized access to information systems.<\/li>\n
      19. Contract management assure confidentiality and availability of information in interactions with parties providing services to the organization.<\/li>\n
      20. Human resource security management assure confidentiality and availability of information available to staff, ex-staff and third parties employees authorized to access information of the organization.<\/li>\n
      21. Penetration tests and security audits assure confidentiality and availability of information through reviewing and validating the current state of security controls in the organization.<\/li>\n<\/ol>\n

        Evaluation and Mitigation of Risks<\/strong><\/p>\n

        The checklist given above may be used by auditors to verify each control\u2019s implementation depth and coverage in the organization.<\/p>\n

        Reviewing the status of each security control given in the above checklist, auditors may find that<\/p>\n

          \n
        1. Security control is implemented with sufficient depth and coverage.<\/li>\n
        2. Security control is implemented with sufficient depth, but some of the business processes or supporting assets are not covered.<\/li>\n
        3. Security control is partially implemented. Both depth and coverage is insufficient, or<\/li>\n
        4. Security control is not implemented at all.<\/li>\n<\/ol>\n

          Specifying the missing depth or coverage, risks may be derived by the auditors for each security control in the checklist given above.<\/p>\n

          The following examples may be given for the risks identified in an organization with the \u201cSolution oriented risk analysis\u201d method:<\/p>\n

            \n
          1. Since access control policy is not reviewed regularly, secret information may leak from projects specific to defense sector.<\/li>\n
          2. Patch management procedure does not assure that the operating systems of users on the corporate network are up-to-date, which increases the likelihood of compromise for these computers.<\/li>\n
          3. All the servers in the system room may shutdown unexpectedly since records about the periodic maintenance of UPS batteries are not available.<\/li>\n
          4. Due to insufficient physical access control, sabotage or theft is not out of question for the system room at the corporate headquarters.<\/li>\n<\/ol>\n

            Examples given above clearly indicate the root cause of the risk, which is an insufficiently implemented security control.<\/p>\n

            The quantity of these risks should be assessed next. The only step that must be taken to assess the risk is deducing the likelihood that, for an (Asset Class, Vulnerability) combination, due to the presence of vulnerability, threat agents would acquire access to the assets and compromise them.<\/p>\n

            After the likelihood is deduced, quantity of the risk is computed, multiplying the likelihood with the combined value of assets defined in the risk. That is depicted in Figure-3<\/strong>.<\/p>\n

            \"\"<\/p>\n

            Figure-3.<\/strong> Risks and effected assets<\/p>\n

            Once a risk is identified and evaluated, the need to mitigate the risk should be reviewed by the management. If the risk has to be reduced and required resources are available, deciding what to do about the risk is simple, since the root cause of the risk is defined as the insufficient implementation of a security control. Implementation of that security control with sufficient depth and coverage would mitigate the risk.<\/p>\n

            Conclusion<\/strong><\/p>\n

            In this blog entry, a method is defined to evaluate the business processes of an organization, the assets those are facilitating the processes and the risks that may compromise these assets.<\/p>\n

            In the defined method, risk analysis is conducted in reverse fashion, answering the question \u201cWhat are the insufficiently implemented security controls in this organization?\u201d, instead of \u201cWhich security controls should be implemented to mitigate the risks in this organization?\u201d. In this method, the security control that should be employed to mitigate a risk is inherently present in the definition of the risk, which ease moving to risk mitigation phase from the risk evaluation phase.<\/p>\n

            The security controls that must be reviewed primarily to deduce organization\u2019s risks is also presented as a list under \u201cEvaluation of Vulnerabilities\u201d heading.<\/p>\n

             <\/p>\n

            References<\/strong><\/p>\n

             <\/p>\n

            1- \u00ab4.20 Cybersecurity,\u00bb inside ISO\/IEC 27032 Guidelines for Cybersecurity, Geneva, International Organization for Standardization \/ International Electrotechnical Commission, 2012, p. 4.<\/p>\n

            2- \u00ab2016-2019 National Cyber Security Strategy,\u00bb [Online]. Available: http:\/\/www.udhb.gov.tr\/doc\/siberg\/UlusalSibereng.pdf. [Accessed: 14 02 2018].<\/p>\n

            3- \u00ab4.2.1 Establish the ISMS,\u00bb inside ISO\/IEC 27001 Information Security Management Systems-Requirements, Geneva, International Organization for Standardization \/ International Electrotechnical Commission, 2005, pp. 4-5.<\/p>\n

            4- \u00abB.1 Examples of Asset Identification,\u00bb inside ISO\/IEC 27005 Information Security Risk Management, Geneva, International Organization for Standardization \/ International Electrotechnical Commission, 2011, p. 33.<\/p>\n

            5- \u00ab7.1.1. Inventory of Assets,\u00bb inside ISO\/IEC 17799 Code of Practice for Information Security Management, Geneva, International Organization for Standardization \/ International Electrotechnical Commission, 2005, p. 19.<\/p>\n

            6- \u00ab8.3.2 Assessment of Consequences,\u00bb inside ISO\/IEC 27005 Information Security Risk Management, Geneva, International Organization for Standardization \/ International Electrotechnical Commission, 2011, p. 18.<\/p>\n

            7- T. Matarac\u0131o\u011flu ve F. Ottekin, \u00abVarl\u0131k Ba\u011f\u0131ml\u0131l\u0131klar\u0131 ve Hiyerar\u015fik Varl\u0131k Envanteri,\u00bb Ulusal Bilgi G\u00fcvenli\u011fi Kap\u0131s\u0131, 28 Eyl\u00fcl 2011.<\/p>\n","protected":false},"excerpt":{"rendered":"

            Gedankenexperiment (Gedankenerfahrung or thought experiment) is a way of thinking that maps a theory to possible causes and consequences (to shed light on these), when no clues or indicators are available to validate the theory.<\/p>\n","protected":false},"author":1,"featured_media":1218,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_et_pb_use_builder":"","_et_pb_old_content":"","_et_gb_content_width":"","footnotes":""},"categories":[21],"tags":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.icterra.com\/wp-json\/wp\/v2\/posts\/4432"}],"collection":[{"href":"https:\/\/www.icterra.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.icterra.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.icterra.com\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.icterra.com\/wp-json\/wp\/v2\/comments?post=4432"}],"version-history":[{"count":0,"href":"https:\/\/www.icterra.com\/wp-json\/wp\/v2\/posts\/4432\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.icterra.com\/wp-json\/wp\/v2\/media\/1218"}],"wp:attachment":[{"href":"https:\/\/www.icterra.com\/wp-json\/wp\/v2\/media?parent=4432"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.icterra.com\/wp-json\/wp\/v2\/categories?post=4432"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.icterra.com\/wp-json\/wp\/v2\/tags?post=4432"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}