The ISMS Governance Strategy

Briefly, governance is the work of a cross-functional team that manages the IT security program for an organization in a continuous process of analysis and actions. Governance according to the ISMS approach uses the Deming Cycleof continuous improvement, also known as Plan-Do-Check-Act (PDCA ). The following is the action plan for getting an ISMS off the ground:

1. Establish the ISMS.

   1. Set up an ISMS security steering committee.

   2. Draft a charter defining the steering committee’s roles and responsibilities.

   3. Obtain executive management’s approval of the charter and the security steering committee.

2. Plan. The steering committee commissions an analysis of assets and compliance requirements. It publishes security goals and scope based on these.

3. Do. The steering committee and related stakeholders commissions an analysis of risk and controls. It reviews these in light of the security goals, decides upon risk treatment options, and assigns work to be done based on them.

4. Check. The steering committee commissions an analysis of control effectiveness and appropriateness within the organization against the previously published goals and scope.

5. Act. The steering committee adjusts the risk treatment plans accordingly to ensure that goals are being met. The steering committee then returns to step 2 and begins the Plan phase again to continue refinement and improvement of the security program.

Let’s break each of these down now.

IT Security

Who should be on the ISMS steering committee? You need some obvious members, like the chief security officer (CSO). The CSO will lead the committee and be responsible for setting the agenda and running the meetings. Please note that the CSO is a role that I am using for convenience not necessarily a title. The CSO’s job title could be security manager, information security officer, IT security lead, or even network security potentate. The title isn’t as important as the role, which belongs to the most senior individual in the organization responsible for managing the IT security program.

Other Security Departments

You should also include any other security departments, such as the leads representing the other domains of security outside of IT. For example, you should include someone from either physical security or facilities. If there is a head of business continuity or disaster response, they should be included as well. In smaller offices, business continuity and physical security duties usually fall onto the office manager, who would be an excellent addition to the ISMS committee. Some organizations have a separate department (and requirement) for data privacy, so they should be involved as well.

Leadership

An absolute requirement would be representation from the executive leadership of the organization. Ideally, the higher ranking the better. If you can get someone who represents the organization’s board or the CEO, that would be best. Sometimes you can’t get so lucky, so the CIO or VP of IT may be the best you can get. Whoever this is, their role is to put executive authority behind the committee decisions and to supply the necessary resources (budget and people’s time) to getting things done. Without explicit and concrete executive support, an ISMS will stall before even getting off the ground. Until that happens, all of your efforts will be an academic exercise with little or no real impact to the organization. At the very least, the committee’s work should roll up to the CEO for formal acceptance of risk. The CEO’s job is to ensure the safety of the organization, even if he or she can’t or don’t have time to participate in the day-to-day work committee.

Audit

As part of the Plan-Do-Check-Act , you should have a representative from the Check phase of the cycle. This means an internal auditor on the committee, or at least an occasional report to the committee from the external auditors. They provide an independent assessment of the progress towards the ISMS goals. As members of the committee, not only could they provide direct feedback on control shortcomings, but they can also provide insight into the design of security program metrics to measure and track effectiveness. Note that if you are doing an ISO 27001 audit, you are required to have an internal audit role within your organization. Chapter 22 is entirely focused on internal audit.

Specialized Departmental Roles

Other appropriate organizational experts should be part of the ISMS committee. You’d want to have someone from the legal team to weigh in on proposed policies as well as to navigate the complex shoals of liability that can arise from IT risk. The legal team can also act as an authority on compliance regulations and contractual issues involving IT. Since IT risk translates to financial risk (as well as financial expenditures), a representative from finance is a strong addition. With so many security policies involving how staff perform their job, a member from the human resources department is another key role. HR becomes especially important when security policy violations involve employee disciplinary measures, as well as IT security initiatives that touch employee privacy.

IT

Since we are talking about IT security, you will want at least one person from the IT department on the committee. Some organizations are large or tech-oriented enough that there may be several different groups of IT personnel . So maybe you’d want one person each from software development, IT operations, the help desk, and projects. Or perhaps you don’t want to load up your committee with techies, so you could have one person who could represent all of those teams, such as the IT director. It all depends on your organization and its culture.

Major Departmental Heads

