A Lightweight Information Security Management System (Part I)

Introduction

Yesterday, ride-hailing service Uber reported a major cybersecurity breach. A hacker impersonating a colleague from IT sent a text message to an Uber employee and persuaded them to give them full access to Uber’s internal systems. It was a simple social engineering trick with potentially devastating consequences.

This was not Uber’s first major incident. In 2016, another hack exposed personal data from 57 million customers and drivers.

Incidents like these happen all the time, and not just to large corporations.

In January this year, data from FlexBooker, an online appointment scheduling service, started to circulate on the dark web. It turned out that FlexBooker was storing appointment confirmation emails in the cloud without any form of access control, so that anybody with a browser had full access to those emails, 19 million of them, which contained appointment data, personal information, health information, and details about people’s children.

What virtually all incidents have in common is that they could have been prevented with relatively simple measures.

Why does information security need to be managed?

The problem with information security in general is that it involves efforts that no-one wants to make in order to deal with scenarios that no-one wants to think about.

Organisations usually misprice the risk of information security incidents, and as a result, tend to prioritise feature development over security.

Since the number of paths to a security incident are unlimited, we can’t address them all. Choices need to be made on where we invest our efforts. Making these choices is a form of risk management, and as the term already suggests, this is a concern that should be addressed at the management level of an organisation. After all, an information security risk can have consequences in terms of reputation damage, litigation, fines etc, all of which affect an organisation’s financial position.

If management doesn’t take responsiblity for information security risk, security policy often happens ad hoc.

For example, a system administrator might impose certain rules, like requiring people to use a company VPN or preventing them from installing applications on their computer. These rules are often implemented without proper assessment of risk, cost, benefits, and possibly better-suited alternatives.

More mature organisations employ a specialist Chief Information Security Officer (CISO), who reports to the CIO or CEO and is responsible for implementing security policy based on proper risk assessment and cost/benefit-analysis of risk controls, and documented in an Information Security Management System (ISMS).

If an organisation’s management doesn’t take responsibility for information security, and a security breach happens on your watch, don’t be surprised if they blame it on you. This article will help you get basic but effective information security policies in place, in which information security is treated as a conscious, ongoing process.

What is information security about?

Information security is about protecting the confidentiality, integrity and availability (CIA) of information.

In the context of the development and management of an application, that information is usually source code, data and documentation.

Examples:

• If an unauthorised person gets access to private information, that’s a loss of confidentiality.
• If information is changed without authorisation, that’s a loss of integrity.
• If a system carrying information goes offline, that’s a loss of availability.
• If information is (permanently) lost, that’s a loss of availability as well.

Now if one of those scenarios materialises, we talk about an incident. An incident is an event where information security is compromised.

A possible incident in the future that we’re concerned about is called a threat. If we consider the likelihood and consequences (costs) of a threat, we’re talking about a risk.

In information security, we address risks with security policy, designed to prevent, detect, respond to and recover from security incidents.

For example:

Let’s consider the threat of a hacker getting access to one of your database servers, encrypting it, and holding it at ransom.

• We try to prevent the hack with strict access control, strong password policy, regular penetrating testing, and an advanced firewall,
• We try to detect the hack with an intrusion detection tool,
• We respond to the hack by involving the response team (like operations or the firewall supplier),
• We recover from the hack by involving a forensics team for analysis, putting new preventing measures in place, and restore a new database server from a backup.

How do we manage information security?

Information security management is a form of risk management, where we address the CIA risks mentioned above with an ongoing, documented, conscious, standardised, continuously improved process.

Information security is managed by means of a system called an ISMS or Information Security Management System.

It is a process based on a set of documentation that lays out what information you want to protect, how you are going to protect it, standard procedures and records.

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.

Why do you need an information security system?

Perhaps you ask, why is information security management a system? Why can’t we just make the application secure and leave it at that?

Security is not a property of an application alone. It involves human behaviour, newly developing threats, and changes in the way an application is used. That means that security is an ongoing process, and it needs to be done correctly right from the beginning, when development starts, until the day that the application is taken offline.

People (users, product managers, developers, even operations) often do things in insecure ways. I once had a power user (someone who could do almost anything on the system that we built) who had his password on a Post-It note attached to his monitor. This is the kind of problem that you want to catch and address on an ongoing basis.

Sometimes unsafe practices happen when the application isn’t properly designed for a workflow that it needs to support. Maybe it was at some point, but the workflow has meanwhile changed.

