Proactive, application and detective security in a growing company
This chapter divides security work into three kinds and places each kind on ACME's data flow. 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. Every later chapter belongs to one or more of these kinds, and the data flow shows where it applies.
- Leading security at two startups in a row, both acquired about two years after I joined
- ACME, the company this series follows
- One set of security records for customers, auditors and regulators
- Proactive, application and detective security in a growing company (you are here)
For engineers: Threat modelling a data flow with STRIDE.
This chapter looks at ACME at its third stage. Twenty people work there. They run a dashboard for businesses in a cloud account in an EU region, and a gateway that reads electricity meters inside customers' buildings.
The data flow
A company's data flow is the path its data takes: where it comes in, where it is stored and processed, and where it goes out. Every security control protects some part of this path, so drawing it comes first.
A trust boundary is a point where data passes from one owner or network to another. Data that crosses a boundary leaves the protection of one side and depends on the other. In the figure, the dashed boxes are trust boundaries, and every arrow that crosses one marks a place where something can go wrong.
We can break ACME's data flow down into three parts:
- Delivery happens inside ACME. Developers send code changes from their laptops to GitHub, where the build pipeline turns the reviewed changes into signed container images, and these are deployed into ACME's cloud account.
- Ingestion starts in the customer's building. The gateway reads the meters over Modbus and sends the readings over mutual TLS to the dashboard's API, which stores them in a Postgres database.
- Use happens over the public internet. Business users sign in to the dashboard and read their sites' consumption, and the dashboard sends alert emails through an email supplier.
Proactive security
Proactive security is what the company decides and sets up before any data moves. On ACME's flow it answers questions like these:
- who may sign in to the dashboard, and with which second factor;
- which data is encrypted in the database and on its way between systems;
- which suppliers may see customer data;
- how the database is backed up, and how long a restore takes;
- what staff know about phishing and lost laptops;
- how a gateway box in a building is protected if someone takes it;
- how often outside testers try to break in while nobody has yet, listing the weaknesses they find and the attack chains those weaknesses make possible (a penetration test).
Encryption is one of these decisions. ACME encrypts all traffic to the dashboard with TLS, the protocol behind the padlock in the browser. Between each gateway and the dashboard it uses mutual TLS, in which both sides prove who they are with a certificate before any reading is sent. The database, the file storage and the backups are encrypted at rest, with the keys kept in the cloud provider's key vault, and every laptop has full-disk encryption, so a stolen laptop does not expose the data on it.
These decisions make attacks harder and limit what an attacker gets when one succeeds. Most of them end up as rules and settings, so their records are policies and configurations, such as the access list and the backup reports. Parts 2 and 3 of the series cover them.
Application security
Application security covers the software at each step of the flow: the code ACME's developers write, the libraries that code uses, and the pipeline that builds and delivers it. For ACME that means the dashboard's API, its web front end, the gateway program, and the GitHub Actions pipeline that turns code into running software.
A weakness here sits inside the processing itself. If the dashboard forgets to check that a user belongs to the customer whose data they ask for, it hands one customer's readings to another, however well the database is encrypted. Part 2 of the series, the assembly line, covers how code is reviewed, tested, scanned, signed and delivered.
Detective security
Detective security watches what happens on the flow and keeps a record of it. On ACME's flow it means logs at each boundary: sign-ins to the dashboard, administrator actions, data exports, deployments and every gateway connection. It also covers the alerts that tell a person when something unusual happens, the plan for handling an incident, and the regular checks that look for problems in what is already running, such as scans and audits.
Detective controls do their work after the fact. They tell the company that something happened, what it touched and when, which is what the legal deadlines and the customers' contracts ask for after an incident. Parts 4 and 5 of the series cover them.
A safe as an example
A simple way to picture the three kinds is a safe. Proactive security is the decision to keep the valuables in a safe at all. Application security makes sure the safe works correctly and opens only with a strong code, never with 0000. Detective security watches the safe: it checks who opens it and when, and when someone is not who they claim to be, it raises an alert and blocks their access.
One incident seen through all three kinds
Suppose an attacker obtains the password of an ACME administrator, for example through a phishing email.
- With proactive security in place, the password alone does not open the account, because ACME requires multi-factor sign-in for administrators. The administrator role also cannot export every customer's data without a second person, which limits the damage if the attacker gets in anyway.
- Application security limits what the session can do. The dashboard asks for the second factor again before a large export, ends sessions after a period without activity, and checks on every request that the user may see the data they ask for.
- Detective security is how anyone finds out. A sign-in from a new country raises an alert, and the audit log shows what the session viewed and exported.
Without the audit log, ACME cannot tell its customers whether their data was read. It would have to decide on the notice to the data protection authority, which GDPR expects within 72 hours where feasible, without knowing the answer.
First steps at each stage
The table lists the first work of each kind at each of ACME's stages. Later chapters take each cell in turn.
| Stage | Proactive | Application | Detective |
|---|---|---|---|
| 1. Webshop | Personal administrator accounts with multi-factor sign-in, backups kept off the server | Few plugins, updated every week on a staging copy | The payment provider's fraud alerts, a notice for each administrator sign-in |
| 2. Dashboard | Single sign-on, access reviews, encryption, a supplier list, a first penetration test | Code review, a build pipeline, dependency scanning | Central logs, an audit log of administrator actions |
| 3. Gateway | Signed releases, an update policy, protection for the boxes in buildings | An SBOM, signing, an update channel with rollback | A contact point for vulnerability reports, monitoring of gateway connections |
| 4. Public sector | The roles and policies that tenders ask for, EU hosting | Records of secure development that buyers can check | An incident plan with the legal deadlines, alerts with on-call duty, internal audits |
Cost
These are estimates. Depending on the company and how it operates, the real numbers can be higher or lower.
- Drawing the data flow
- About half a day at ACME's third stage, for someone who knows the systems. At the first stage it fits on one page and takes about an hour.
- Keeping it current
- About thirty minutes for each change in the architecture.
- Skill
- Someone who knows where the data goes, usually the CTO or a senior developer.
- Money
- At this stage, only time. Sample costs for each control are in the chapter that covers it.
Keeping all of this under control also takes attention, beyond the hours. It can break the concentration needed for product work or for leading new business, and in a small company the same person often does both.
Limits
The three kinds overlap. A penetration test is proactive work that finds application weaknesses: nobody has broken in yet, and the testers try to, listing the weaknesses and the attack chains they find. A backup is proactive work whose restore test is detective. The split helps to see which kind of work is missing at a given stage. The controls themselves are chosen from the risks on the data flow, which chapter 3.2 covers.