Enrique Polanco Abarca @epola001
Director of Technology and Logical Security Global Technology 4E
Senior Engineer in computing by Old Dominion University (Norfolk VA, USA). 5 years manager of Logical Security of the Prisa Group in Spain. Executive Master In Global Security Management (European University of Madrid). Lead Auditor, Specialist & Expert ISO27001 by AENOR (2007).
Director of Adhoc Security www.adhoc-security.es
Telecommunication Engineer by Telecom Sud Paris in 1982. 13 years Expertise in ISMS (Information Security Management ISO27001). 7 years Expertise in BCM (Business Continuity Management BS25599/UNE71599/ISO22301). Member of SC27 (Security Norms committee in SPAIN/AENOR). Teacher of AENOR Education program for ISO27001 and ISO22301. Lead Auditor BSI BS7799 (2001). Lead Auditor, Specialist & Expert ISO27001 by AENOR (2002). CISA (2013)
Every one, whatever is his ground or level of expertise, is able, using tools, training, and time to obtain results, with a minimum dedication and effort. It means that a perfect security specialist may achieve good technical results on vulnerability identification and resolution. A good event manager may register full of events and presents very different and interesting diagrams and reports. By the same way, a risk analyser may spend hours trying to prevent or anticipate the future, by using complete or complex risk methodology, having “good” appetite on Risks. On the other hand, an auditor or compliance manager may identify the level of compliance for a set of controls (ISO27002, PCI-DSS, etc.).
Several issues occur when you try to fulfil all those expertise and experts together. And raise the following problems:
• No common objectives: each one has their own objectives but they are not shared (i.e: Audit wants to achieve 0 No conformity, SIEM to register and solve ASAP incidents)
• Vocabulary misunderstanding: Vulnerability may be assumed or understood as a risk, even if there is no risk. A No-Conformity may be treated as a problem or as vulnerability.
• Security breach due to bad Priorities: The common security objectives may be hidden or under-prioritize beyond the individual experts priorities (i.e: effort will be done to apply a patch to a level 5 scoring vulnerability, instead of focusing on a higher level as the IP impact on Confidentiality, Availability or Integrity is not enter in the CVSS scoring)
• Technical no-integration or overlapping: Each aspect may have their own tools, but cannot work together and therefore the tools functions overlap (i.e.: a tool of Vulnerability, or SIEM, or ISO27002 compliance may have each one a Risk analyser function, but not compatible)
• Time scale problem: Each process does not have the same Time scales for actions or priorities (i.e: audit by year plan, vulnerability by weeks, events by immediate scale, norms change every 3 or 5 years…)
To overcome those problems, it is clear that those 3 hot aspects need an Integration effort, and this effort consists of 4 lines of actuation, 3 ones for the pair (Integration 1 to1) and a forth working for all together, as represented in figure 1. All the topics described in Figure 1 will be commented in this article.
Figure 1. 3 HOT Aspects & Integration
HOT 3 SECURITY ASPECTS
Before entering the Integration solution, it is important to know the current state of art or issue of each aspect. All what I may expose may be obsolete in one month, when appears on the market new tools or new services to address those aspects; therefore I will stay quite superficial or focus on what I think are the main issues for a global or standards point of view.
The risk management is a very new process, from a standard or global point of view, less than 5 years. At the time of the article there are 2 main international standards:
• ISO/IEC 31000:2009, Risk management – Risk assessment techniques: which focuses on risk assessment in general
• ISO/IEC 27005:2011 Information technology – Security techniques – Information security risk management: which focus on Risk for Information technology but compatible with ISO 31000.
Figure 2. ISO 31000 Risk management activities
Both norms explain that a Risk management has two main phases: 1-Assesment and 2-Treatment, well explained in the new ISO/IEC ISO27001:2013.
• The information security risk assessment consists in identifying and evaluating risks in comparison with the defined risks criteria to acknowledge the accepted risks and priorities.
• The information security risk treatment consists in selecting appropriate information security risk treatment options and determining all controls that are necessary to implement the information security risk treatment option(s) chosen.
The new ISO27001 does not specify what the components of a risk are, but generally speaking, the identification and evaluation of a risk is based on 2 components (Cause and Consequence). In reference with the ISO/IEC 27005, the purpose of risk identification is to determine what could happen to cause a potential loss, and to gain insight into how, where and why the loss might happen.
• Consequences: the value of the Asset (usually impact analysis) within the scope or the Risk management context
• Cause: the probability of occurrence of the threat to produce those consequences
There are different methods and tools to support the complexity of the risk models (relational model between Information Asset layers: i.e Invoice<->-SW ERP<->HW Server<->IP …). Whatever is the model, the objective of Risk management is not to obtain an accuracy of 99% on risk calculation (nobody can predicts the future), but to define priority and treatment proportionality, depending on the level of risks. An example of Risk Matrix (Table 1)
For this matrix the treatment depends on the level of risks:
Security Information and Event Management (definition extracted of SIEM from Wikipedia) is a term for software and products services combining security information management (SIM) and security event manager (SEM). SIEM technology provides real-time analysis of security alerts generated by network hardware and applications. SIEM is sold as software, appliances or managed services, and are also used to log security data and generate reports for compliance purposes.
We can appreciate in Figure 3, an online report on Alert produce by the Tool Alienvault.
Figure 3. OTX (Open Threat Exchange) alerts
Something clear is that SIEM manage EVENTS, and those events are past or present, but not future.
Someone may argue that, depending on the confidence of the prevision, the occurrence of a future event may be evaluated, but this falls into the Risk Management process. The only sure issue is that, if there is vulnerability or an incident detected (Event), a way of eliminating a risk in the future due to this vulnerability is to supress the vulnerability itself.
A SOC (Security Office Center) is a set of internal or external resources (People, Tools, Processes) trying to minimize the Elapse Time between the present Events and the possible future Eventsto reduce the possibility of having negative Event, or to reduce as quickly as possible the detected events, like Figure 4.
Figure 4. Events Detection from a SOC7
The ISO/IEC 27002:2013 “Information technology – Security techniques – Code of practice for information security controls”, is an International Standard which provides a list of commonly accepted control objectives and best practice controls to be used as implementation guidance when selecting and implementing controls for achieving information security. Its purpose is to provide guidance on the implementation of information security controls defined in the Annex A of ISO/IEC 27001 (Table 3). This International gets a new release last October 2013.
To understand the compliance within the ISO27002, it should be understood that it must not only to be conform to the last Clause “18-Compliance”, but also to ensure that all the applicable security controls are implemented in and efficient way for security objectives.
The Compliance, or the confidence in the level of conformity of the applicable control is better estimated or obtained through independent review, explain in Objective “18.2 Information security reviews”, with 1 objective and 3 controls (see Table 4).
The audit department can realize that independent review, by themselves or sub-contracting audit to external companies. Some controls may be audited directly with technical audit tools (Vulnerability Audits, Log Audit, by example)
We will analyse the 3 pairs of integration to understand their specific issues.
RISK ANALYSIS-ISO27002 COMPLIANCE
This Integration pair is filled by the ISO/IEC 27001 ISMS Information security management system. An ISMS is defined in ISO/IEC 27000:
ISMS: An Information Security Management System consists of the policies, procedures, guidelines, and associated resources and activities, collectively managed by an organization, in the pursuit of protecting its information assets. An ISMS is a systematic approach for establishing, implementing, operating, monitoring, reviewing, maintaining and improving organization’s information security to achieve business objectives. It is based upon a risk assessment and the organization’s risk acceptance levels designed to effectively treat and manage risks. Analysing requirements for the protection of information assets and applying appropriate controls to ensure the protection of these information assets, as required, contributes to the successful implementation of an ISMS.
This international standard requires from an organization, within a determined Scope, to realize a Risk management, and to develop very interesting process and documentation activities (the following list is not exhaustive of all the requirements of ISO27001)
• SCOPE: The scope is a document which explains the relation between the activities, information assets and technological assets and services.
- I.e: Activity (Invoicing), Information Asset (Invoices), Technological Assets (ERP Sw+Servers+Network with IPs).
• RISK: Risk report and the acceptation of the residual from the risk owners.
• SOA: A statement of applicability (S0A) of the 114 controls of the ISO/IEC 27002.
- An organization shall produce a Statement of Applicability that contains the necessary controls and justification for inclusions, whether they are implemented or not, and the justification for exclusions of controls from the ISO27001- Annex A (114 controls of ISO27002).
• RTP: Formulate an information security Risk Treatment Plan (accepted by the Risk owners) to explain the plan to implement the security controls which are no yet implemented.
• AUDIT: The organization shall plan, establish, implement and maintain an audit programme(s), including the frequency, methods, and responsibilities, planning requirements and reporting. The audit programme(s) shall take into consideration the importance of the processes concerned (Risk oriented Audit)
Apart from the own implementation of the ISO27001, this process may be certified by an accredited certified company which give additional confidence internally and externally.
The use of a risk method gives the opportunity to evaluate the Impacts on the final IP (servers IP) obtained from the Impact of the Information or process supported.
• I.e: supposing that an Impact method has associated the level impact to an ERP Information as followed on the 4 dimension of security:
• Confidentiality: Medium (C:M)
• Integrity: High, (I:H)
• Availability: Medium. (A:M)
• Authenticity: High (a:H)
• Therefore its external IP (the IP of the ERP Web servers) will inherit those vector values
• (CIAa = M:H:M:H)
Those values are used for different purposes:
• To calculate correctly the CVVS scoring for vulnerability (Base metrics of CVSS: see http://www.first.org/cvss/cvss-guide for more information).
• For all the SIEM report, where the Risk is not only associated to the vulnerability level, but also with the Risk level (see Figure 5)
Figure 5. Risk Report
• By the same way, to reduce the Exposure to Vulnerabilities, it may be useful to create a loop on the Vulnerability management process. In the next Figure 5, after discovering some vulnerabilities, only 2 will be send for remediation. The Pol3 scanning policy is there to check, that the remediation is realized.
The method is as follow:
• defining the Audit policy depending on technologies, and previous results, and assignments of the C.I.A weights to each IPs
• realizing the Vulnerability Audit scanning according to policies
• reporting the findings calculating the CVSS score, from 0 to 10, based on the C.I.A weight of the IP and dangerousness of the Vulnerability. (see figure 6 Vulnerability Report)
• depending on the Risk Threshold (CVSS score), the vulnerability information are sent for remediation with priority Flag (urgent is threshold is > 8), using Incident Management SW: SIEM, Remedy, etc..)
• the loop is created by ensuring that there is a policy to check the previous results (by CVSS score, or database of previous vulnerabilities, etc..)
Figure 7. Vulnerability Report with Priorities