Building a security program for a growing company

Security is a process, and its records show you are in control

Security is the work of protecting people, their data and the value a company builds, and of staying in control of that protection while the company changes. It runs as a process, week after week, and every round of it leaves records: an access review, a restore test, a signed software release, an incident log, a penetration test report.

Customers and certification auditors ask for these records. So do regulators and insurers, and the buyers of a company before a sale. Each of them uses its own name for the same work: ISO 27001, SOC 2, NIS2, the Cyber Resilience Act, GDPR, a security questionnaire, due diligence. A company that keeps the records while it makes and ships its product can answer a new customer or a new auditor with little extra work, and it can show at any time that it is in control. Every chapter shows one or two of these records: the risk each one answers, what it costs to build and keep, and who reads it.

ACME

ACME starts as a webshop for smart plugs, grows into software for businesses with a gateway installed in customers' buildings, and later sells to municipalities and hospitals. At each stage new customers and new laws ask for new security work, and the chapters follow that order.

Proactive, application and detective security

The series sorts security work into three kinds. Proactive security is what a company decides and sets up before data moves. Application security covers the software that handles the data. Detective security watches what happens and keeps the record. Chapter 1.4 places all three on ACME's data flow.

Reading the series

The plain chapters are written for founders and managers, and for the buyers who review suppliers, with every technical term explained the first time it appears. The engineering companions are written for developers and platform engineers, with code and the commands to run it. Each chapter links to its companion, and the chapters can be read in order or picked by topic.

Part 1. Introduction

This part introduces the author and ACME, the company the series follows. It also sets out the main idea of the series and the three kinds of security work.

1. 1.1 Leading security at two startups in a row, both acquired about two years after I joined
2. 1.2 ACME, the company this series follows
3. 1.3 One set of security records for customers, auditors and regulators
   for engineers: Producing audit evidence from the build pipeline TBA
4. 1.4 Proactive, application and detective security in a growing company
   for engineers: Threat modelling a data flow with STRIDE

Part 2. The assembly line: building and delivering software securely

This part follows ACME's software from the first webshop to the gateway installed at customers' sites. It shows how code becomes a product that customers can trust, and the records each step leaves.

1. 2.1 Keeping a WooCommerce webshop up to date and secure
2. 2.2 Deploying through a CI pipeline instead of by hand TBA
   for engineers: A first CI pipeline for a small team TBA
3. 2.3 Handling passwords, keys and other secrets TBA
   for engineers: Finding and rotating leaked secrets TBA
4. 2.4 Code review as a security control TBA
   for engineers: Secure coding in PHP and WordPress TBA; Secure coding in Python and Django TBA; Secure coding in Node.js and TypeScript TBA; Secure coding in Go, and what static typing and memory safety do and do not prevent TBA
5. 2.5 Code your product uses but your team did not write: libraries, licences and the SBOM TBA
   for engineers: Dependency scanning, licence checks and an SBOM in one CI job TBA
6. 2.6 Shipping only what the product needs to run (container images) TBA
   for engineers: Multi-stage, non-root container builds with scanning TBA
7. 2.7 Access to the production systems (Kubernetes) TBA
   for engineers: RBAC, namespaces, network policies and audit logs for a small team TBA
8. 2.8 Delivering software that customers run on their own servers TBA
   for engineers: Signing images and binaries, and verifying them on install TBA
9. 2.9 Updates and support periods for software on customer sites TBA
   for engineers: An update channel with signed manifests, staged rollout and rollback TBA
10. 2.10 Receiving and handling vulnerability reports TBA
    for engineers: From a vulnerability report to a published advisory TBA
11. 2.11 Supplier security requirements from an industrial customer in 2020 TBA

Part 3. The security program

The management side of security that customers and auditors ask about, written for a company of ten to fifty people.

1. 3.1 Answering a customer's security questionnaire TBA
   for engineers: Collecting technical evidence from the repository and the cloud TBA
2. 3.2 Scope, assets and risk assessment TBA
   for engineers: Keeping an asset inventory current TBA
3. 3.3 Security roles and separation of duties in a small company TBA
4. 3.4 Writing security policies that fit the company TBA
   for engineers: Keeping policies in Git and releasing them like code TBA
5. 3.5 Access over an employee's time at the company: joining, changing roles, leaving TBA
   for engineers: Managing access with SSO and SCIM TBA
6. 3.6 Suppliers and the services the product depends on TBA
7. 3.7 Physical security for a company without its own server room TBA
   for engineers: A laptop baseline: disk encryption, screen lock and updates TBA
8. 3.8 Backups, restores and business continuity TBA
   for engineers: Restore drills for Postgres and a container registry TBA
9. 3.9 Personal data and GDPR in a SaaS company TBA
   for engineers: Using production data in staging without customer data TBA
10. 3.10 Writing the Omnio ISMS in LaTeX, September 2020 to January 2021 TBA

Part 4. Audits, certification and regulation

This part covers the checks that auditors and customers make on the security work, and the laws that apply to it.

1. 4.1 ISO 27001 and SOC 2 compared TBA
   for engineers: One set of evidence for two audits TBA
2. 4.2 Running an internal audit TBA
3. 4.3 The certification audit: stage 1, stage 2 and surveillance audits TBA
4. 4.4 Scoping a penetration test TBA
   for engineers: Writing a penetration test scope document TBA
5. 4.5 Security reviews in enterprise sales TBA
6. 4.6 The Cyber Resilience Act for a company that makes a connected product TBA
   for engineers: Technical documentation for the Cyber Resilience Act TBA
7. 4.7 NIS2 requirements that reach suppliers TBA
8. 4.8 Security requirements in public tenders TBA
9. 4.9 Selling to regulated sectors such as finance and health TBA
10. 4.10 Learning security from customer due diligence at Krizo TBA

Part 5. Operating and improving the program

This part covers the daily running of the program and its improvement over time. It closes with ACME's acquisition.

1. 5.1 Logging and audit trails TBA
   for engineers: Application audit logs: who, what, when and from where TBA
2. 5.2 Detection and alerting in a small team TBA
   for engineers: A short set of detections for a SaaS on Kubernetes TBA
3. 5.3 Incident response TBA
   for engineers: An incident runbook and a forensic capture of a Kubernetes pod TBA
4. 5.4 Investigating an incident by the weight of the evidence TBA
5. 5.5 Vulnerability management in operations TBA
   for engineers: Prioritising scanner findings with reachability, KEV and VEX TBA
6. 5.6 Measuring the program and reporting to management TBA
7. 5.7 Continual improvement and the limits of spending TBA
8. 5.8 Due diligence when Omnio was acquired by IBM TBA
   for engineers: Rebuilding a product for an enterprise buyer: static musl builds, approved base images and FIPS-validated cryptography TBA

The author

Marius-Florin Cristian is a CISSP who led security at Krizo and at Omnio. Dataminr later acquired Krizo, and IBM acquired Omnio. He runs KEIBISOFT, which builds and runs security programs for companies at the stages this series describes, and he develops KEIBIDROP, an open-source tool that opens a folder on another computer over an end-to-end encrypted peer-to-peer connection. You can find the work listed on the services page.