The ISMS committee should have representative from a cross-section of business within the organization. These are the department heads who represent the important business processes and user communities that are affected and protected by the ISMS. In larger organizations, these department heads are likely already meeting for other reasons. In that case, you could use that forum as an opportunity to get their feedback and opinion on risk matters. These department heads act as system owners, weighing in on decisions and analyses tied to the daily business of the organization. Without them on the committee, you risk doing things in a vacuum and failing to engage user’s support. As my old boss used to say, without input from the business, your security program will be like throwing sod down on cement and expecting it to grow.

ISMS Committee Guests

In addition to the standing membership, the ISMS committee could benefit from occasional guest members or speakers. These members can come both inside and outside the organization.

Inside the organization, you can include other department heads not formally in the ISMS committee. Perhaps these departments don’t even have a strong IT presence within the organization, but could still provide some new insights or warnings. This could include marketing, sales, customer service, manufacturing, academics, research, transportation, or even the cafeteria. You could also look at asking one of your standing department heads to bring in a representative from one of their underlying sub-departments. For example, facilities could bring someone from janitorial to talk about what goes on after dark. The IT help desk could bring in a support phone tech to talk about how they do password resets over the phone. The idea is to keep the ISMS fresh with new ideas and leave no stone unturned when it comes to possible internal risk.

External expertise is also valuable to the ISMS committee. If an ISMS is just starting out and all the participants are new the process, then having a security consultant on the committee would be extremely beneficial. If there is outside counsel with expertise in areas of the law beyond your in-house knowledge, this person would be a good drop-in member. Subject matter experts could guest lecture on occasional topics as well. This could include key vendors, technical consultants, regulators, and even cyber-cops. I have seen several federal cyber-police agencies willing to go onsite to organizations and provide advice on the protection of critical infrastructure. Do you remember the security organizations that I discussed back in Chapter 1? They are a good source for these kinds of speakers.

Also remember that the ISMS committee is as organic as your security program itself. The membership will ebb and flow, as your organizational and security needs change. It is not a fixed committee but one you can add and change members on over time.

CSO

As we discussed earlier, the CSO is the top security person leading the ISMS committee. This means setting and running the agenda for the meeting, as well as keeping the discussions on topic. As the most knowledgeable expert in IT security in the group, she should also act as teacher and explainer for the rest. The CSO should make sure that the committee reviews critical policy and control project proposals at the appropriate time. Since the CSO is running the ISMS as part of her day-to-day job, she is likely the main point of contact for all ISMS committee business and communication. The CSO also directs the various assessments, including the risk, asset, and compliance analyses. The CSO has the functional responsibility for security, she is charge of directing the IT and security administrators to implement and maintain the controls. The role of CSO is so important that this role should be part of the CSO’s job description. The CSO’s authority is derived from a formal delegation of authority from the head of the organization. This can be direct or indirect via a chain of command, but the ultimately the CSO has been officially tasked with security by the leader of the organization. This authority can be documented in a memo, in the ISMS charter (endorsed by leadership), in their job description, or all of the above.

Asset Owner

The asset owner is the one responsible for the security of their assets. They empower and delegate the task to the CSO to find and reduce risks to their assets and associated business processes. The asset owner provides support and resources for the CSO to do her job. The asset owners are also the ones who help determine the information classification of the data within their systems. If they appear to be making ill-informed or irresponsible choices, the CSO (and perhaps the legal department) needs to educate them on the possible consequences of their decisions.

The ultimate asset owner on the ISMS committee is the leadership role or C-level executive. That role is the asset owner of the entire organization and would have final say on support and resources allocations for the CSO, which is probably no different from their role outside of the ISMS committee. By default, this person is also ultimately responsible for ensuring that risk is kept to minimum acceptable levels and nothing goes horribly wrong. Again, this is probably not different from their role outside the committee. Be aware that there will be struggles with asset owners and security requirements. Asset owners may occasionally resist security control work and operations due to their own priorities. For example, they may not want their systems down for an urgent zero-day patch if they are facing their own deadlines. The ISMS committee forum is one place that these requirements can be resolved. For ideas on how to manage these obstacles, see Chapters 8, 9, and 10.

Asset Custodian

The Custodians are the people who manage and take care of the assets for the owners. Generally, this means the IT operational personnel. Their role is to implement, operate, and maintain the various defined controls that manage risk to the assets. They are responsible for maintaining the control operational records, which auditors may need to review. They must also report any deficiencies or deviations to defined risks, assets, and controls to the CSO so they can be dealt with. Custodians also work ensuring information is maintained according to data classification policies set down by the ISMS committee. Upcoming chapters go into the specifics of how controls can be implemented and maintained.

