A Lightweight Information Security Management System (Part II)

Create the necessary documents

In your documentation system, create the following documents:

• the Information Security Objective, which states the desired outcome of our information security policy,
• Users of the ISMS, which states who are responsible for executing information security policy,
• the Information Security Policy, which states the means by which we are going to achieve our objective,
• the Inventory of Assets, which keeps track of computers, storage, services that we use etcetera,
• Projects, which keeps track of what needs to be done in order to get policies in place,

Per document, I’ll shortly discuss its contents, and provide example copy to get you started.

Information Security Objective document

The Information Security Objective document explains to users of the ISMS why it exists, and what we want to achieve with it.

For example:

The objective of this information security management system (ISMS) is to reduce the risk of loss of confidentiality, integrity or availability of the HelloWorld application’s data, source code, and documentation.

Now that we have the objective in writing, we can use it as validation for every new policy that we’re going to include in the ISMS. Does this new policy serve the information security objective, yes or no? If yes, it’s in, if no, it’s out.

We need to make this document available to all users of the ISMS, so that everyone can remind themselves at any time of the importance of what they’re doing. It also allows them to challenge a policy if they believe it does not make sense.

Users of the ISMS

The users of the ISMS are all actors who are supposed to carry out the information security policy.

Some parties who have a responsibility in your information security are not users, for instance if they’re working for a different department or organisation. In such case, they are considered suppliers, and you need to have their responsibilities formulated in your Supplier Policy, and have those agreed upon in a contract.

Example copy:

Users of the ISMS shall be:

• the product manager of the HelloWorld application,
• team members of the development and operations team/s of the HelloWorld application.

The product manager shall be responsible for:

• maintaining the ISMS, including managing its users,
• keeping records of incident postmortem reports, ISMS change proposals, threat reports, and non-conformity reports,
• overseeing corrections and corrective actions where needed,
• update procedures in the ISMS with proposals from other users.

Team members shall be responsible for:

• reviewing ISMS policies, and reporting proposals for improvement to the product manager,
• executing procedures, and making changes to them based on what they learn from real-world use,
• notifying the product manager when they become aware of a potential threat,
• notifying the product manager of any non-conformities (violations of the information security policies as laid out in this ISMS) that they learn about,
• sending postmortem reports after any incident in which information security was compromised,

Information Security Policy document

The Information Security Policy describes the means by which we achieve the information security objective.

A policy is a set of promises. We are going to live up to those promises by following procedures (and keeping a journal so that we have records of what we did).

Let’s go through the chapters one by one:

Usage

Example text:

This policy document lays out what we are going to do in order to achieve our information security objective.

All team members shall carefully review this information security policy once every 3 months, ask clarification where needed, suggest improvements if applicable, and finally confirm in writing to the product manager that the policy was read and understood.

Now create:

• a recurring, 3-monthly calendar item in your team calendar to remind all users of this policy,
• a recurring, 3-monthly calendar item in your own calendar to remind yourself to check that all team members responded, and to record their responses in the ISMS.

Location of information

Example text:

• In order to keep track of where information is stored, the product manager shall maintain a list of assets and 3rd party services in this ISMS. Per asset, the list will show the location of the asset, and under whose control it is.
• The product manager shall keep the Inventory of Assets up to date in terms of assets that they (the product manager) control.
• The product manager shall conduct a survey among all team members once every 3 months and update the Inventory of Assets accordingly.

Now create:

• in your “Projects” document, a new to-do item “Create Inventory of Assets”,
• a recurring, 3-monthly calendar item in your own calendar “Conduct Inventory survey across team members”,
• a recurring, 3-monthly calendar item in your own calendar “Update Inventory of Assets”.

Application vulnerabilities

Example text:

• In order to prevent an incident enabled by a known vulnerability, the developers will follow the most recent version of OWASP Secure Coding Practices.
• The development team shall use a tool to continuously inspect the source code in the repository for code smells and outdated or insecure libraries.
• The team shall have the application tested for the most recent OWASP Top-10 list of security risks once every 6 months, and report findings to the product manager, who will subsequently put them on the backlog.

Now create:

• a recurring, 6-monthly calendar item in the team calendar to have the application tested,
• a recurring, 6-monthly calendar item in your own calendar to have the test results stored as a record in this ISMS.

System vulnerabilities and availability (Operations)

Example text:

• The operations team shall have intrusion detection, error monitoring and a web application firewall (WAF) in place, and a response team to deal with urgent notifications from those on a 365/24/7 basis.
• The product manager and development team shall have access to the error monitoring tool for analysis.
• Operations will have the application monitored for uptime and error rates on a 365/24/7 basis.
• The operations team shall send a postmortem to the product manager after each incident, with recommendations on how to prevent similar future incidents.
• In the absence of any notifications, the product manager will check every month if the intrusion detection, error monitoring and WAF are accessible and operational.

Now create:

• a recurring, 1-monthly calendar item in your own calendar to check if the monitoring tools are up and running.

Application hosting location

Example text:

• To avoid legal complications in case of an incident resulting from criminal activity, production and backup systems shall be hosted within the same jurisdiction as the organisation.

If you are not sure where production and backup systems are hosted, create:

• in your “Projects” document, a task to check the jurisdiction of these systems.

If they appear to be hosted in a different jurisdiction, create:

• a backlog item “Migrate production and backup systems to a host in the same jurisdiction as the organisation”.

Production data

In this example copy, I’m assuming a relatively low level of criticality of the data - in other words that we’re not dealing with financial or health records. (In those cases, you need a full-blown ISMS anyway.)

