Security teams divvy up their time between fundamental and exceptional mitigations.

Hopefully, more effort is allocated to the former.

The fundamentals go by many names: best practices, standards, checklists, maturity models, and others. A practice that mitigates large numbers of risks with a common pattern is fundamental. (Examples below)

An exceptional risk isn’t mitigated well enough by fundamentals. Attention is taken from fundamentals to mitigate exceptional risks.

Here’s a health analogy:

  • Fundamental : Regular exercise, good nutrition, community involvement

  • Exceptional : Anti-bear mace, shin guards, self-isolation

Discussing fundamental and exceptional mitigations

Fundamentals are portable concepts. Many security teams and organizations build these familiar mitigations for familiar problems. Thus, a missing fundamental is often viewed as a gap at an organization.

Exceptional mitigations are not seen everywhere and are appropriate for risks that are conditional to the organization.

For instance:

  • A cryptocurrency firm works on custody risks.
  • A social media firm works on misinformation and spam.
  • A hardware firm works on supply chain risks.

The skills and talents involved with exceptional mitigations are not entirely portable from one firm to the next. However, each have someone working on single sign-on and logging, which are fundamentals. Exceptional mitigations are what make security teams unique.

There is no universal advice on how to spread efforts between fundamental and exceptional risks other than to use this model to hunt for an optimum at your own organization to avoid large gaps.

Exceptional mitigations come from decisions to leave the comfort of fundamental approaches. These decisions can be rather obvious, or, arrived at through risk management.

To summarize: The fundamentals come first, but exceptional approaches are always necessary.

The following resources aim at building well-rounded, fundamental security teams. Please message me if you find something you would like added here.

The following are example fundamentals described as risk based OKRs. You can use them to bootstrap a brainstorming and planning session with your earliest objectives.

Fundamental OKRs

As discussed in management, OKR is an Objective and Key Result. The objective is a direction. It’s where we want to go and leads the behaviors of people around us. The key results are actionable tasks, milestones, or other measurable things we can complete to get there. They can be binary (completed/not completed) or some other value (interview eight candidates).

Ideally, key results closely measure the outcome we are trying to influence. You’ll find this in strict OKR literature and teachings. The knowledge workers you’ve recruited would then organize themselves into initiatives to pursue this outcome.

However, we discussed in foundations and management that direct, measurable outcomes are not readily available when targeting the reduction of risk. Second order results are often relied on instead.

For strict OKR practitioners, the following examples will include initiatives. The traditional risk-based key results are part of the objective description instead. The bullets are initiatives towards those results. For more discussion about the difficulty in measuring risk-based key results, see management.

✅ Objective: Centralize and improve logging

We want to ensure the logs that would be valuable in an investigation are accessible and searchable in the fewest places as possible. Incident investigation time is shortened. We are more confident about incident causation. More employees are available to assist with investigations.

  • Decide/Build/Buy a central logging platform or service.
  • Decide on critical logs that are critical for investigations.
  • Decide/Build/Buy an ingestion strategy.
  • Design procedure/playbooks for important investigations.
  • Test playbooks.

✅ Objective: Improve employee responsiveness in reporting incidents

We want to increase the probability that an employee will report an incident or exposure they observe while decreasing the time it takes for them to report it.

  • Create #security aliases across chat, email, and tasks.
  • Launch a propaganda campaign to evangelize the #security alias.
  • Maintain a 1 hour SLA in #security ticket acknowledgment for one quarter.

✅ Objective: Reduce the risks associated with vendors

The probability of a vendor incident is reduced. A vendor incident would be remediated quickly. The probability of a vendor disclosure is increased.

  • Establish process with legal to escalate data contracts.
  • Scan expenses and corporate credit cards for shadow IT vendors.
  • Add vulnerability and incident disclosure guidelines to high-risk contracts.
  • Add penetration testing language exceptions to all contracts.
  • Build rolodex for vendor security teams.

✅ Objective: Reduce the risk of insider abuse

The probability of an insider incident is reduced. Causal insight is gathered quickly from an insider incident. The impact of an insider incident is reduced.

  • Improve log coverage in administrative tooling.
  • Build detection for high-risk actions on high-value accounts
  • Build threshold-based approvals to account deletion/account transfers.
  • Build employee role grants through manager approval.
  • Build auth token service based on customer approval

✅ Objective: Reduce the risk of an endpoint compromise

The probability of an endpoint compromise is reduced. Endpoint theft has a reduced likelihood of being unencrypted. An endpoint breach due to a known, patchable vulnerability is less probable.

  • Discover, estimate volume, and retrospective unmanaged hosts
  • Improve HDD encryption coverage past N%.
  • Choose/Eval/Deploy EDR product
  • Build and test termination and theft runbooks.
  • Decide on patch strategy for highest risk endpoint vulnerabilities.

✅ Objective: Improve responsiveness to incidents

Reduce estimated incident resolution times. Decrease estimated time to coordinate the incident team.

  • Write an incident response plan.
  • Create rolodex for external IR partners
  • Select and train internal IR partners
  • Set up internal communications for compromised scenarios.

✅ Objective: Reduce the risk of remote IaaS API compromise

The probability of IaaS credentials being accessed is reduced.

  • Design/Deploy network restrictions.
  • Design/Deploy a strong authentication strategy.
  • Choose/Demo/Deploy log ingestion pipeline.
  • Choose/Eval/Deploy secrets storage.
  • Spend N days on vulnerability finding. Fix all critical issues.

✅ Objective: Reduce our risks of account compromise

The probability of an adversary accessing an employee account is reduced.

  • Choose/Demo/Deploy SSO and MFA Vendor.
  • Create a rollout plan for company-wide SSO.
  • Estimate # of “Shadow” IT applications being used. Migrate auth towards it.
  • Build and deploy “Shadow IT” detection. Migrate auth towards it.
  • Follow a similar rollout for infrastructure and production.

✅ Objective: Lay groundwork for secure development practices

The probability that a vulnerability will be found and exploited by an adversary is reduced. The probability that leaked source code results in an intrusion is reduced.

  • Discuss / Decide on engineering quality standards (with ENG)
  • Discuss / Decide on secret storage (with ENG)
  • Add security engineering to the product development workspaces.
  • Build security “boot camp” for engineering onboarding.
  • Build vulnerability management standards.

✅ Objective: Lay groundwork for future detection efforts

Increase the probability of discovering an exposure before exploitation. Increase the probability that a true-positive detection will be handled as an incident.

  • Design/Build/Deploy log management pipeline.
  • Decide on alerting and detection strategy.
  • Recruit and select on-call rotation.
  • Buy/Build on-call incident platforms.
  • Build detection/alerting for three risk areas.

✅ Objective: Lay groundwork for future risk management efforts

Make investments in mitigating the most significant risks.

  • Create a risk register.
  • Interview n organization partners and model top risks.
  • Decide on future periodicity of re-assessments.
  • Update “priority risk” documentation.
  • Represent risk priorities in planning meetings.

✅ Objective: Lay groundwork for finding and fixing

Vulnerabilities will have a low probability of being found and exploited.

  • Spend n days vulnerability finding.
  • Write up vulnerabilities for policy discussions.
  • Decide on SLA’s / Criticality with IT and Engineering.
  • Create a central location for known vulnerabilities and associated tasks.