Asset User

Asset users can refer to anyone in the organization, whether or not they are a member of the ISMS committee. The asset users are anyone who uses the IT assets defined in the scope of the ISMS. They are responsible for exercising due care to protect the assets by following the ISMS defined policies and operational procedures. Upcoming chapters define how asset users are educated on and managed with ISMS rules of conduct.

Auditor

The auditor role is the tester of the ISMS. Their job is to monitor the ISMS and report on deviations and shortcomings of the process. Because they are in a watchdog role, they must be independent and not in the chain of command of any of the ISMS custodians or the CSO. This role is not the same as penetration testers or vulnerability assessors, which are usually hired by the CSO to test for vulnerabilities from outside the organization. Auditors are given full authority to see everything going on within the organization at any time. The trade-off is that auditors are not allowed to implement or maintain controls. They are testers only. This function is described in more detail in Chapters 21 and 22.

Roles and Responsibilities Diagram

The RACI diagram is a helpful tool for managing roles and responsibility. It is a responsibility assignment matrix named after the four commonly assigned duties: Responsible, Accountable, Consulted, and Informed. They are described as follows:

• Responsible: The person(s) assigned to work on this task

• Accountable: The person(s) in trouble if the task isn’t done correctly

• Consulted: The person(s) contributing information to this task

• Informed: The person(s) who need to be updated about the task

Figure 7-1 shows a RACI diagram for the ISMS for the Plan-Do-Check-Act process.

Figure 7-1. RACI diagram for the ISMS for the Plan-Do-Check-Act process

Sample ISMS Charter

Information Security Management System Charter for Puget Regional Bank

The purpose of theInformation Security Management System (ISMS)is to:

• To ensure confidentiality, integrity and availability of sensitive information of Puget Regional Bank, its customers, and business partners

• To ensure management and employee accountability for information resources including assets and information entrusted to them

• To ensure compliance with legal and regulatory requirements

• To eliminate or minimize risk to Puget Regional Bank’s IT resources

• To reinforce Puget Regional Bank’s core ethical values

Sponsorship: The Chief Technology Officer (CTO)

Scope: Puget Regional Banks’s scoped assets

The ISMS Committee: An ISMS committee will be formed to define and lead the ISMS. The ISMS committee will be responsible for:

• Setting goals for security projects and program

• Defining organizational policy regarding IT security based on those goals

• Communicate with leadership and the organization regarding the security goals

• Strive to achieve those goals by defining control objectives for risk treatment

• Measure the effectiveness and performance of the controls and control objectives

The committee will annually review membership and recommend changes after considering the needs for continuity and expertise as well as the need to encourage change and opportunities to participate. The Office of the CTO will provide administrative support.

The current ISMS membership includes:

• IT Security Officer (ISO) - Chair

• Director of IT Services - Co-chair, CTO proxy

• Puget Regional Bank Lead counsel

• Lead Internal Auditor

• Director of Continuity of Operations

• Director of Bank security

• Director of Customer Services

• Director of Remote Customer Services

• Director of Credit Services

• Director of Mortgage

• Director of Collections

• Director of HumanResources

Meetings: The 3rd Tuesday of the first month of the annual quarter. The committee can have emergency meetings if any member calls one

Decision-making: Decisions by consensus of the ISMS committee with disputes taken to the CTO for resolution

Attendance: Regular attendance by ISMS Committee members is mandatory. ISMS Committee members can designate proxies to attend in their stead if unavailable.

ISMS Committee members can invite additional attendees as appropriate

Communication: In addition to this charter, membership list, schedules, and other docs will be posted on the ISMS Intranet web site. During the next meeting, the meeting minutes from the previous meeting will be approved and posted on the ISMS Intranet.

ISMS Strategy: To achieve its stated purpose:

• The Puget Regional Bank ISMS program will employ a risk-based approach to analyze, and compare threats to and vulnerabilities in, information resources with respect to their criticality and value to Puget Regional Bank.

  • The ISMS program will also determine compliance with country, community, federal, state, and other regulatory information resource requirements. The results of the risk assessment will be used to determine appropriate, cost-effective safeguards and countermeasures.

