Why you need to get to grips with information security (and all it takes is common sense)

Our firm develops enterprise software for clients around the world. Recently, I’ve been looking at tightening up our Information Security Management System (ISMS) with a view to gaining ISO 27001 certification.

I started by reading around the subject, but the more I read, the more of a disconnect I felt. We were already managing security, and ISO 27001 was only supposed to impose structure. But all the literature I read on the subject was so abstract that I couldn’t work out how I should adapt our ISMS to make it compliant.

I simply could not lay my hands on a simple, clear summary of what I had to do. And, to be honest, I started to feel irritated. What was the point of ISO 27001 if it couldn’t be made to work in practice?

ISO 27001: the options

If you’re a firm contemplating ISO 27001, you have four options: doing it all yourself, getting training before going it alone, offloading everything to a security consultant, or a halfway house where a consultant helps but you do the hands-on work.

Clearly, the first option wasn’t working out for us, and I wasn’t convinced that training wouldn’t be the same jargon-fest transplanted to a classroom. So how could a consultant help?

After my bruising encounters with ISO documentation and literature, passing the buck to someone else certainly sounded attractive. But I was worried that their solutions wouldn’t reflect how we worked. Then we might end up ignoring their suggestions, or going through the motions without making any real changes.

Another concern was that a consultant might introduce the same depressing jargon and management-speak I’d found in the literature into our ISMS, and that that would put off the team. I wanted our documents to be in plain English.

In the end I went for a consultancy package offering a set of templates we could customize or use as references, plus support via phone and email. With the consultant’s help, plus my own reading, I finally understood what ISO 27001 was all about.

Not rocket science

The big surprise was it wasn’t actually all that hard. Developing an ISMS isn’t about applying obscure technical standards or following complex processes. A lot of it is just common sense: things you’d come up with yourself, if you thought about it for long enough.

The problem wasn’t the ideas themselves, but the impenetrable thicket of management-speak that had grown up around them. It made security sound huge, complicated and scary, when it’s actually something anyone can understand, and put into practice in their business, whatever its size.

So, to help people in a similar situation get started on the road to better security, here’s my jargon-free take on what information security is all about.

Why information security is important

If you’re storing data on customers, subscribers, intellectual property or any other sensitive information, you need to think about keeping that data secure, and what you’ll do in the event of a breach.

These days, that means pretty much everybody, no matter what industry you’re in, and regardless of whether you’re going for a certificate like ISO 27001.

What’s more, when it comes to security, organizations are like sieves, leaking information every way they can. People plug in USB sticks, leave laptops open in cafés and send confidential emails to the wrong place. And the problem can’t be outsourced, because hosting firms (for example) only safeguard data when it’s on their premises, not yours.

Because of all this, security breaches aren’t rare or one-off events that you can forget about, like being struck by lightning. In 2015, 1.9m records were compromised every day. That’s 1346 every minute.

It’s not a question of whether you’ll become a victim, but when. In fact, with major security breaches at both LinkedIn and Adobe in the last few years, there’s a pretty good chance you already have. So you need to plan both your actions and your reactions — what you can do now to reduce security risks, and what you’ll do in the future if they do occur.

What is an ISMS?

An Information Security Management System (ISMS) reflects what you will do to safeguard the confidentiality, integrity and availability of sensitive data.

Your ISMS is recorded in a set of documents (discussed below), and it’s put into practice through tasks you carry out to protect data, record events and make improvements. To get your document library going, you’ll need some sort of document control management system that can store the documents, log updates and control versions.

An ISMS makes your security conscious and consistent. Instead of doing random checks and responding to issues when it’s too late, you have clearly defined tasks and processes that you commit to doing on a regular basis.

An ISMS is not a one-off project. All policy documents and procedures need to be regularly reviewed to make sure they’re still accurate and complete, and updated accordingly.

Information security standards

There are information security certifications, such as ISO 27001, that you can gain to show you’ve reached a certain standard.

These standards don’t tell you exactly what to do; they just describe the elements you need to put in place (and prove that you’ve done so).

