All businesses have processes for their operations. These can be production, sales, support, IT, procurement, auditing, and so on.
All businesses also need risk management. Traditional risk management has focused on financial risks, as well as HSE risks. These governance activities are also legal requirements in most countries. Recently cybersecurity has also caught mainstream attention, thanks to heavy (and often exaggerated) media coverage of breaches. Cyber threats are a real risk amplifier for any data centric business. Therefore it needs to be dealt with as part of risk management. In many businesses this is, however, still not the case, as discussed in detail in this excellent Forbes article.
One common mistake many business leaders make is to view cybersecurity as an IT issue alone. Obviously, IT plays a big role here but the whole organization must pull the load together.
Another mistake a leader can make is to view security as a “set and forget” thing. It is unlikely that this would be the case for HSE risks, and even less so for financial risks.
The key to operating with a reasonable risk level is to embed risk management in all business processes. This includes activities such as:
Identify and evaluate risks to the business related to the business process in question
Design controls where appropriate. Evaluate controls up against other business objectives as well as security
Get your people processes right (e.g. roles and responsibilities, hiring, firing, training, leadership, performance management)
What does the security aware organization look like?
Boiling this down to practice, what would some key characteristics of a business that has successfully embedded security in their operations?
Cybersecurity would be a standard part of the agenda for board meetings. The directors would review security governance together with other governance issues, and also think about how security can be a growth enhancer for the business in the markets they are operating.
Procurement considers security when selecting suppliers. They identify cybersecurity threats together with other supply chain risks and act accordingly. They ensure baseline requirements are included in the assessment.
The CISO does not report to the head of IT. The CISO should report directly to the CEO and be regularly involved in strategic business decisions within all aspects of operations.
The company has an internal auditing system that includes cybersecurity. It has based its security governance on an established framework and created standardized ways of measuring compliance, ranging from automated audits of IT system logs to employee surveys and policy compliance audits.
Human resources is seen as a key department for security management. Not only are they involved in designing role requirements, performance management tools and training materials but they are heavily involved in helping leaders build a security aware culture in the company. HR should also be a key resource for evaluating M&A activites when it comes to cultural fit, including cybersecurity culture.
Maintaining security is an ongoing process which requires coordinated effort by the whole organization. Without backing from the top management levels and buy-in through the ranks there is little chance of building up resilience against cyber attacks. As organization complexity increases and value creation becomes distributed it will be necessary to have an integrated approach to security; your company needs an information security management system. ISO 27001 is an international standard that sets requirements to such as system based on what has been internationally recognized as best practice.
ISO 27001 [external link] is a management system standard that follows many of the same principles as other ISO standards such as ISO 9001 for quality management. Assuming that the client has a ISO 9001 compliant system in place, the information security management system should be built on the existing processes and workflows. This means that existing auditing systems and reporting requirements should be appended, rather than building everything from scratch.
The following are key elements of information security management system establishment. First we look at the activities that need to be performed in the order of appearance of requirements in ISO 27001. Afterwards, we summarize the bare minimum that you will have to do in a table.
Under which regulatory regimes does the organization operate?
Who are the main threat actors based on the external context? (Script kiddies, hacktivists, cyber criminals, nation states, etc.)
Internal stakeholder definitions
Who are the system owners?
Who are the system users?
Which process owners depend the most on the information assets?
Who are responsible for maintaining security?
Identify main information assets
What are the critical information objects?
Why are they critical in the context of operations?
Are there assets that require security due to external stakeholder situations (legal or commercial requirements, or due to risk drivers)
The most efficient approach for this type of context development is a working meeting with the organization’s top management where these key issues are identified.
Policy development and leadership
(ISO 27001 Section 5)
Top management must be involved in policy development, and promote its integration in the overall management system of the organization
A policy should be developed and be sanctioned and signed by top management. The policy shall include the following:
Should commit the organization to compliance with infosec requirements, and to continuous improvement. It should therefore refer to the organizations existing systems for compliance measurement and continuous improvement processes, as well as to internal information security standards with more practical requirements.
The policy shall be documented and made available and communicated to all users
Top management shall assign responsibility and authority for follow-up of information security, and for reporting to top management. In most organizations a single role is recommended for this, and a person competent in both the organization’s core activity and in information security principles should take this role. In most commercial organizations this role is designated as CISO.
Policy objectives should conform to the requirements of Clause 6.3 of ISO 27001. In order to identify these goals when building a new system it is recommended to write the policy after an initial risk and vulnerability assessment has been performed.
Recommended practice is to develop the policy in cooperation with the assigned CISO (if existing at this point). A policy document should be written and discussed with top management before it is updated. The policy should be dated, and an expiry date should be set in order to guarantee regular reviews (this is not an ISO 27001 requirement but is considered good practice for security critical process documents).
Information security risk management planning
(ISO 27001 Section 6)
Define a process for information security risk assessment. The recommended elements of this process:
Requirements to documentation of [USERS, HARDWARE, SOFTWARE, NETWORKS]
Requirements to performing risk assessments
Risk acceptance criteria. It is recommended to keep this at a coarse level and use qualitative descriptors
HAZID-type risk identification (use of guidewords)
Control planning methodology (ref. to Annex A of ISO 27001)
Perform a risk assessment for all applicable systems (Scope definition à HAZID à Risk ranking à Risk treatment planning)
Produce a statement of applicability for the controls in Annex A of ISO 27001
Formulate infosec objectives (ref policy development). These objectives should be measurable, or at least possible to evaluate with respect to performance. The objectives should align well with the overall criticality of the information assets (ref. risk context). Annex A of ISO 27001 is a good guidance point for developing objectives. Also, the organization should not choose objectives that are inconsistent with the maturity and capabilities of the organization.
The risk assessment procedure should be written in a practical way, such that the organization can apply it with the available resources. It should include examples of format for reporting, and also the recommended guidewords/threat descriptors.
A key difficulty for infosec risk assessments is the risk ranking. There are several ways this has been approached, varying from using “complexity of attack vector” as an proxy for probability and generic ratings for impact, to context related impact assessments in operationally relevant categories such as revenue loss, legal and litigation consequences, or reputation loss. The probability dimension can also be treated using aggressor profiling techniques, which is recommended for sophisticated organizations with a good understanding of the threat landscape. You can read more about that technique in this blog post from 2015: https://safecontrols.blog/2015/09/08/profiling-of-hackers-presented-at-esrel-2015/
(ISO 27001 Section 7)
The organization must perform a competence requirements mapping with respect to infosec for the various roles in the organization. This work should be performed in cooperation with the organization’s HR department, and set verifiable requirements for groups of employees. Responsibility for following up this type of competence should be given, preferably to the HR director or similar. Typical employee groups would be:
HR and middle management
Information system users
Specific roles (CISO, internal auditor, etc.)
The organization must develop an awareness program. The awareness program should as a minimum include:
Making employees aware of the policy
Why complying with the policy and the procedures is necessary and beneficial
Implications of non-compliance (up to and including employee termination and criminal charges in serious circumstances, depending on local legislation)
Information security aspects should be included in the communication plans for both internal and external communication.
For document control and similar processes, it is assumed that the organization has an appropriate system. If not, see ISO 27001 Section 7, Clause 7.5.3, as well as ISO 9001 requirements).
The awareness program should be made the responsibility of either the CISO or the training manager /HR. These departments must cooperate on this issue.
The communication plan for information security can be integrated in other communication plans but shall be approved by the CISO. It is recommended to develop a specific plan for information security that other communication plans can refer to. This is especially relevant for communications during incident handling, which may require tight stakeholder cooperation and maintaining good public relations and media contacts.
Operations and Performance Monitoring
(ISO 27001 Section 8-9)
The organization must implement and document the performance of the risk mitigating controls. A lot of the proof can be extracted from data from technological barrier functions, whereas other measures may be necessary to document organizational controls.
Information security aspects should be included in the organizations change management procedures (ref. ISO 9001 requirements)
Information security monitoring should be implemented based on control and objectives
Information security auditing should be included in the internal auditing program. It is recommended to build up on the existing system, and to include requirements to competence for the subject matter expert assisting the head auditor (ref. back to competence management and HR processes). Some extra reading about auditing and what it is good for can be found here, but for the context of reliability engineering. It should be equally applicable in the context of cybersecurity: Why functional safety audits are useful
Include infosec in management review. In particular ensure efficient reporting on infosec objectives. It is recommended to create a simple and standardized reporting format (e.g. a dashboard) for this use.
(ISO 27001 Section 10)
Include infosec into the existing non-conformance system
Assign CISO as owner of infosec related deviations
Activity summary and sequence
Building a management system requires multiple activities that have interdependencies, as well as dependencies on other management system artifacts. The following sequence is a suggested path to developing an information security management system from scratch in a robust organization.
Note that it should be expected that some iterations will be needed, especially on:
Policy and objectives
Risk assessment procedure and risk and vulnerability study (the procedure is updated based on experience with the method)
Objectives and measurements will need to be reviewed and updated based on experience
Note also that a consultant has been included in the “People” category. For organizations that do not have sufficient in-house competence in management system development it can be beneficial to contract a knowledgeable consultant to help with the project. For organizations with sufficient in-house capacity this is not necessary, and it is not a requirement for compliance with ISO 27001.
Customers/users, organization charts, suppliers, partner lists, etc.
Information in technical note on Context: stakeholders. Should include who, why, what and how with respect to the information security risk.
Network topologies, asset lists, document systems
Prioritized inventory description as section in technical note on Context.
Threat actor assessment
Outputs from previous activities.
News and general media. Experience from previous incidents.
Open security assessments from police and intelligence communities.
List of threat actor categories with descriptions of motivations and capabilities.
Risk procedure development
Risk assessment procedure document
Scope definition for risk assessment
Context note with inventory.
Topology drawings. Organization charts. Use cases.
Use of guidewords for each scope node, ref risk assessment procedure.
Risk identification table (HAZID table)
Mitigation planning (including ISO 27001 Annex A review)
HAZID table with risk ranking.
List of actions and controls to be evaluated or implemented.
HAZID table and risk mitigation results.
Risk and vulnerability report.
Statement of applicability
Review each control in Annex A
Context note. Risk and vulnarbility report.
Statement of applicability (report)
Suggest objectives based on previous activities and maturity of the organization
Risk assessment, context, statement of applicability
Information security objectives, including measurement and review requirements in technical note or procedure.
Review of objectives with key stakeholders
Revised objective note.
Develop draft policy for information security.
Objectives, statement of applicability, risk and vulnerability report, context, policy templates.
Review draft policy in meeting with top management. Top leadership needs to be involved and take ownership, headed by the CISO.
HR Integration: competence management
Develop competence requirements for roles
Updated competence requirements in role descriptions
Develop awareness program, tailored to competence requirements of groups.
Updated role descriptions
Awareness program plan
Internal auditing requirements
Update internal auditing requirements
Infosec policy and procedures, objectives
Updated audit plans and competence requirements for subject matter expert
Update change management system and management’s annual review reporting requirements
Infosec policy and objectives
Updated change management procedure
Updated reporting format to top management.
CISO (recommend that this is done internally unless consultant’s assistance is needed)
After the management system has been established, it is recommended to perform an internal requirements audit to identify gaps.
After the system has been in operation for 6 months an internal security audit with focus on evidence of use is recommended.
Summing up what you just read
You have determined your company needs a security management system. This blog post gives you a blueprint for building one from scratch. Keep in mind that the system with its processes, governing documents and role descriptions only provide a framework to work within. Key to getting value from this process is starting to use the system.
Building a management system from scratch is a big undertaking, and for many companies it makes more sense to do it piece by piece. Start with a minimum solution, start using it, and improve on the processes and documents based on your experience. That is much better than trying to build the system to be fully compliant from day 1 – and you will start to see real benefits much sooner.