• All assessment findings and recommendations, as well as the safeguards, procedures and controls implemented, will be documented and reported to the Puget Regional Bank Chief Technology Officer.

• The Internal Audit department will maintain an ongoing assessment program to test and evaluate the effectiveness of preventative, detective, and corrective information security controls to ensure their continued effectiveness against evolving risks and threats.

• The Puget Regional Bank ISMS will be managed by security policies.

• The IT Security Department will work with various departments as necessary to develop and maintain comprehensive security standards and procedures designed to implement this security strategy and security policies.

• The ISMS Committee will accept requests from any business unit, group, or department to add or make modifications to security policies or controls.

  • The ISMS Committee will address requests at their discretion based upon an analysis of the request.

• Puget Regional Bank’s IT Security Policy will be available to all Puget Regional Bank personnel via an Intranet-based application, or other appropriate medium.

  • Puget Regional Bank personnel will be informed when policies or control standards are created or changed.

  • A communication plan will be developed for security policies, standards, and procedures.

Define Control Objectives

With goals, you can begin to draft control objectives , which are the specifics with respect to assets and requirements. The organization builds controls to achieve those control objectives. Consider the following Puget Regional Bank sample assets in Table 7-1.

The following are some potential control objectives based on these two assets and requirement combinations:

• Controls provide reasonable assurance that physical and logical access to Puget Regional Bank databases and data records are restricted to authorized persons.

• Controls provide a reasonable assurance that all changes to the Puget Regional customer web site are approved and performed by authorized personnel.

• Controls provide reasonable assurance that Puget Regional Bank critical systems and infrastructure are available and fully functional as scheduled.

For an SSAE 16 SOC 1, these kinds of control objectives are a critical part of the audit. The SOC 1 is both the most flexible and most challenging in this aspect. You have the privilege and the burden of writing your own control objectives. For other audits, the compliance framework dictates a specific control objective. This is the first objective for SSAE 16 SOC 2 and SOC 3 under security:

Security commitments and requirements are addressed during the system development lifecycle including design, acquisition, implementation, configuration, testing, modification, and maintenance of system components.

Under the PCI DSS, this is the first of 12 control objectives (called a requirement in the standard): “Install and maintain a firewall configuration to protect cardholder data.”

Underneath that control objective (or requirement), the PCI DSS specifies a dozen or so specific controls that need to be in place to support it.

In ISO 27001:2013, there are 14 control groups that are analogous to control objectives. With the ISO 27001, you need to create a document called a Statement of Applicability based on these control groups. We’ll get into that soon.

Assignment of Role and Responsibility

One thing to keep in mind when working on control objectives is to think about how you are going to achieve them. This means formally assigning the control objectives to someone to work on and then requiring a continuous monitoring process. It’s common for the ISMS committee to assign the majority of IT Security control objectives to the CSO. This is a big reason why you have the formal CSO role . Left to themselves, most people neglect risks that aren’t directly their problem. They’re probably already busy doing something else. Formal assignment of roles helps minimize that.

Risk Acceptance

An ISMS committee may want to accept certain kinds of risk. Risk acceptance is the deliberate and carefully considered formal act of declaring that an organization will deal with the consequences of a risk impact. This is not ignorance, where you pretend the problem doesn’t exist. This is a conscious choice, documented in writing, that the risk is acceptable. This is usually done for risks that where the impact or likelihood is small. It can also be done for risks where the cost of managing that risk is higher than the impact.

For example, a company may say that it is accepting the risk of a super-typhoon wiping out its Hong Kong sales office; the impact is potentially high, but the likelihood is somewhat low. There are already controls for normal typhoons and the sales functions aren’t critical to company operations, so for now the risk is accepted.

When doing risk acceptance, the ISMS committee must be very explicit about documenting what they are accepting and why. The criteria for accepting risk should also be formalized, so that auditors and other interested third parties can review the decisions. To an outsider, risk acceptance can look like negligence to customers, auditors, or regulators. If something goes wrong on a risk you’ve accepted, then you really better be ready to deal with the consequences. Be very sure about your impact calculation. Lawsuits and failed audits are not pleasant experiences.

The ISMS committee should track and review accepted risks at least annually. Risks can change for a number of factors, both internally and externally, and the ISMS committee should revisit and re-decide on the risk acceptance.

