I have several years of experience building and leading security teams. My teams have built security programs from scratch, helped prepare companies for their IPO, fought off active attacks, and attained compliance/alignment/certification with PCI DSS, SOC 1, SOC2, NIST CSF, etc.
I still feel like an outsider in this space, but I have learned a few tricks.
First, I acknowledge that cybersecurity speak is hard. There is a lot of jargon and acronyms, and it is deliberately designed to be that way. It is much like Wall Street. Cybersecurity vendors sell on fear and misinformation. The playbook, I imagine, is as follows
- make up new terms
- play up obscure risks
- scare you into buying
- use “defense-in-depth” to upsell
Aside: DNSSEC — I am looking at you. I have spent hours and hours in meetings, reading books, and implementing it myself, trying to understand why we need it. The conclusion: we don’t! For every hypothetical risk, there is a better solution than RRSIGs and DNSKEYs.
If you are already tired of the jargon on this page, there is more! We regularly use terms such as SCIM, SIEM, and HSTS. The industry has suffered because of it. Every day, cybersecurity professionals struggle to explain the value of their work and demonstrate compelling investment cases.
Second, there is a subworld of real cybersecurity and another subworld of security theater. The real world is where Heartbleed and Log4Shell happen. It is important to find this subworld, stay up to date, and make sure to follow all the recommendations. The other subworld is trying to sell you the 12th scanner for your dependencies and your 4th “single pane of glass”. It is hard to tell the difference.
I am here to share some intuition.
One: Think About The Attacker’s ROI
Mental model: cyberattacks are a business.
Attackers have costs — they expend resources on researching and acquiring information. They purchase hardware to implement attacks. They need some return to stay in business. Our role is to put them out of business by (a) making it expensive for them, (b) limiting their income, and (c) finding leverage while doing it.
(c) needs some explanation. Leverage is the presence of asymmetric costs i.e. defensive measures that have small marginal costs for us, but substantially increase the attackers’ costs.
Example: encrypt Internet traffic by using HTTPS everywhere.
- Marginal cost to us: in 2024, it is very cheap to implement. Most cloud providers offer automatic certificate renewals.
- Marginal cost to attackers: very high. It is a lot more expensive compared to plain-text traffic.
For (b), start by assessing the attackers’ potential income from our organization. Do they want to sell our data? Do they want our ransom? Do they want to impersonate us or our customers and execute some privileged action?
Two: Diminishing Returns
Mental model: buying marginal defense with each marginal dollar.
Our role is to find our organization on this curve. Ask your Security team: where would you spend our next dollar, and what marginal defense does it buy us?
In other words, ask for a prioritized sequence of investments, in terms of both time and money.
Some examples I can think of:
- Dependabot vs Snyk: if we already have Dependabot scanning our application’s dependencies, and our cloud provider is already scanning our images, what is the marginal value of procuring Snyk? Is it marginally better scanning results, better output, or an entirely different product?
- In-app kernel access scanners: if we already have container orchestration, and other controls limiting what these containers can do, what is the marginal value of in-app kernel access scanners?
- SSO everywhere vs SAML: if we already have Single Sign-On with Google on all applications our employees use, what is the marginal value of migrating all of that to SAML?
Going deeper into the last example: SAML allows us to limit which employees have access to a particular app, instead of allowing anyone who has @myorg.com to get into every app. If we are a 20-person organization, this might not matter. If we are a 200-person organization with several contractors, then this matters more.
The key benefit of this mental model is that it forces us to evaluate where we are and where we want to go next. An organization without any controls over its production infrastructure will get a lot of value from in-app kernel access scanners, but another that already has hardened, segmented, Principle-of-Least-Privileged-policy-locked-downed containers on GCP Cloud Run would not.
Three: 3 Types of Security (Generally)
Mental Model: we are protecting these
- A: Protecting Our Employees: what are our employees able to do, and what can attackers get from them?
- B: Protecting Your Assets (usually Data): what assets do we have that are valuable, and what can attackers do with them?
- C: Protecting Your Customers. How can attackers get to our customers? (We can sell these features for a price.)
When evaluating additional defense measures, it is helpful to determine the marginal value for A, B, or C. When determining our organization’s risk, we can take into account the attackers’ ROI for each, and use that to build a prioritized roadmap.
A and B are often addressed by compliance programs. C is how we add value in the highest tier Enterprise pricing plan that we offer our customers.
Cheatsheet
This is a list of commonly used cybersecurity jargon and acronyms that are very confusing to most people, explained in simple terms.
- Authentication: establishing the identity of a user i.e. sign-in, login.
- Authorization: the permissions and privileges that a user should have after they have been authenticated i.e. groups, roles.
- SSO — Single Sign-On: the user signs-in to one centralized service, and that service lets them sign-in to other services and apps e.g. I sign-in to my Google account, and with that I can get into all my apps. This is way better than having users create passwords separately for each app. Important: this does not refer to any specific technology or software. SSO describes a requirement or pattern.
- SAML — A commonly used protocol for SSO. Most organizations start with having employees use “Sign In With Google” to sign-in to everything. Eventually, organizations want to limit who can use a specific app, and migrate to SAML using Okta, OneLogin, or a similar directory service.
- SCIM — System for Cross Domain Identity Management. It lets us proactively create a user account for that user before their first login attempt. It also lets us manage their groups and roles from the directory service.
- SIEM — Security Information and Event Management. A sink for all the logs and events that our Security team cares about so they can review. Usually comes with search and alerting.
- HSTS — HTTP Strict Transport Security. When enabled, the user’s browser redirects HTTP (plain-text traffic) to HTTPS (encrypted traffic). Without this, the webserver does the redirect. This protects the first bytes of unprotected traffic from capturing and tampering.