For example, one of our applications used to have a user archetype for preparing and reviewing legal documents. At some point, some users who were logging in as that archetype got so much work that they got an assistant to help them with preparing legal documents. However the assistant did not have clearance to review legal documents, yet was given that level of access because that was the only way to let them do their work without changing the software. That created a new case for risk assessement: the possibility of the assistant accidentally approving a legal document.

Another factor is time. Over time, systems need security updates and sometimes, major upgrades. Someone needs to keep track of those things and ensure that they happen. No developer enjoys those maintenance chores, so they don’t happen unless you are on top of them.

The main benefit of having a disciplined security process in place is that it creates security awareness. The discipline of going through policy documents and procedures prevents people from getting sloppy. An information security system is essentially a framework for an ongoing process of learning and habit-forming.

Information security standards

Among the most well-known standards for information security are SOC 2, NIST 800-53 and ISO-27001. SOC 2 and NIST 800-53 are mostly used in the United States, ISO-27001 everywhere else. ISO-27001 is the most disciplined and extensive standard of these.

The benefit of implementing a standardised ISMS is that you can get audited and certified. Certification guarantees a certain discipline to your security management process, and proves that to the outside world. Clients will be more eager to work with you, knowing that you take the protection of their data seriously.

However if you are in the situation that management is not taking responsibility for information security, certification is out of reach, as some of the core parts of an ISMS, like risk management and policy review, are explicit management responsibilities.

So what do we do?

If a formal, certified ISMS is not feasible, you still have the option of implementing a basic ISMS that will provide a considerable improvement in information security over ad-hoc information security.

Now as I said, this lightweight approach is not a replacement for a fully-fledged, formal, auditable/certifiable ISMS. I assume that you’ve have made a serious effort to convince management of the need of information security policy and a CISO to ensure its execution. I assume that management has either shown lack of responsibility, understanding, or sense of urgency. You need to be the adult in the room and get some kind of security in place, before accidents happen and the blame falls on you, the developers or operations.

Also, its underlying ideas are compatible with SOC 2 or ISO-27001, so you’ll be able to expand to those standards later if so required, and be able to reuse your work, without having to redo everything you did.

(If management talk about costs, that might actually be a good starting point for a conversation. After all, information security policy is like insurance, and when proper risk assessement takes place, no risk is treated unless its cost is preferred over accepting the risk.)

Differences with formal, standardised ISMS

The alternative, lightweight approach described in this article is designed to deal with the OWASP Top 10 Web Application Security Risks.

It is a major improvement over ad hoc policy, and gets the policies and procedures in place that are irresponsible to leave out. They prevent you and the development team from looking stupid in case of a security incident.

The approach is much less extensive than ISO-27001 or even SOC 2.

To give you an idea, here’s a workflow diagram of the ISO-27001 based ISMS that we set up in E-accent in 2015.

Does that look overwhelming to you? Fortunately, our simplified ISMS is a lot more simple.

Compared to ISO-27001, it most notably ignores:

• Management review
• Risk assessment and risk treatment methodology (clause 6.1.2)
• Statement of Applicability (clause 6.1.3 d)
• Risk assessment report (clauses 8.2 and 8.3)

Again, this is because these are management concerns, and as product managers, we can’t take on their responsibilities.

Documents of the ISMS

All ISMS consist of living documentation, consisting of (among others):

• Information security objectives, so that everyone understands what you are trying to accomplish,
• Assets, to keep track of where information is stored,
• Policies that describe how we are going to achieve our objectives,
• Procedures that help us apply security measures in a standardised, repeatable and measurable way,
• Records that keep track of incidents and feedback from real-world us.

Documentation system

An ISMS requires some kind of shared documentation system.

My company uses Notion, but there are plenty of alternatives like Coda, Evernote, Asana, Confluence and many others.

The documentation system should be accessible to anyone who is supposed to follow information security policy. However you’ll probably want some kind of access control on individual sections and pages, so that you can keep sensitive data (like reports of threats or incidents) private to the product management team if necessary.

Preferably use a documentation system that is based in the same jurisdiction as yourself, or at least one that is compatible with privacy regulations in your jurisdiction (like GDPR in the European Union or CCPA in California).

Setting up our ISMS

In part II of this article, we get our hands dirty and create the core documents of our lightweight ISMS. You’ll be up and running soon, isn’t that exciting?