Lastly, once a small risk is accepted, there is a tendency for people to think that a precedent is set and all similar small risks should be automatically be accepted. Remember risk is cumulative, like drops of water in a bucket. The more little risky things you accept, the more risk you take on as a whole. A lot of little risks are as bad as one big risk. Don’t fall into the trap of saying “We allowed this thing, so we might as well allow more like it.” It all adds up. If you’re doing quantitative risk analysis, you can calculate this cumulative risk.

Risk Elimination

There have been times when an organization did a risk analysis on a particular process and decided to drop that process entirely. The risk could simply be too high and the cost of reducing that risk just not worth it. Maybe the process is not that critical to the organization. In some cases, the organization may find a way to redesign or reorganize the process so the risky functions are no longer performed. Perhaps the process could be folded into another function, and the risk moved that way.

This kind of work can involve research, experimentation, thorough analysis, and imagination. Moreover, sometimes the resulting product does not reduce the risk in any significant way. Systems interact, both internally within the organization, and externally with the outside world. Risks almost never live in isolation and solutions can sometimes produce newer and bigger problems. In any case, risk elimination means that this particular risky process and its assets are shut down and with them, the associated risk. From an IT security perspective, this is the optimal solution. Unfortunately, the organization may have different priorities.

Risk Reduction with Controls

This is the most common choice that people make when confronted with risk. It’s likely that your organization is already trying to reduce perceived risks with controls. It’s become automatic to install firewalls, passwords, and antivirus for IT systems. It’s a suboptimal solution because the risk is rarely reduced to zero, but it’s the generally accepted solution and is often good enough. Let’s revisit the sample table of risks for Puget Regional Bank. In the analysis, several risks were not reduced enough by controls:

• Application attacks against the database and customer records

• Insider theft or sabotage against the database and customer records

• Physical theft or damage of the database and customer records

• Accidental data leaks of the database and customer records

• Defacements of the corporate web site

The ISMS committee can now propose new control projects for these risks. At this point, the ISMS committee does not have to select a particular control. It merely needs to decide that someone owns the project of reducing this risk through controls. The committee usually assigns these controls projects to the CSO to oversee, with the various departments doing the work. This is probably a good time for another RACI diagram. In Table 7-4, I present a different format of RACI diagram, breaking things down by risk.

Often a risk can be reduced by using many different types of controls. It may take some work to determine which control works best in your organization. For example, with the Application attack, risk against the database could be reduced by hardening the software with the programming work done by the developers (as shown in the preceding example). Alternatively, perhaps IT could install an application-aware filtering firewall or proxy in front of the database to stop attacks before they get there. For the physical theft risk of the databases, facilities could add better door locks or IT could implement database encryption. An ISMS sub-committee may have to do a bit of work to find a solution that is acceptably efficient and effective. Control design is covered more in Chapter 12.

Risk Transfer

There is actually a fifth option, which is a hybrid of risk elimination and risk reduction: risk transfer. For a risk transfer, you transfer either the impact or risky activity itself out of your organization. Many companies choose to outsource their payment card operations for this reason. They haven’t fully eliminated the risk, because their customers will still be angry if hackers steal their credit cards. However, the outsourcing company can be contractually bound to pay for the damages if this happens. The trick is estimating the impact so that the party taking on the risk transfer can properly compensate you. You also can try to transfer to a third party that could lower the likelihood of the risk occurring as well. A third party payment card hosting company will likely have better controls in place than in this area and (hopefully) be fully PCI DSS compliant. So you can hope that not only is the impact transferred, but the likelihood has been reduced by superior controls.

Another way to transfer risk is to simply buy cyber-insurance against the risk. There were already many insurance options for disaster related IT risks. Now many hacking or data breach risk premiums are available. Be warned however, insurance companies may interpret a covered loss much differently than you might. You should make sure that your policy really covers what you think it does before you consider a risk transferred. In addition, many insurance underwriters perform an audit much like we are describing in this book of your organization’s IT security program to calculate the cost of your premiums. Depending on the risks and the state of your organization, you may not save much money.

Documenting Risk Treatment

Once all of this done, the ISMS committee should document their proposed risk treatments. For each risk listed, the ISMS committee needs to commission a plan. Revisiting our risk list from Puget Regional Bank, let’s make a new table. Here in Table 7-5, we see the ISMS committee has decided to transfer the risk of physical theft by moving the servers to a co-location facility. They have also decided to accept the risk of insiders as the nature of the system makes controlling that risk prohibitively expensive.