Everything must be internally consistent and continually improved, but it’s up to you to identify specific risks and decide which ones to guard against. To retain your certification, you need to show that you’re making improvements and responding to security breaches in the right way, usually via a yearly audit.

This feedback loop is one of the most interesting things about the ISO 27001 standard, since it forces you to become more secure over time, even if you start out with a relatively poor implementation. And there will always be room for improvement, because your business will always be evolving, and new risks will always emerge.

ISMS policy

Common-sense summary: choose the destination before you set off

Your information security policy is a high-level document that describes, in general terms:

• what information you’re aiming to protect (customer records, client data, intellectual property and so on)
• why you need to protect it (to safeguard your or your clients’ businesses, to gain a certification and so on)
• how you will protect it (roles, responsibilities, processes, technologies and so on).

Your ISMS policy is a summary, not a full description. You’ll get into the nuts and bolts of security in other documents, covered below.

Roles and responsibilities

Common-sense summary: decide who will do what

There are certain security roles that have to be filled by people within the business. The people who will take on these roles can be listed in your ISMS policy.

In our ISMS, we distinguish the following roles:

• A Chief Information Security Officer (CISO) to take charge of security. In a small firm, this will probably be the founder/director. In a larger firm, the CISO will be a senior manager with a dedicated team.
• A project sponsor to act as a ‘peer reviewer’ for security work. This has to be someone different from the CISO. The sponsor reviews security initiatives and offers criticism and feedback, helping the CISO fill in gaps and iron out problems.
• Employees or team members to carry out security tasks — reviewing policies, following security training, using checklists to perform tasks, reporting to the CISO, etc.
• Management, responsible for resource allocation and risk assessment.

These are roles, not necessarily full-time jobs. However, the people who take them on will need to dedicate time to them. For example, I’d estimate that building our ISMS and making it ISO 27001 compliant took me two hours’ time a day, for about half a year. Non-tech firms might only need half that.

Management buy-in

Common-sense summary: commitment starts at the top

Managers need to make an explicit public commitment to information security. They need to affirm that security is important, and that they’ll give team members the time and resources they need to pursue it. Then, if that doesn’t happen, team members can hold them accountable.

Management buy-in must be recorded in your ISMS policy, which is signed by management and shared with employees.

Scope

Common-sense summary: decide what’s in and what’s out

Your ISMS policy can cover many different aspects of your IT systems: different types of data and documents, storage media, hardware, software and more.

Time and resources are always limited, so you can’t secure absolutely everything. You have to decide which risks to prevent, which ones to manage and which ones to accept.

The scope is a document that defines the perimeter of your ISMS: essentially, what’s in and what’s out.

The boundaries of the scope are usually defined by the question, ‘Can we control what happens with this asset?’ With company laptops, for example, you can set ‘parental controls’, disable USB ports or limit users to the company VPN for internet access. So those assets fall within the scope.

Other areas may be less black and white. For example, we use Trello for project management. We can set up two-factor authentication on our account, and we can decide what information to store there. However, we can’t control the security of the Trello service as a whole, so that’s covered by a Supplier Policy that sets out how we evaluate a supplier’s security before working with them.

The scope is one of the ISMS documents that you might want to share with clients. Combined with a third-party certification, it confirms exactly what you have committed to keeping safe.

Legal, regulatory and contractual requirements

Common-sense summary: what do the law and your contracts say?

This document lists your contractual and legal obligations.

It sets out the key points of your contracts with clients, as well as applicable legislation about data protection, personally identifiable information and so on.

It’s the source document for your risk assessment documents (see below), because risks follow from obligations.

Risk assessment

Common-sense summary: work out what could go wrong

The risk assessment is a list of all the potential security breaches that could happen within your scope.

When you first create it, you’ll need to sit down and think of all the asset classes that are covered by the obligations listed in your Legal, Regulatory and Contractual Requirements. They’ll probably include hardware, infrastructure, software, people, services and paper documents.

