Principles

Let’s first describe some principles that should in order of importance.

1. Pragmatic Security

When creating an API the primary goal is to solve a problem for a user or organisation. But we don’t want to create new problems by introducing vulnerabilities.

When designing or implementing a new feature always consider how it could be abused and strive for security by design.

Be pragmatic, solve problems don’t create new ones.

2. Use Standards & Frameworks

When it comes to security, many organisations face the same problems, luckily as a result we can also use the same solutions. In the world of software engineering we are blessed with great open standards organisations and communities such as OWASP, IETF, the OpenID Foundation, and the many open source communities.

When faced with a check if one of the tools you are using might already have a solution or look online if there are no current best practices on how it can be solved.

For example, the front-end framework you are using probably has a way to obtain OAuth tokens, and don’t implement JWT validation yourself, your API framework or standard library probably has an implementation of JOSE already.

But be ware of the third-party risk, don’t just add any random library as a dependency.

Using standards and frameworks ensures interoperability, not only internally but also when working with vendors, partners and customers. It also ensures that we use reviewed solutions and implementations.

3. Layered Security

  • ZTA
  • …

Guidelines

Threat Model

The first step when considering security for any project is to start with a threat model. Don’t know what threat modeling is? Take a look at the Threat Modeling Manifesto which gives the following definition.

Threat modeling is analyzing representations of a system to highlight concerns about security and privacy characteristics.

The manifesto describes four questions to ask to start threat modeling.

  1. What are we working on? (Create a model)
  2. What can go wrong? (Identify threats)
  3. What are we going to do about it? (Design & implement mitigations)
  4. Did we do a good enough job? (Review & repeat)

Plenty has been written online about threat modeling, so there is no need to explain it further in this note. But I would like to highlight the following.

Threat modeling as a team activity, not a CISO requirement

Threat modeling should be an activity practiced by the team designing and implementing the system. It’s a fundamental way of doing pragmatic security by focussing on mitigating the threats that really matter.

Creating and discussing the potential threats your system faces is a great way to get the team to think about security and have security by design.

Unfortunately a threat model is often seen as a requirement form the CISO-office which might require a DFD-diagram and threat categorized with STRIDE so they can check the checkbox on their compliance spreadsheet without really caring about security. Threat modeling without involving the team is a waste of time.

Model your way

Data-flow-diagrams DFD’s and STRIDE can be great tools, but if you already have other models of your system you should not have to create a new digram form scratch.

Continuous Threat Modeling

When adding a new endpoint or making changes to an existing one, make sure to update your threat model. Threat modeling is a continuous activity and not a one off.

Further reading

Pentest

Internet facing API’s should always be pentested.

Monitoring & Logging

Ideally a security operations center (SOC)

Secure your transport layer!

References