Patent Application
20130253979
Many organizations in today's business climate have developed methodologies for managing profit and loss through a study of internal practices and procedures in light of external forces. Those organizations regularly assess the organization at various levels to identify inefficiencies, unnecessary expenses, and potential liabilities. Documented methodologies for performing and describing such assessments are necessary to ensure that measures are objective rather than subjective and that processes are repeatable, such that meaningful data may be obtained and compared over time and/or through implementation of changes within the organization.
Information is increasingly vital to organizational management and its value as an asset increases accordingly. Managing information security, privacy, and compliance has become a critical domain for risk management efforts. However, traditional information assessment methodologies do not provide an accurate holistic measure of the health and safety of both a maturing organization and its customers. Such a holistic measure could permit an organization to more effectively apply its financial and human resources based on the maturity level of its organization.
Some embodiments of the invention provide a computer implemented method for managing risk. In some embodiments, an organizational impact score is determined from an aggregate of scenario impact scores. The organizational impact score can be stored in a memory of the computer. Some embodiments include calculating a likelihood score based upon an analysis of threats, imminence of each threat, and a likelihood associated with each threat, and storing the likelihood score in a memory of the computer. In some embodiments, an organizational maturity score is determined based on the ability of the organization to mitigate the actions of a potential threat and recover from a given scenario, and the organizational maturity score is stored in a memory of the computer. In some embodiments, a Risk Index is calculated using a processor of the computer wherein the Risk Index=(impact score)*(likelihood score)/(maturity score).
Before any embodiments of the invention are explained in detail, it is to be understood that the invention is not limited in its application to the details of construction and the arrangement of components set forth in the following description or illustrated in the following drawings. The invention is capable of other embodiments and of being practiced or of being carried out in various ways. Also, it is to be understood that the phraseology and terminology used herein is for the purpose of description and should not be regarded as limiting. The use of “including,” “comprising,” or “having” and variations thereof herein is meant to encompass the items listed thereafter and equivalents thereof as well as additional items. Unless specified or limited otherwise, the terms “mounted,” “connected,” “supported,” and “coupled” and variations thereof are used broadly and encompass both direct and indirect mountings, connections, supports, and couplings. Further, “connected” and “coupled” are not restricted to physical or mechanical connections or couplings.
The following discussion is presented to enable a person skilled in the art to make and use embodiments of the invention. Various modifications to the illustrated embodiments will be readily apparent to those skilled in the art, and the generic principles herein can be applied to other embodiments and applications without departing from embodiments of the invention. Thus, embodiments of the invention are not intended to be limited to embodiments shown, but are to be accorded the widest scope consistent with the principles and features disclosed herein. The following detailed description is to be read with reference to the figures, in which like elements in different figures have like reference numerals. The figures, which are not necessarily to scale, depict selected embodiments and are not intended to limit the scope of embodiments of the invention. Skilled artisans will recognize the examples provided herein have many useful alternatives that fall within the scope of embodiments of the invention.
In some embodiments, the Risk Management Framework 100 comprises a set of core components including a list of key business capabilities 102. The key business capabilities 102 include an inventory of components corresponding to each capability. The list of key business capabilities 102 can document the organization's recoverability, control methods, implementation techniques, and risk profiles.
In some embodiments, the Risk Management Framework 100 also includes an Organizational Control Framework 500, that provides a body of harmonized controls that are deemed to meet or exceed selected rules, regulations and guidelines sourced, for example, by the vendor for the Unified Control Framework (UCF) and the organization. In some embodiments, a Risk Management Index 104 may provide a scoring system consistent with the requirements of a governmental agency, such as the Department of Energy (DOE) Utility Industry Guidelines. Practitioners will appreciate that a scoring system may be defined in light of the needs and requirements of the organization or any other entity to which the organization has accountability.
In some embodiments, the Risk Management Framework 100 further includes components that document a history of scenarios and threats, findings from audits, investigations and other tests, and disaster recover/business continuity information, such as recoverability.
As used herein in accordance with some embodiments of the invention, the Organizational Control Framework 500 is a process and methodology deployed to manage and maintain the body of controls for all levels of assets at risk. In some embodiments, the Organizational Control Framework 500 core structure is a body of harmonized controls that contain both elements provided by UCF and those developed by the organization based on its compliance profile and business needs. In the Organizational Control Framework 500 of some embodiments, the term “authoritative sources” is used to denote the sources of the requirements of these controls. This is the same term that is used to describe sources that are added by the organization and are not supported by UCF. In some embodiments, these sources may include, for example, regulations, laws, guidelines and the organization's corporate policy statements.
In some embodiments, the Risk Management Index 104 is a calculation designed to provide a consistent approach for the assessment of information security risk to the organization's business processes, infrastructure, information systems, and technology. Furthermore, application of this calculation enables a consistent approach in prioritizing mitigations and corrective actions across various business units. In some embodiments, the Risk Management Index 104 is developed for each component of a given business capability 102. The analysis includes a development of a scenario 110 exercising one of more vulnerabilities of the component under consideration. In some embodiments, a basis of the calculation comprises a combination of three elements, including and impact score 112, a likelihood score 114, and a maturity score 116.
As used herein in accordance with some embodiments of the invention, impact 112 represents the consequence to the organization in light of a failure of one of more controls permitting an identified threat to bring harm to life, infrastructure, and brand. Likelihood 114 is based on a consideration of the magnitude, skills, ability, and recent activity of the particular threat and likely target. Maturity 116 is based on a consideration of the ability of the organization to mitigate the actions of a potential threat and recover from a given scenario 110.
In some embodiments, the maturity calculation for the Risk Management Index 104 may include the consideration of the state of a particular ability of an asset to mitigate an action. Therefore, all findings from investigations, audits, and other tests may be maintained and rationalized using designated Organizational Control Framework 500 structures.
As used herein in accordance with some embodiments of the invention, a scenario 110 is a real life example of how a particular vulnerability or control failure can lead to a potentially damaging situation for the organization. A scenario 110 can encapsulate the following elements: a discussion of what action is taking place and by whom, a discussion of how the assets vulnerability leads to a compromised situation, and a discussion of the impact and consequence to the organization.
Another element of Maturity 116 that is included in some embodiments of the Risk Management Framework 100 is the organization's ability to recover from a control failure or breach of any form. This information may be included in the calculation of the maturity of the organization and may be considered as important as the ability to prevent a control failure or breach. In some embodiments, corrective and detective controls may be considered with less weight to the overall maturity of the organization.
In some embodiments, an important element of the disclosed Risk Management Framework 100 is the appropriate application of harmonized controls to the assets and processes that a compliance manager manages for compliance. The term “business capability” 102 is used herein to describe a particular combination of assets and processes.
In some embodiments, the concept of a business capability 102 forms a central means for relating organizational assets to the authoritative sources and their controls. In some embodiments, the management of this list of business capabilities may be considered a high-priority item, and tasked accordingly within the organization. Examples of typical business elements are described in reference to
In some embodiments, each business capability 102 may then be broken out into individual components. Practitioners will appreciate that the following components and their respective attribute definitions have been included in this document for description only and do not limit the scope of the invention.
Based on the critical business processes identified by the organization, the following example list of key business capabilities may also be identified. The list may evolve as the components are identified and the effectiveness of the initial configuration is assessed.
Example business capabilities 102 may include, for example, Aviation Services and Management, Bulk Power Operations, Chemical Facility Operations, Distribution Operations, Generation (non-nuclear), Nuclear Facility Operations, Pipeline (Gas) Operations, Communications, Contract/Vendor Management, Customer Care, Enterprise-Wide Infrastructure Services, Financial Operations, Human Resources, Load Forecasting, Physical Facility Access Management and Control, Energy and Commodity Trading, and Work/Workforce Management.
In some embodiments, an objective of the Organizational Control Framework 500 component of the Risk Management Framework 100 is the management and maintenance of the body of harmonized controls. These controls are derived to meet requirements arising from a combination of UCF and authoritative sources provided by the organization.
In some embodiments, there are two forms of information sources for the Organizational Control Framework 500, including:
1) Authoritative sources provided by the UCF. The UCF may provide a body of harmonized controls based on any number of Authoritative Sources. These controls may be distributed in a database, xml, or Excel format, for example, depending on the form of a contract with UCF. In some embodiments, such controls may be updated by UCF on a defined interval (e.g., quarterly). The controls may be for information security, privacy, applicable physical security, etc.
2) Authoritative sources provided by the organization. This information may comprise a combination of regulations, rules, and other guidelines that the organization determines are needed for a complete organizational solution:
In some embodiments, the Organizational Control Framework 500 is configured to manage and maintain only the administrative sources and controls that are applicable to the organization. As such, the list of source information may be filtered in order to capture and retain only relevant data. For example, a primary filter may be defined as the asset class that Organizational Control Framework 500 defines as the business capability 102. A secondary filter is the “applicability” of the source based on whether it is a regulatory requirement or an organizational mandate.
In some embodiments, regulatory required authoritative sources may be manifested only at the Mandatory level of controls. The organization mandated authoritative sources may manifest themselves as Mandatory, Medium, or High level controls.
To accomplish this, each business capability 102 may be cross-referenced with the applicable administrative sources. This results in a body of harmonized controls that are variously relevant to the organization in regard to level of importance. For example, the harmonized controls may be classified as “Mandatory”, “Medium”, or “High”, each being described in greater detail below.
Mandatory—The primary source of Mandatory controls are those required by laws and regulations and are imposed on systems that may be subject to a set of regulations and laws deemed appropriate and necessary for the organization to meet their obligations under state and federal codes for those systems. The organization, at their discretion, may add documents to the authoritative source list that constitute corporate level policy and will have controls associated with them, which are deemed Mandatory by that policy document. These policy documents may require various levels of authorization, for example, by a corporate level officer in order to be considered Mandatory. In some embodiments, Mandatory controls may be applied to all components of all business capabilities, regardless of risk level, based on the regulatory requirements and policies covering those systems.
Medium—These controls may be considered as discretionary from a regulatory perspective and may apply to the components of those business capabilities that have a Medium or High risk ranking. The controls may have originated from authoritative sources, which are considered “advisory” or corporate policy deeming these controls as required for Medium and high-risk capabilities.
High—These are controls that may be considered as discretionary from a regulatory perspective and may apply to the components of those business capabilities that have a high-risk ranking The controls may have originated from authoritative sources that are considered “advisory” or corporate policy deeming these controls as required for high-risk capabilities.
The UCF provides structure to the controls through a concept known as the “impact area.” The origin of this concept is that each of the categories represents a typical IT Domain where these controls would typically be deployed. In some embodiments, UCF defines 14 of these impact areas. However, practitioners will appreciate that any number of impact areas may be defined without departing from the scope of the invention
Within the Risk Management Framework 100 and Organizational Control Framework 500, the impact areas may be referred to as “control families”, and they may take on additional meaning and relevance. In some embodiments, the control family may be used to provide clarity in status and the maturity of the organization in implementing the controls within the family, as well as in focusing effort and expenditure, and assigning responsibilities for action.
In some embodiments, a discretionary control is a supplemental control to those required by regulatory mandate that the organization has determined to be required in order to meet internal risk management objectives for High and Medium risk business capabilities. A discretionary control may be linked through Organizational Control Framework 500 to an authoritative source in a manner that is similar to a linking of a Mandatory control. Moreover, a discretionary control may be managed and maintained as part of the Organizational Control Framework 500 body of controls.
When considering which controls should be added beyond those deemed Mandatory, the consideration of the type of control should be a paramount question. Much analysis would demonstrate that preventive controls are favored, as they prohibit the threat from materializing. In this case, the cost and need of corrective action or recovery is minimized or zero. In addition, preventive controls may provide detailed reporting capability to facilitate an understanding of the changing capabilities and intents of the actors involved at the same time as preventing damage.
In some embodiments, an addition of any form of discretionary control may be accompanied by a “what-if” analysis. This may help determine whether an application of the control would improve the business capability 102, or one if its components' resilience to known threats through a reduction in the Risk Index. In some embodiments, discretionary controls may be restricted to fall in the Medium or High class of controls. Examples of areas where supplemental controls may reduce a risk level include:
These controls may be added to the Organizational Control Framework 500 container under the organization's mandated authoritative document source label, for example, and maintained and updated with other organizational mandated documents and controls. Should the control be created by the organization, it may be provided a unique identifier and is referenced to an authoritative source that the organization may provide. If a source document does not exist and the control is required then an organizational policy document may be created and referenced as the authoritative source. Any organizational created controls may be developed and type defined using the same definitions as UCF provided for the operational controls of a type of preventive, corrective, or detective.
In some embodiments, periodic maintenance of the source content of the Organizational Control Framework 500 engine may be desirable. Maintenance relating to the compliance requirements and the matching up of the updated UCF content with the organization's created content may also be performed at defined intervals, for example.
As each Organizational Control Framework 500 Maintenance cycle is performed, a compliance review may be performed to ensure that the authoritative sources and their associated controls continue to provide the proper level of compliance coverage required to meet the organization's legal operating and reporting obligations.
As components of a business capability 102 are deployed, they may be associated with the relevant Organizational Control Framework 500 controls. In some embodiments, each component inherits the Risk Index of the business capability 102 that it is associated with and that share the same set of identified authoritative sources. As used herein, the Risk Index is a component of the Risk Index Methodology, as will be described in greater detail below. For each component deployed, determination may be made as to how these controls are to be satisfied and identify any implementation technology (i.e., artifact) that may be used to provide the controls.
Examples of implementation technologies may include virus checkers, scans, password management tools, firewalls, etc. The control activity itself may be characterized using the organization's control type definition as automatic, manual, or auto/manual, and this attribute of a component labeled as the implementation method.
Ultimately the effectiveness of these controls and the control activities deployed are tested and the results may be compiled to develop an understanding of the level of maturity of the organization to meet the demands of the threats facing it. In some embodiments, a maturity score is also used in the development of the Risk Index.
As each project is implemented, the control baseline for a project may be considered as the controls and their associated control activities that are required to be implemented for each sub-system or component being deployed. These requirements then form the basis against which any pre-production security testing can be executed.
In some embodiments, a policy outlines security roles and responsibilities, defines the scope of information to be protected, and provides a high-level description of the controls that are to be in place to protect the information. Moreover, the policy may make references to the standards that support it. Businesses may have a single encompassing policy, or several specific policies that target different areas. From a legal and compliance perspective, for example, an information security policy may be viewed as a commitment from senior managers to protect information. A documented policy is frequently a requirement to satisfy regulations or laws, such as those relating to privacy and finance. The security policy may be viewed as a business mandate and it may be driven from the top (i.e. senior management) downward in order to be effective.
In some embodiments, a security policy provides high-level, broad instruction about a significant business operation subject or function consistent with laws and regulations, the company's vision, values and goals, and any direction from a managing entity.
A standard consists of specific Organizational Control Framework 500 Mandatory controls that help enforce and support the information security policy of the organization. As used herein, a standard helps to ensure security consistency across the organization and often includes security controls relating to the implementation of specific technology, hardware, or software.
As used herein in accordance with some embodiments, a standard describes the major steps of a work process and/or major internal or external compliance requirements, and the roles and responsibilities of those involved. A standard may involve one or more organization, department, job function, or compliance requirement.
As used herein in accordance with some embodiments, a procedure consists of step-by-step instructions to assist in implementing the various policies and standards. While the policies and standards consist of the controls that should be in place, a procedure focuses on specifics, explaining how to implement these controls in a step-by-step fashion.
In some embodiments, a procedure comprises a detailed, step-by-step instruction that describes the functions, tasks, and expectations of employees who are responsible for performing a specific function or task. A procedure can include or refer to a set of safety, health, and environmental instructions that an employee needs in order to perform assigned tasks correctly.
In some embodiments, each type of document as previously described, has an inherent target audience within the organization. The grouping of these documents forms the concept of an information security policy framework. In some embodiments, this framework may include a unique indexing for each document according to the organization's standards. The documents may be maintained in a common repository and have an ability to be located by a control identifier, control family, document number, or a similar unique identifier. In some embodiments, the following steps may be implemented in order to develop policies, standards, and/or procedures. Practitioners will appreciate that the specific steps are presented for description only, and do not limit the scope of the invention.
The DOE has published a set of guidelines known as the “Electricity Sector Cybersecurity Risk Management Process Guideline,” dated September 2011. The DOE guidelines define “risk” as a function of threats, vulnerabilities, impacts, and likelihood. According to the DOE, these risks should then be managed according to three tiers, Organization, Business Process, and Information Technology/Industrial Control Systems.
Under the DOE guidelines, each business capability 102, and/or one of its components, would then have a classification to indicate whether it should be considered as an industrial control system or general IT and desktop. This information may also be considered when framing the risk of a particular component or its business capability 102.
In some embodiments, the framing of the risk and the development of the Risk Index associated with a given system, is accomplished by considering the risks associated with system components. Each system component may be vulnerable or exposed to a variety of potentially damaging scenarios. As such, each of these scenarios 110 may be evaluated for groups of components, a score being computed for each scenario 110. A group of components may consist of a single component depending on the action of the scenario 110.
Over time, as each new set of risk/threat scenarios, vulnerabilities findings, state of controls, and impact/likelihood changes, the risk profile may be updated using the new risk score associated with that scenario 110.
The Risk Management Framework 100 is compliant with the tenants of the DOE guidelines and calculates a Risk Index 104 as the maximum risk score for a business capabilities components where:
Risk Index 104=Impact*Likelihood/(Control)Maturity for a given scenario 110.
It is important to note that the use of control maturity in a risk formula results in a risk score for residual risk. As such, the Risk Index 104 is a measure of residual risk. It mitigates the native risk, which is provided by the framing of the risk with impact and likelihood, by using a measure of the maturity of the controls and recoverability of a given component. The exposing of such a measure permits an organization to more effectively apply its financial and human resources based on the maturity level of its organization.
Those of ordinary skill in the art will appreciate that the precise calculation used in determining a risk score may vary without departing from the scope of the invention. It should be further appreciated that there are likely multiple methods, in addition to what is disclosed herein, for calculating a set of variables to derive a meaningful outcome without deviating from the methodologies described herein. The Risk Management Framework 100 may employ calculations having greater or fewer variables, constants, weighting values, and the like, which are used to create a desired outcome in accordance with the methodologies disclosed herein. For example, a more complex calculation that may be implemented within the Risk Management Framework 100 in accordance with some embodiments is as follows:
As used herein, likelihood is a product of three factors: 1) threats; 2) imminence of threat; and 3) the targeting likelihood of the component under consideration. In some embodiments, its range of values is from 0.002 to 360. Threats may be scored as a sum of the measure reflecting the number of types of adversaries, and the highest level of capability and intent of adversaries, with a value from 0.02 to 12.
The scoring of imminence recognizes it as an accelerator of the risk level. Imminence provides an ability to capture changing capabilities and intentions that are often viewed in cyber security relative to how they would impact the organization today, at this point in time. These risk vectors often result from changes in an organization's business model that impacts its employees and customers and the gradual emergence of technologies designed to penetrate existing deployed controls.
A final element of the organization's risk calculation is maturity. This is a measure of the effectiveness of the mitigation/controls for a given component or group of components. In some embodiments, it is scored as a weighted average of the effectiveness (%) for each type of control: preventive, detective, or corrective controls and the recoverability of the particular system component or group of component. In some embodiments, the initial weights are 30 for each of the recoverability and preventive scores and 20 for the corrective and detective scores. However, practitioners will appreciate that the specific weights presented herein are for description only and do not limit the scope of the invention.
To determine the maturity of a group of components, the lowest maturity effectiveness for the components may be the one used in the risk score calculation as this represents the highest risk. In some embodiments, the calculation for the development of the maturity value includes a control by control assessment (i.e., Yes/No) as to whether the applied control activities meet the control objectives. In the Risk Management Framework 100, these controls may have been originally developed through the Organizational Control Framework 500 and then tested or audited through any appropriate means. This linkage provides the ability to independently assess and report on an organization based on the maturity of a particular control or family of controls.
In some embodiments, the range of scores for the Risk Index 104 effectively ranges from 0 to 4680. As these numbers are not immediately intuitive in a risk management arena, it is typical to normalize these scores into tiers, High, Medium, and Low. In some embodiments, this may be accomplished using empirical methods with the calibration of the generated score against the organizationally accepted level of risk for that scenario 110. In lieu of this data, the following tiers are suggested as the starting point.
In some embodiments, the development and evaluation of a full library of scenario 110s and the evolution of the scoring formats described above will require that this normalization scheme be revisited and evolved over time. As the scoring formats change it may be optimal to migrate previous risk scores into the new format, both as a control and also as to maintain the integrity of mitigation expenditures and effort based on the previous risk scores.
This data continues to require the development of a library of scenario 110s and their scoring. However, it does provide an effective manner for evaluating the capability of an organization's ability to respond to all threats. With this form of analysis assignment of organizational responsibility (accountability) and division of resources is easily accomplished.
In some embodiments, the principle of a “high water mark” for risk may indicate that efforts to reduce risk for incoming components may not be beneficial due to the addition of such an element to the ‘pool’ not significantly altering the Enterprise Risk Index (2700).
While some embodiments can be implemented in fully functioning computers and computer systems, various embodiments are capable of being distributed as a computing product in a variety of forms and are capable of being applied regardless of the particular type of machine or computer-readable media used to actually effect the distribution.
At least some aspects disclosed can be embodied, at least in part, in software. That is, the techniques may be carried out in a computer system as shown in
Routines executed to implement the embodiments may be implemented as part of an operating system or a specific application, component, program, object, module or sequence of instructions referred to as “computer programs.” The computer programs typically include one or more instructions set at various times in various memory and storage devices in a computer, and that, when read and executed by one or more processors in a computer, cause the computer to perform operations necessary to execute elements involving the various aspects.
A machine readable medium can be used to store software and data which when executed by a data processing system causes the system to perform various methods. The executable software and data may be stored in various places including for example ROM, volatile RAM, non-volatile memory and/or cache. Portions of this software and/or data may be stored in any one of these storage devices. Further, the data and instructions can be obtained from centralized servers or peer to peer networks. Different portions of the data and instructions can be obtained from different centralized servers and/or peer to peer networks at different times and in different communication sessions or in a same communication session. The data and instructions can be obtained in entirety prior to the execution of the applications. Alternatively, portions of the data and instructions can be obtained dynamically, just in time, when needed for execution. Thus, it is not required that the data and instructions be on a machine readable medium in entirety at a particular instance of time.
Examples of computer-readable media include but are not limited to recordable and non-recordable type media such as volatile and non-volatile memory devices, read only memory (ROM), random access memory (RAM), flash memory devices, floppy and other removable disks, magnetic disk storage media, optical storage media (e.g., Compact Disk Read-Only Memory (CD ROMS), Digital Versatile Disks (DVDs), etc.), among others. The computer-readable media may store the instructions.
The instructions may also be embodied in digital and analog communication links for electrical, optical, acoustical or other forms of propagated signals, such as carrier waves, infrared signals, digital signals, etc. However, propagated signals, such as carrier waves, infrared signals, digital signals, etc. are not tangible machine readable medium and are not configured to store instructions.
In general, a machine readable medium includes any apparatus that provides (i.e., stores and/or transmits) information in a form accessible by a machine (e.g., a computer, network device, personal digital assistant, manufacturing tool, any device with a set of one or more processors, etc.).
In various embodiments, hardwired circuitry may be used in combination with software instructions to implement the techniques. Thus, the techniques are neither limited to any specific combination of hardware circuitry and software nor to any particular source for the instructions executed by the data processing system.
It will be appreciated by those skilled in the art that while the invention has been described above in connection with particular embodiments and examples, the invention is not necessarily so limited, and that numerous other embodiments, examples, uses, modifications and departures from the embodiments, examples and uses are intended to be encompassed by the invention.
This application claims priority under 35 U.S.C. §119 to U.S. Provisional Patent Application No. 61/610,248 filed on Mar. 13, 2012, the entire contents of which are incorporated herein by reference.
| Number | Date | Country | |
|---|---|---|---|
| 61610248 | Mar 2012 | US |