Ideally, everyone in the organization will do a thought exercise in which they list all the assets that they can think of, and then consider what could happen to them — threats, in other words.

Types of threat include malicious or deliberate damage (hacking, sabotage, theft, embezzlement), natural events (fire, flooding, earthquake), malfunction (drive failure, system crash, network outage) and human error (forgotten backup, loss of a laptop). To help you get started, you can find standard checklists of common threats.

To think about risks, just ‘mix and match’ assets and threats. For example, consider a company laptop. Could it be hacked or stolen? Could it be damaged by fire? Could it break down? Could it be lost?

Finally, you need to think of vulnerabilities. These are specific to your organization, not generic threats. They might include things like: too much power in the hands of one person, an overly complex interface that people avoid because it’s too difficult to use, etc.

Ideally, all employees should report the risks and vulnerabilities they can see right now. They should also be trained so they can get better at spotting them in the future.

Once risks are identified, you need to assess them. This is usually a job for management, because it means considering what a risk would mean to your organization if it happened.

ISO 27001 doesn’t tell you which risk assessment methodology you should use, but you do need to specify which one you’ve chosen.

One simple way to assess risks is to give each one a score based on how likely it is to happen (probability) and how bad the consequences will be (severity). For example, you could rate probability and severity on a 0–2 scale, as we do. For probability, 0=very unlikely; 1=fairly likely; 2=almost certain. For severity, 0=reversible; 1=reversible at a cost we can handle; 2=irreversible, or the damage is beyond our ability to pay.

You then add the two numbers together to give a score between 0 and 4, with risks scoring 4 being the most important and urgent. You can then define a baseline above which a risk needs attention, and below which you don’t need to do anything.

Once you’ve identified all the risks that need action, you need to set a policy for each one by deciding how you’ll prevent it, reduce its likelihood or respond to it if it takes place. At the next two steps, you’ll specify which approaches to use (controls), and how you’ll make it happen (procedures).

Statement of applicability

Common-sense summary: choose fixes for the problems

This document, prescribed by ISO 27001, lists all the different methods (called ‘controls’) you could use to manage the risks you identified in the risk assessment. They include authentication, encryption, backups, staff training and so on.

For each control, you need to say whether and how you’ll use it — or, if not it, why not.

All your plans need to be accurate and consistent, or third-party auditors will refuse to certify you.

Procedures

Common-sense summary: make step-by-step plans to manage risks

Procedures are detailed documents that explain what you will do to put your risk policies into practice, using the controls identified in the statement of applicability.

Let’s say you’ve identified a risk of data loss from malfunction or human error. To reduce the severity of this risk, your policy says that each application must generate a nightly backup, and that a team member must make sure that it’s happened. The description of this sequence of events is called a procedure: a step-by-step checklist that is followed every time a particular task is carried out.

For example, we have procedures for:

• thoroughly checking laptops’ configuration every three months, following the CIS specification
• working away from home
• selecting a supplier (asking them to fill in a questionnaire, for instance)
• sending laptops in for repairs
• sharing passwords with clients
• decommissioning servers
• wrapping up for the day (clean desk policy)
• employee onboarding/offboarding.

You might also want to develop more high-level procedures to help continuous improvement. For example, you could hold a monthly brainstorm for ideas on security improvements, or a quiz including security-testing questions such as ‘think of a way to hack our server’.

Creating a security culture

_ Common-sense summary: rules don’t make security, people do_

Although an ISMS "lays down the law" on security, it isn’t just about setting rigid rules and blindly following them. It’s also about people, and how they work together to maintain and improve security.

Not every risk can be foreseen; some just have to be spotted and dealt with as they arise. That can only happen when people know what to look for, and are actively looking for it. Your ISMS should help to cultivate a security culture within your business, where everyone takes a security perspective on everything they do. Security awareness is a very important control in ISO 27001.

If you want everyone to buy into security, they need to understand what it’s all about. That’s why writing documents in plain, engaging language is so important. Jargon puts up barriers, while plain words bring people together.