• Production data shall only be stored or processed on production and backup systems, and never leave those systems.
• If -by exception- production data is needed for debugging outside the production system, the developer/s performing the debugging shall inform the product manager, securely erase those data as soon as debugging is done, and confirm erasure to the product manager.
• Every month, the product manager will ask the development and operations team members if they are aware of any occasion in which production data was moved outside production and backup systems, used for debugging, or for testing, and ensure that any production data remaining outside production and backup systems is securely erased.

Now create:

• in your own calendar, a monthly calendar item “Ask the development team about occasions where production data left the production or backup systems”.

Backup systems

Example text:

• Operations shall maintain a “hot backup” system that synchronises with the production system in near-real time. The backup system shall be hosted with a different vendor, on a different network, than the production system.
• Operations shall have a procedure in place allowing the backup system to be promoted to production within 30 minutes, in case the production system becomes unavailable.
• Operations shall have a procedure in place to create an automatic nightly backup with a 60-day retention time, every night at 1am.

Disaster recovery

Example text:

• Operations shall be able to perform a disaster recovery procedure in case of a catastrophic incident.
• Operations shall be able to start the mitigation procedure within 10 minutes of a catastrophic incident.
• Operations shall be able to switch the hot backup system into a production system within 30 minutes after mitigation of the incident.
• If recovery from the backup system fails, operations shall be able to set up a new production system from the most recent nightly backup within 2 hours.
• Operations shall practice the recovery procedures once every 6 months, and report to results to the product manager.

Workplace security

Example text:

• Users shall only use their work computer/s in the company’s office, in their home office, or in a co-working space. Using a work computer anywhere else is only allowed with the product manager’s explicit permission.
• Users shall limit their work computer use to work on the HelloWorld application. Work computers shall not be used for other projects, or for private use like gaming, chatting, email, social media etc.
• Users’ work computers shall only have the applications and data and communications tools needed for work on the HelloWorld application.
• Users shall not connect or use storage devices to the work computer without the product manager’s permission.
• Users shall not subscribe to any 3rd party services without the product manager’s written permission.
• Every 3 months, all users shall review their computer settings with the most recent CIS Benchmarks, and report detailed results to the product manager.
• Every 3 months, the product manager shall conduct a survey to check if workplace security policies were followed.

Authentication policy

There are too many options here to give you example copy, so you’ll want to discuss the options with your development and operations teams and possibly the service that you use for the regular security testing.

In general, you need to consider the needs and responsibilities of the general public, “power users” and developers/operations.

The general public is used to authenticate with usernames and passwords, which unfortunately are very insecure and get compromised all the time. Strong passwords offer few benefits, although it’s probably a good idea to disallow users to create top-100 common passwords like “password123”. 2-factor authentication via email or text message does little to improve things, and in some cases might actually make things worse.

If security for the general public is important, consider one of the more modern implementations of passwordless authentication such as Apple’s Passkeys, but be aware of the users’ unfamiliarity with the technology and make sure to guide them through the process gently.

For power users, you’ll probably want some hardware-key based security, and also a good web application firewall is important.

Developers and Operations should use the strongest authentication methods available, like public key authentication in combination with a passphrase. Hardware-key based authentication is a good idea as well. This won’t be a problem as developers and operations people are familiar with all those methods.

I’ll write a separate article on this topic soon.

Protection of personally identifiable information (PII)

Residents of the EU, California and other jurisdictions have the legal right to:

• see a record of their PII as stored by an organisation,
• have mistakes in their PII corrected,
• have their PII deleted, once it is no longer required to be there for fulfilling the contract with the individual, or for legal or regulatory purposes.

This right is independent of where the organisation that processes the data is stored. So even if your organisation is based in New York, you are subject to EU and California legislation as soon as you have data on EU or California residents.

Especially the implementation of PII deletion can be a bit complicated.

Even if you don’t have PII of EU or California residents in your database, it might still be a good bet to be prepared for privacy requirements. Especially since EU and California legislation is being used as a model by other countries, even China.

Perhaps the following example copy could be useful:

• The product manager shall see to the implementation of a “right to be forgotten” feature, which allows the personally identifiable information of an individual in the application’s database to be removed once it is no longer needed to fulfill the contract with the individual, or for legal or regulatory purposes.

Supplier policy

Example text:

• The product manager shall review any supplier’s security policy before they are contracted.
• The product manager shall review any changes in any supplier’s security policy.
• The product manager shall store a list of all suppliers, and per supplier, a copy of all policy documentation, for reference.
• Security review shall include checking and documenting (a) the presence, scope and statement of applicability of formal security policy (SOC 2 or ISO 27001), (b) which data of the organisation the supplier stores, © the physical and geographical location of said data, (d) data retention policy, (e) backup and recovery procedures, (f) data deletion policy after cancellation, (g) policies for encrypting data in transit and at rest, (h) incident management procedures, and (i) external review of the supplier’s security.
• Security review shall in first instance be based on documentation published on the reviewer’s web site. The product manager shall ask the supplier for clarification on any points that aren’t addressed in said documentation.

Security awareness training

If your organisation has low security awareness, it might be difficult to get funding for proper security awareness training.

In that case, you might just set aside some time for self-study, using free resources:

• The product manager shall set aside 8 hours per 3 months per team member for information security self-study.
• Operations and development team leads shall decide, based on the OWASP top-10 list of vulnerabilities and all team member’s skills and experience, which topics need to be studied by each team members, and which resources should be used.
• Team members shall report to the product manager what they did in terms of self-study.
• The product manager shall keep records of self-study in this ISMS.

That is all for Part II!

We have now covered the core documents of your ISMS!

In part III of this article, we are going to cover procedures, records, non-conformities and project management.