Top of the iceberg: politicians’ private email accounts and shadow IT

In CISO circles the term “shadow IT” is commonly used for when employees use private accounts, devices and networks to conduct work outside of the company’s IT policies. People often do this because they feel they don’t have the freedom to get the job done within the rules.

071615_1406_Treatyourpe1.jpg

If you deny your people a well-stacked toolbox, they will bring their own. That may not be the best solution for your security. 

This is not only for low-level clerks and helpdesk ninjas: top level managers are known to do this a lot, including politicians. Hillary Clinton probably lost the presidential election at least partially due to her poor security awareness. Now VP Mike Pence has also been outed as “private email wielding pubic servant” – and he was hacked too. Why do people do this?

Reasons why people do their business in the IT shadows

I’ll nominate 3 main reasons why people tend to use private and unauthorized tools and services in companies and public service. Then let’s look at what we can do about it, because this is a serious expansion of the organization’s attack surface! And we don’t want that, do we?

I believe (based on experience) the 3 main reasons are:

  1. The tools they are provided with are hard to use, impractical or not available
  2. They do not understand the security implications and have not internalized what secure behaviors really are
  3. The always-on culture is making the distinction between “work” and “personal” foggy; people don’t see that risks they are willing to take in their personal lives are also affecting their organizations that typically will have a completely different risk context

How to avoid the shadow IT rabbit hole of vulnerabilities

First of all, don’t treat your employees and co-workers are idiots. IT security is very often about locking everything down and hardening machines and services. If you go too far in this direction you make it very hard for people to do their jobs, and you can end of driving them into the far riskier practices of inventing their own workarounds using unauthorized solutions – like private email accounts. Make sure controls are balanced, and don’t forget that security is there to protect productivity – not as the key product of most organizations. Therefore, your risk governance must ensure:

  • Select risk-based controls – don’t lock everything down by default
  • Provide your employees with the solutions they need to do their jobs
  • Remember that no matter how much you harden your servers, the human factor still remains.

Second, make people your most important security assets. Build a security aware culture. This has to be done by training, by leadership and by grassroots engagement in your organization.

Third, and for now last, disconnect. Allow people to disconnect. Encourage it. Introduce separations between the private and what is work or for your organization. This is important because the threat contexts of the private sphere and the organizational sphere are in most cases very different. This is also the most difficult part of the management equation: allowing flexible work but ensuring there is a divide between “work” and “life”. This is what work-life balance means for security; it allows people to maintain different contexts for different parts of their lives.

 

Cybersecurity for boards – the short story

A few days ago I wrote a post on the lack of cybersecurity skills in corporate boards, and how to fix that. This became one of the most popular posts on the blog. That’s why I created this short summary video – that you can easily share with your top management and board members.

The take-aways are:

  • Build an information security management system with the most important policies, guidelines, procedures, change mangement and monitoring processes in place
  • Select reporting metrics that make sense in terms of the company strategy. Relate impact to financial, customer, organnization and learning, and internal process perspectives.
  • Use compliance to drive board focus: regulatory compliance is already central in goverannce work.
  • Focus on people when communicating – build a positive security culture by combining bottom-up and top-down approaches.

Thanks to Kenneth Holley and eForensics Magazine for sharing the board post! Great accounts to follow on Twitter!

How to build up your information security management system in accordance with ISO 27001

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.

Main requirements and activity descriptions

Context mapping

(Ref. ISO 27001 Section 4)

The context mapping consists of creating an overview of the value chain as well as the internal requirements to security (you can read more about that in What are the things that need to be considered when doing a risk assessment?), and how this affects the information security risk. Key activities:

  • External stakeholder definitions
    • Who are the main customers
    • Who are the main suppliers
    • 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.

071415_0731_Fourgoldenp1.png

Building a management system requires the involvement from the whole organization. Focusing on business strategy, key stakeholders and the value chain in terms of core competence, contracts with the supply chain and how to drive compliance (e.g. through auditing) is key to securing the organizations’ assets in the long run.

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:
    • Policy objectives
    • 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/

Support

