Business and security teams alike have seen breathtaking changes over the last few years with the rise of a digital universe that is global, social, mobile and interconnected. New business models and technologies introduce new risk factors as organizations expand supply chains to distant partners; outsource key functions to third parties, in which visibility into best practices may be obscured; and entrust regulated information to cloud service providers.1 In the midst of increased threats and regulatory and technology complexities, risk professionals are being pressured by customers, regulators and suppliers, who demand and require explanations as to how risk is being identified, managed and controlled.
In 2012, 66 percent of breaches that led to data compromise within days or less remained undiscovered for months or more and, in 69 percent of the cases, a third party discovered the breach.2 Clearly, security teams need more proactive, business-driven models that provide insight to better protect critical processes and sensitive information.
Security and risk intelligence that yields 360-degree, near real-time views is becoming foundational in order to keep critical processes running and sensitive assets protected. Integrating security analytics into governance, risk and compliance (GRC) processes allows security and business teams to build a common language and discussion framework around risk appetites and scenarios, ultimately aimed at improving the way risk is identified, analyzed and mitigated. Most important, when framed in the GRC taxonomy, analytics provide a context that the business and the board of directors can understand and use when making decisions ranging from improving business processes to making necessary security investments. It is this fundamental need to mature from risk identification to risk analysis and, finally, to risk intelligence that drives the maturity of security analytics programs (figure 1).
There is a growing convergence of security programs with enterprise GRC programs. The Open Compliance and Ethics Group (OCEG) Global 2012 GRC Maturity Survey revealed that 90 percent of organizations that have implemented programs to reduce the fragmentation of security, IT, finance, legal and operational risk programs have realized significant benefits.3 GRC programs seek to provide integrated and federated processes that increase contextual understanding, visibility and remediation of key risk and compliance exposures across the enterprise. GRC programs must understand the size, scale and scope of risk to effectively and efficiently implement the appropriate corrective action plans to mitigate risk.
Information security programs seek to protect the confidentiality (access, use and disclosure), integrity (modification or destruction) and availability of information and systems from unauthorized users, including external adversaries such as criminals, hacktivists or governments. Information security programs must identify and respond to risk in a rapidly evolving technology landscape characterized by increasing complexity, volume and variety of data and all of the associated threats to business processes, applications and networking layers.
A well-designed and implemented security analytics program that is integrated with a GRC program serves both security and business teams by providing analysis, insights and metrics that give an organization the risk intelligence needed to act on and drive better business performance. Security analytics deliver the much-needed insights in mapping the size, scale and scope of risk, and provide a basis for root-cause analysis and remediation strategies across policies, processes and technologies. For example, security analytics that can show trends such as increasing exploits against key assets can be used to justify changes to corporate policy, the implementation of stronger controls, and investments in monitoring technologies for identity management and access control.
Analytics are more than just metrics. The key ingredient in an analytics program is the ability to slice and dice the data on an ad hoc basis in real time or near real time. Metrics, on the other hand, represent numeric information that is generated by calculations often derived from aggregating the vast amount of data gathered from multiple sources, such as logs, events or transactions. A metric that is the result of a calculation, in and of itself, does not provide insight.
A key performance indicator (KPI) is a specific type of metric that measures performance against objectives and can bridge business objectives with security metrics. For example, a business KPI could be based on the number of orders and the average size of orders lost due to security incidents and could be a metric of interest to security teams and the business. For example, ISACA’s COBIT 5 framework provides best practice guidance on KPIs for 37 IT processes.4
Metrics are a fundamental and essential part of a security analytics program. For example, the metric for mean time to recovery from an incident provides insight when analyzed with the severity of incidents, the impact to the organization and a root-cause analysis. What may be most important to know are answers to questions such as: How can the incident management process be streamlined to minimize impacts on key business processes? How can the organization ensure that the right incident management processes are in place to handle current security threats and potential future critical ones? What technologies will help the organization be proactive in preventing severe incidents?
The volume, complexity, velocity, variety and veracity of data make the task of identifying risk with traditional security monitoring systems cumbersome. Big data analysis can be used to detect probable threats based on current vulnerabilities by delving into the large, diverse and dynamic structured and unstructured data sets running on Hadoop clouds, leveraging analytics languages such as R. Another use case may be the correlation of security events in the context of critical business processes, applications and sensitive information. Security metrics and analytics are as vital to an organization’s performance as metrics on liquidity, cash flow and revenue, as organizations seek to have a 360-degree view of risk across all of their operations.
Security analytics programs need to be embedded within GRC programs at five layers (figure 2), as described in the following sections.
Optimizing Governance, Reporting and Decision Making Through Appetites and ThresholdsSecurity analytics thrive within a framework of appetites and thresholds. The board of directors is required to set risk appetites, which senior management translates into thresholds, which are then mapped to policies that govern the behavior of people, processes and systems. For example, the board may establish a zero-tolerance policy on regulatory noncompliance, which then must be reflected in compliance program governance, processes to establish controls and testing to ensure that controls are designed and operating effectively. Once established, policies, controls and reporting can be calibrated to feed the right indicators that allow management to make decisions to avoid, treat or transfer risk efficiently and effectively. Without well-defined risk appetites, a security analytics program may provide meaningless, misleading or incomplete information to decision makers who can actually increase the organization’s risk. For example, the board’s zero-tolerance policy on regulatory noncompliance translates into specific access control, identity management, authentication and incident response processes that include controls for personally identifiable information (PII) that is protected by regulations (e.g., the US Gramm-Leach-Bliley Act [GLBA], the EU Data Protection Directive, the US Health Insurance Portability and Accountability Act [HIPAA], the State of California’s CA-1386). Security teams rely on standard control frameworks such as ISO 27002 from the International Organization for Standardization (ISO) and NIST 800.53 from the US National Institute of Standards and Technology (NIST) to provide assessments of how closely their systems are operating to established baselines.
Everything depends on the right formulation of thresholds, policies, controls, and what is viewed and expressed as a risk. This is then translated into security- and technology-related thresholds that have meaning to security teams. Without a good articulation and agreement from executives on the organization’s risk appetite, it is simply impossible for the organization to effectively manage its risk.
Security analytics can be leveraged in the governance process as a means to open and extend the conversation around risk appetite, tolerances and thresholds. This is an ongoing process among the business, IT and security teams, in which metrics give rise to analysis, which gives rise to new questions being asked and more analytics being provided to determine the root cause and intended performance improvements. This discussion will likely extend the traditional risk and control framework to a policy, risk, control and asset framework, with a focus on KPIs, key risk indicators (KRIs) and key control indicators (KCIs), which will help provide insight and warning signals for possible loss events and other exposures. Metrics and analytics help business owners make decisions about accepting, transferring or remediating risk and making investments in people, processes and technology.
Often IT and security professionals are asked to sign off on risk that really belongs to the business. While it is sometimes difficult to get the business to own or sign off on risk that has security or technology components that it simply does not understand, security professionals must strive to map threats and vulnerabilities unique to security and IT to business processes, impacts and thresholds in order to move the business to take rightful ownership of risk.
Business continuity and disaster recovery programs are far more mature in measuring such impacts, e.g., the effect of an e-commerce site outage on online orders.
Aligning the GRC Information Ontology With Security Analytics and Metrics ProgramsAn information ontology is a model that provides a description of classes, entities, ways in which classes relate to one another, rules, calculations and metrics. In GRC and security, ontologies are becoming powerful ways to get diverse stakeholders to use a common language and taxonomy when describing risk.
The security analytics ontology should be aligned to the overall organization risk ontology (figure 3) and include threats, vulnerabilities, assets, incidents, security overlays, configuration baselines, and other attributes important to maintaining security hygiene and protecting against advanced threats and complex attacks.
Building Sustainability Into the Security Metrics Program and CatalogSecurity analytics depend on metrics; therefore, it is critical to define a metrics program and catalog that can be easily implemented, are based on industry standards and baselines, and provide a basis for benchmarking.
NIST SP 800-55 describes a metric as having the following attributes,5 all of which should be considered as metrics are defined:
At the strategic level, metrics can be used to assess maturity levels for key information security program capabilities. At the tactical level, metrics can be used to improve security processes, such as scoping risk assessments, testing controls, determining remediation strategies and corrective action plans, streamlining incident and crisis management processes, and supporting business continuity and resilience. At the operational level, metrics are an essential component of information security program management.
The Center for Internet Security (CIS) defines a set of metric categories and provides a set of security metrics and consensus guidance (figure 4).6
It is important to track how metrics change over time and how past metric values might be used to forecast the future and to identify which factors are most influential in driving outcomes. An evolving and sustainable security analytics program builds out scenarios, identifies further factors for investigation and refines data collection and correlation techniques.
Content from the European Network and Information Security Agency (ENISA),7 NIST8 and ISO9 frameworks can be leveraged in analytics programs to provide information on security threat communities and the most likely attack vectors, motivations to access various assets and skill levels. Threat frequency analytics can help in determining if controls on assets provide the right level of resistance to threats. Encouraging risk analysts and subject matter experts to stay current with emerging threats and control standards in order to drive frequent improvements into security analytics programs has never been more important to the business.
Aggregating Data Across the Security EcosystemThe most important technical capability in a security analytics program is the ability to collect, rationalize and aggregate information across multiple sources and model processes, and to perform what-if analyses to determine the impact across the technology ecosystem. For example, when applying security analytics to incident response processes, key factors in the definition of the metric formula may include the impact of changes on the threat landscape and service level agreements (SLAs). Other factors to consider are notifications to authorities, suppliers and customers in the event of a breach, as well as the impact of changes on the control environment in order to mitigate risk arising from new threats.
Continuous monitoring and measurement of anomalies are fundamental to managing risk and understanding what actions to take when thresholds are crossed. Technology is being leveraged more than ever to provide continuous monitoring of technical controls on infrastructure assets, as well as transactions within and between applications and systems. Monitoring provides some measure of confidence that policies and controls are being adhered to and that threats and vulnerabilities are being managed. Security metrics ensure the definition of what to monitor and how frequently. As a best practice, organizations should monitor against defined baselines, standards and acceptable thresholds that have been set by the business. To leverage this information within a security analytics program, KPIs, KRIs and KCIs can be mapped back to business processes to provide early warning alerts, enabling security and business teams to be more proactive.
Leveraging the GRC Technology PlatformA common GRC technology platform, supported by an asset inventory, risk and control framework, and uniform nomenclature of risk, can take a security analytics program to the next level of maturity. The GRC technology platform can be integrated with security and IT monitoring systems to provide an organizational, business process, regulatory, policy and control context. KPIs can trigger issues, notifications and escalations when certain thresholds are breached.
The integration of security analytics within an overall GRC program is driven by business’s increasing need to know the size, scope and scale of risk in order to give guidance on how it can be best managed. Security and business teams need to work together to develop a 360-degree view of risk, comprised of a clear picture of top risk factors and how they translate down through a hierarchy to lower-level controls, with an easy-to- understand risk model. Security analytics, which provide insights based on data and metric analysis, provide a discussion framework that allows management to form a view about the risk, the organization’s appetite and its willingness to take risk to achieve aggressive business objectives.
Metrics and analytics frameworks can be essential enablers when making the transition from risk and compliance identification to risk and compliance analysis, and, finally, to risk and compliance intelligence. Technology can provide a powerful foundation for analytics as more automated continuous monitoring and measurement become available through the technology ecosystem. Integrating security analytics into the enterprise GRC program and technology ecosystem can help drive ownership and accountability between security teams and the business, lower overall risk for the enterprise, and ensure that security analytics become part of a sustainable organizational risk management framework.
1 World Economic Forum, “Partnering for Cyber Resilience,” March 2012, www.weforum.org/reports/risk-and-responsibility-hyperconnected-world-pathways-global-cyber-resilience2 Verizon Data Breach Investigation Report, 2013, www.verizonenterprise.com/DBIR/2013/3 Open Compliance and Ethics Group, Global 2012 GRC Maturity Survey, http://hello.oceg.org/grc-maturity-survey-2012/4 ISACA, COBIT, www.isaca.org/cobit 5 National Institute of Standards and Technology, NIST 800-55, USA, http://csrc.nist.gov/publications/nistpubs/800-55-Rev1/SP800-55-rev1.pdf6 Center for Internet Security, Security Benchmarks, CIS Consensus Security Metrics v1.1.0, November 2010, www.cisecurity.org7 Marinos, Louis; Andreas Sfakianakis; ENISA Threat Landscape Report, European Network and Information Security Agency, 8 January 2013, www.enisa.europa.eu/activities/risk-management/evolving-threat-environment/ENISA_Threat_Landscape8 National Institute of Standards and Technology, Special Publications (800 series), USA, http://csrc.nist.gov/publications/PubsSPs.html9 International Organization for Standardization, ISO/IEC 27000:2009, Information technology—Security techniques—Information security management systems—Overview and vocabulary, www.iso.org/iso/catalogue_detail?csnumber=41933
Yo Delmar, CISM, CGEIT, CMC, is vice president, GRC solutions at MetricStream and has more than 30 years of experience in IT and management, with a focus on governance, risk and compliance. Delmar has broad experience developing GRC program strategies and security programs for large organizations. She can be reached at firstname.lastname@example.org.
Opinions expressed in the ISACA Journal represent the views
of the authors and advertisers. They may differ from policies
and official statements of ISACA and from opinions endorsed by
authors’ employers or the editors of the Journal. The ISACA
Journal does not attest to the originality of authors’ content.