Understanding Information Security Management Systems
What Is an Information Security Management System?
Definitions
Information security: Preservation of confidentiality, integrity and availability of information.
Management system: Coordinated activities to direct and control an organization.
Information Security Management System (ISMS): Coordinated activities to direct and control the preservation of confidentiality, integrity, and availability of information
History and Background
The current process based approach to management systems is derived from the work of W. Edwards Demming and the world of Total Quality Management (TQM). His holistic and process based approach to the manufacturing sector was initially ignored, and eventually embraced after the rapid rise in quality of Japanese products in the 1960s. Although initially viewed as relevant only to a production line environment, the concepts have since been successfully applied to many other environments.
Concept
ISMS is an example of applying the management system conceptual model to the discipline of Information Security. Unique attributes to this instance of a management system include:
- Risk management applied to information and based upon metrics of confidentiality, integrity, and availability
- TQM applied to information security processes and based upon metrics of efficiency and effectiveness.
- A monitoring and reporting model based upon abstraction layers that filter and aggregate operational details for management presentation.
- A structured approach towards integrating people, process, and technology to furnish enterprise information security services.
- An extensible framework from which to manage information security compliance.
Why Is an ISMS Beneficial
On the surface, ISMS may appear to be a paperwork exercise. While this may be true, the benefit of ISMS far outweighs the resultant documentation. Of equal or greater value is the resultant thought process, awareness, and informed choice decision making.
Defensible
The structure inherent to an ISMS shows clear direction and authorization. Executive management direction is linked to operational detail. Details are derived from documented informed choice decision making. Measuring and monitoring ensure reasonable awareness of the information security environment. This documented due diligence provides a defensible posture.
A standards-based ISMS, allows extra defensibility through third party validation such as certification to the ISO27001 Information Security Management standard. This defensibility works whether a consumer or source of information. Choosing to do business with an externally validated partner is a defensible decision.
Differentiator
An ISMS may serve as a market differentiator, as well as serve to enhance perception and image. Marketing your information services to external information sharing partners or clients requires a degree of confidence from all parties. The extra effort of information security certification makes their decision defensible.
Business Enabler
An ISMS may serve as an umbrella to cover several regulatory components simultaneously. Most relevant regulations deal with very specific data types such as health or financial information. Controls deployed for one regulation, and managed by an overarching or blanket ISMS typically meet the requirements of multiple regulations simultaneously. Most legal regulations also require demonstrable management of information security, something inherent in an ISMS. The potential legal and regulatory cost savings of an overarching ISMS is obvious.
An ISMS allows for, and generally is based upon, risk. Risk analysis and risk rating may serve as a fundamental justification for the selection and deployment of controls that populate the ISMS. A risk-based ISMS, such as required by the ISO 27001 standard, allow for business to accept risk based upon informed choice decision making. This ability to accept risk enables businesses to react to their environment, not someone elses interpretation of their environment.
A standards-based ISMS offers the basis for enhanced interoperability with information trading partners. The ISMS framework eases interfacing and is extensible to absorb future expansion or change. Standardized terminology facilitates communication.
Structure
An ISMS brings structure to the information security program. With clear direction and authorization, roles are understood. Defined functions or services allow derivation of tasks that can be delegated. Metrics can be collected and analyzed, producing feedback for "continuous process improvement."
In many situations, creation of an information security management system inspires and spawns complementary management systems in other disciplines such as human resources, physical security, business continuity, and more. The framework and management system principles transcend disciplines, and tend to enhance multi-disciplinary interoperation.
Who Participates in an ISMS
An ISMS transcends an organization from the board room to the data center. There are typically three organizational layers with three very distinct audiences.
Board
The board of directors typically provide the organizational vision and guiding principles in response to managing risk on multiple fronts, from regulatory compliance to fiduciary responsibility. The board of directors participates in the ISMS through empowerment. This empowerment or authorization is a strategic control in response to risks such as regulatory non-compliance and fiduciary irresponsibility.
Executive Staff
Senior executives are the typical owners of programs that would be managed by a management system. Management systems enhance an organizations horizontal and vertical integration and visibility. Senior executives participate in the ISMS through definition and provision of services provided to the enterprise by the program, such as incident management.
Management
Directors manage the tactics required to provide the program services. In a process-based ISMS, program services are provided by a collection of complimentary and integrated processes. Directors participate in the ISMS through the definition, execution, and ongoing improvement of these relevant information security processes such as contain, eradicate, restore.
Operations
Managers implement the program on an operational level. The ISMS will generate standardized methodologies and requirements, codified in organizational process and standards. Managers participate in the ISMS through integration of people, procedure, and technology in response to these organizational directives.
Where Does an ISMS Live?
An ISMS lives within an organization from the board room to the production floor, each strata addressing a different need.
Enterprise
At the enterprise level the ISMS lives in the form of a minimum enterprise information security baseline created in direct response to the enterprise information security risk addressed by upper management. The enterprise information security baseline, typically consists of enterprise information security standards, processes, and roles and responsibilities. Risk acceptance for non-conformance to the information security baseline has enterprise wide information security significance.
Information Security Domains
At the operational level, an ISMS lives in multiple places and instances, based upon functional areas, or information security domains. A typical information security domain may be a data center, office area, or reception area, each with a unique security profile. Information security domains serve as the basis for enterprise information security baseline implementation. Each domain is autonomous in how they tailor the enterprise information security baseline requirements to their unique environment.
How Is an ISMS Built?
An ISMS is typically risk based, and process oriented. There may be multiple layers of abstraction to accommodate the distinct audiences whose concerns must be addressed. The ISO 27001 standard recommends a Plan-Do-Check-Act (PDCA) process-based approach defined as:
- Plan: Establish the ISMS
- Understand the environment
- Assess enterprise risk
- Charter information security program
- Assess program risk
- Do: Implement and operate the ISMS
- Create enterprise information security baseline
- Create domain specific implementations
- Check: Monitor and review the ISMS
- Act: Maintain and improve the ISMS
Understand Environment
The structure and the content of the ISMS must take into account the management environment in order to be successful. Organizational considerations will influence the ISMS framework. Cultural sensitivities may change usage of terminology. Regulatory requirements will certainly influence approach, contents, and packaging.
Assess Enterprise Risk
Enterprise risk is usually assessed and addressed through upper management directives such as corporate policies. The assessment of high level enterprise risk, such as regulatory compliance and fiduciary responsibility is inherently understood and intuitively addressed. Upper management directive serves as the authorization and empowerment of the supporting enterprise risk mitigating programs.
For example:
- A corporate behavioral or acceptable use policy empowers proactive behavioral training as well as reactive behavioral detection mechanisms.
- Corporate administrative policy empowers efficiency initiatives supported by operational metrics and continuous process improvement.
- Corporate legal and regulatory policy establishes non-negotiable requirements embedded as controls within the ISMS.
Charter Information Security Program
The Information Security Program is the organizational entity authorized and empowered to create and maintain the ISMS in order to offer the enterprise the services required to meet corporate policy goals. The information security program not only offers services, but also requires externally provided services to maintain program effectiveness. An example program dependency may be a human resource department that performs background checks for the information security program. A program charter may serve as a vehicle to document the authorization and empowerment, as well as document and acknowledge the mutually recognized program dependencies.
Assess Program Risk
Program risk serves as the basis to select controls managed by the ISMS. Some program risk has been analyzed and addressed by others that believe they know the practitioners environment better than the practitioner, resulting in binding regulations. Some program risk is obvious and intuitive, such as the risk of unpatched information processing systems. Other program risk is more insidious, such as aggregation when individual inconsequential risks combine to produce risk disproportionate to the sum. For example,
- There is no firewall between Department A and Department B. This is rated a minor risk and has been accepted by both departments.
- Department B then deploys a webserver. The risk of opening HTTP port 80 through the Department B external (Internet facing) firewall is deemed a minor risk and has been accepted by Department B.
- Department As previously isolated network segment is now no longer isolated.
- A minor risk accepted by Department B caused an unknown risk acceptance by Department A. There is now an unrecognized major enterprise risk.
An ISMS serves as the vehicle to coordinate the management of risk and risk mitigating controls. Identified risks are quantified, and control objectives assigned. Control objectives serve as the glue that justifies and binds each risk to its respective control. The satisfaction of control objectives is prioritized by the risk quantification.
Create Enterprise Information Security Baseline
An enterprise information security baseline serves as a common minimum information security posture for the enterprise. This in turn serves as the basis for trust between operational areas or domains since they all are required to meet this minimum baseline, which may be exceeded as required.
Directives
Directives are controls that define hard and measurable requirements. Directives may be derived from legislation, industry standards and practices, or in response to risk. Directive controls are typically codified in a suite of standards, with the content based upon informed choice decision making. Care must be taken in the crafting of the directives because informed choice decision making implies a degree of risk acceptance. That which is not addressed is by default accepted.
Methodologies
Methodologies are controls that define measurable and repeatable processes. Methodologies may be derived to meet the requirements of directives, or may be part of a suite of processes that provide a program service. Methodologies are typically codified as a process flow. Care must be taken in crafting processes flows to ensure that the process can be measured and monitored. That which cannot be measured cannot be improved.
Responsibilities
Clear assignment of responsibilities is a control that binds a role to an activity. Activities may be derived to meet the requirements of directives, and may be performed by executing a methodology. Responsibilities are typically codified via functional role definitions. Care must be taken when defining functional roles to ensure that role assigned responsibilities are supported by role required authorizations and qualifications. Those assigned responsibility must have the requisite authorization, qualifications, and resources.
Create Domain Specific Implementations
Specifications
Specifications are domain specific operational controls that define hard and measurable details such as configurations or attributes. Specifications are derived from enterprise information security standards, with each domain potentially deriving unique interpretations to a common standard, dependent on each unique environment. This allows a degree of autonomy in execution. Care must be taken when deriving specifications to ensure domain specific interpretations, while meeting the spirit and intent of the parent standards, do not cause inter-domain incompatibility. To preclude introduction of unidentified risk, specifications must meet the spirit and intent of the parent standard.
Procedures
Standard Operating Procedures are controls that define measurable and repeatable work instructions. Standard operating procedures are derived from enterprise information security processes with each domain potentially deriving unique interpretations dependent on each unique environment. This allows a degree of autonomy in execution. Care must be taken in deriving Standard Operating Procedures to ensure parent process attributes are preserved. The execution of domain Standard Operating Procedures is the basis of enterprise information security services.
Tasks
Tasks are activities assigned a functional role executing a Standard Operating Procedure. Tasks are domain specific and schedule driven, with frequency of execution based upon risk. Individuals executing tasks while filling a role are performing their employment duties. Performance of duty is an employee metric. Care must be taken when scheduling tasks and assigning duties to ensure the schedule is defensible, and the individual competent. Tasking is an employee performance metric.
Assess Operational Risk
Operational risk is based upon the risk that a domain will not be able to meet its enterprise information security baseline derived obligations, such as specifications, procedures, and scheduled tasks. This risk is many times resource driven, putting a risk justification to budgeting. Acceptance of operational risk may change residual program risk and aggregation may cause this program risk to rise to an unacceptable level.
Measure and Monitor
Measuring and monitoring is the feedback mechanism required for continuous process improvement. What to monitor and how to measure requires well defined metrics. Typical domains will obtain multiple varieties of metrics.
Environmental Metrics
Environmental metrics are based upon the surroundings. The focus is on identifying the enterprises risk profile. Industry groups are a consideration. Banking and financial services may, for example, attract highly motivated attackers. Level of organizational sophistication may influence the risk level. An ISO 27001 certified domain may, for example, have a perceived lower risk level. Location may become a factor influenced by crime rates or fire response times. Risk profiles affect probability. This can be utilized to influence risk ratings in the vulnerability management process. For example, the probability of a specific vulnerability being exploited at a bank is perhaps higher than at a home user site because of attacker motivation and targeting. Consideration should be taken to weighting risk and response based upon these environmental metrics. Another focus for environmental metrics is to establish an information security frame of reference or threshold. Intrusion sensors for example utilize environmental metrics to establish detection noise baselines and thresholds.
Program Metrics
Program metrics are based upon effectiveness. The focus is on validating that the ISMS is successfully providing the services that justify its existence. Consider Vulnerability management. This ISMS service measures effectiveness, for example, not by how rapidly a vulnerability can be identified and processed (efficiency). Vulnerability management effectiveness is measured by how many vulnerabilities were never identified or fully processed.
Process Metrics
Process metrics are based upon efficiency. The focus is on fine-tuning procedures to maximize performance. Consider a vulnerability tracking process. The acquisition of new software may, for example, decrease a "time to resolve," improving an efficiency metric.
When Does an ISMS Protect?
An ISMS protects by degrees.
| Responsibility | Owner | Focus |
| Degree of Assurance | Program management | Program risk |
| Degree of Maturity | ISMS management | ISMS process |
| Degree of Implementation | Project management | People, procedure, and technology |
Degree of Assurance
In a risk based ISMS, the Risk Assessment process is an integral part of the feedback loop that provides continuous process improvement. Since risk can never be completely eliminated, a compromise is sought where residual risk has been reduced to an acceptable level. This is known as degree of assurance. The information security program is a risk management tool. From the program perspective, the ISMS protects when risk has been reduced to an acceptable level.
The important question is how to define this "acceptable level" threshold. Degree of assurance implies a level of risk acceptance, but risk may be scattered throughout the ISMS. This may preclude a straightforward assignment of risk acceptance authorization. An ISMS by nature of its structure recognizes the need to delegate risk acceptance, as well as take into consideration aggregate risk.
Degree of Maturity
A process based ISMS is conducive to maturity modeling, since processes by definition should produce feedback metrics that enhance the maturation of the process. Maturity modeling scales, such as seen in the Capability Maturity Modeling (CMM) schemas and others, serve as a common language with consistent definition of scale. The desired degree of maturity is hence bound to the maturity scale selected, as well as to the specific process under evaluation. A defensible degree of maturity is based upon informed choice. Processes may vary in their acceptable degree of maturity, dependent on external factors such as risk. Nevertheless, the ISMS protects as ISMS processes reach the desired degree of maturity.
Degree of Implementation
Degree of Implementation is tied to operations and project management. Information security projects at the operational level are tied to specific operational areas, or security domains. These projects deploy domain specific controls in response to domain specific risk, aggregating to raise the enterprise degree of assurance. Upon project completion, Degree of Implementation is complete, and the control is now bound to degree of maturity. The ISMS protects as people, procedure, and product integrate into process.
Summary
The management system concept is being applied across many new disciplines. With the ratification of the ISO27001 standard, information security management systems have achieved new prominence, in some arenas becoming a defacto requirement.
In conclusion, an ISMS:
- Integrates information security risk into enterprise risk management.
- Documents informed choice decision making and due diligence.
- Provides a framework for regulatory compliance.
- Offers a structure to efficiently and effectively integrate people, process, and technology.
- Furnishes a mechanism for monitoring and reporting.
- Is business friendly, and a market differentiator.
About the Author
Tom Carlson is a certified ISO 27001 auditor and a recognized expert on information security standards and programs. His background spans diverse environments including national security, academia, private enterprise, and Antarctic research, encompassing design, development, deployment, operations, and knowledge transfer. Through his career, Tom has worked with multiple government agencies on a variety of mission critical projects, as well as security solutions for the private sector. His area of expertise is in Information Security Management Systems and Risk Management. Tom holds a B.S. in Electrical Engineering, as well as various education and industry certifications.
From Information Security Management Handbook, Sixth Edition, Volume 2, edited by Harold F. Tipton and Micki Krause. New York: Auerbach Publications, 2008.
 |
|
|