(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:
    • Senior leadership
    • HR and middle management
    • Information system users
    • IT personnel
    • 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.

Continuous Improvement

(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.

Main activity Sub activities Inputs Outputs People
Context development Stakeholder mapping 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. Top management

Consultant

Context development Inventory mapping Network topologies, asset lists, document systems Prioritized inventory description as section in technical note on Context. CISO

IT department

Archiving department

Consultant

Context development 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. CISO

Consultant

Risk procedure development Risk assessment procedure document CISO

Consultant

Risk assessment Scope definition for risk assessment Context note with inventory.

Topology drawings. Organization charts. Use cases.

Scope presentations Consultant

System owners

CISO

Risk assessment Risk identification Use of guidewords for each scope node, ref risk assessment procedure. Risk identification table (HAZID table) Consultant

System owners

CISO

Risk assessment Risk evaluation HAZID table. Risk ranking. Consultant

System owners

CISO

Risk assessment Mitigation planning (including ISO 27001 Annex A review) HAZID table with risk ranking. List of actions and controls to be evaluated or implemented. Consultant

System owners

CISO

Risk assessment Reporting HAZID table and risk mitigation results. Risk and vulnerability report. Consultant
Statement of applicability Review each control in Annex A Context note. Risk and vulnarbility report. Statement of applicability (report) Consultant

CISO

Objectives development 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. Consultants
Objectives development Review of objectives with key stakeholders Objective note. Revised objective note. CISO

Top management

Consultant

Policy development Develop draft policy for information security. Objectives, statement of applicability, risk and vulnerability report, context, policy templates. Draft policy. Consultant

CISO

Policy development Review draft policy in meeting with top management. Top leadership needs to be involved and take ownership, headed by the CISO. Draft document Revised policy Top management

CISO

Consultant

HR Integration: competence management Develop competence requirements for roles Role descriptions Updated competence requirements in role descriptions HR

CISO

Consultant

Awareness program Develop awareness program, tailored to competence requirements of groups. Updated role descriptions Awareness program plan HR/Training responsible

CISO

Consultant

Internal auditing requirements Update internal auditing requirements Infosec policy and procedures, objectives Updated audit plans and competence requirements for subject matter expert CISO

Internal auditor

Consultant

Other integrations 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.

Thinking about risk through methods

Risk management is  a topic with a large number of methods. Within the process industries, semi-quantitative methods are popular, in particular for determining required SIL for safety instrumented functions (automatic shutdowns, etc.). Two common approaches are known as LOPA, which is short for “layers of protection analysis” and Riskgraph. These methods are sometimes treated as “holy” by practicioners, but truth is that they are merely coginitive aids in sorting through our thinking about risks.

 

13768080_1067660556651700_1098663203_n

Riskgraph #sliderule – methods are formalisms. See picture on Instagram

 

In short, our risk assessment process consists of a series of steps here:

  • Identify risk scenarios
  • Find out what can reduce the risk that you have in place, like design features and procedures
  • Determine what the potential consequences of the scenario at hand is, e.g. worker fatalities or a major environmental disaster
  • Make an estimate of how likely or credible you think it is that the risk scenario should occur
  • Consider how much you trust the existing barriers to do the job
  • Determine how trustworthy your new barrier must be for the situation to be acceptable

Several of these bullet points can be very difficult tasks alone, and putting together a risk picture that allows you to make sane decisions is hard work. That’s why we lean on methods, to help us make sense of the mess that discussions about risk typically lead to.

Consequences can be hard to gauge, and one bad situation may lead to a set of different outcomes. Think about the risk of “falling asleep while driving a car”. Both of these are valid consequences that may occur:

  • You drive off the road and crash in the ditch – moderate to serious injuries
  • You steer the car into the wrong lane and crash head-on with a truck – instant death

Should you think about both, or pick one of them, or another consequence not on this list? In many “barrier design” cases the designer chooses to design for the worst-case credible consequence. It may be difficult to judge what is really credible, and what is truly the worst-case. And is this approach sound if the worst-case is credible but still quite unlikeley, while at the same time you have relatively likely scenarios with less serious outcomes? If you use a method like LOPA or RiskGraph, you may very well have a statement in your method description to always use the worst-case consequence. A bit of judgment and common sense is still a good idea.

Another difficult topic is probability, or credibility. How likely is it that an initiating event should occur, and what is the initating event in the first place? If you are the driver of the car, is “falling asleep behind the wheel” the initating event? Let’s say it is. You can definitely find statistics on how often people fall asleep behind the wheel. The key question is, is this applicable to the situation at hand? Are data from other countries applicable? Maybe not, if they have different road standards, different requirements for getting a driver’s license, etc. Personal or local factors can also influence the probability. In the case of the driver falling asleep, the probabilities would be influenced by his or her health, stress levels, maintenance of the car, etc. Bottom line is, also the estimate of probability will be a judgment call in most cases. If you are lucky enough to have statistical data to lean on, make sure you validate that the data are representative for your situation.Good method descriptions should also give guidance on how to do these judgment calls.

Most risks you identify already have some risk reducing barrier elements. These can be things like alarms and operating procedures, and other means to reduce the likelihood or consequence of escalation of the scenario. Determining how much you are willing to rely on these other barriers is key to setting a requirement on your safety function of interest – typically a SIL rating. Standards limit how much you can trust certain types of safeguards, but also here there will be some judgment involved. Key questions are:

  • Are multiple safeguards really independent, such that the same type of failure cannot know out multiple defenses at once?
  • How much trust can you put in each safeguard?
  • Are there situations where the safeguards are less trustworthy, e.g. if there are only summer interns available to handle a serious situation that requires experience and leadership?

Risk assessmen methods are helpful but don’t forget that you make a lot of assumptions when you use them. Don’t forget to question your assumptions even if you use a recognized method, especially not if somebody’s life will depend on your decision.

Safety versus convenience 

Risk based asset management frameworks force us to be systematic in our approach. Multiple layers of defense are commonly applied to mitigate risks down to what we see as an acceptable level. In many cases it will feel like each layer of defense is a layer of inconvenience. 

 

Do we maximize the number of spikes (or layers of protection) to feel safe?


The ALARP principle is often used to evaluate if a certain defense layer is worth the investment. This type of analysis tends to be CAPEX focused. Very cumbersome operations tend to make people invent bypasses that are more convenient. In addition to investment cost, maybe we should also include the effect of the mitigation solution on convenience and how humans react to it, in addition to cost? If people bypass the intended operating procedure – the result of the new risk mitigation investment could be an increase in the overall risk.