Agile methodologies have become so pervasive in the tech industry that, even if you’ve never officially followed an Agile process, you’re probably familiar with some of the terms and approaches. “Shift left” is an Agile concept that’s recently been getting more attention. The phrase refers to the common left-to-right representation of the software development lifecycle – when you “shift left” on a certain aspect of your API program, you are committing resources to it in the earliest phases of concept development and design. Resources are limited, so choosing to “shift left” in one area might seem like it will shortchange other aspects of your API programs.
When you build or integrate a new API, you’ll likely hear at least one or two voices pushing you to emphasize security. Listen to that advice. Security is not a tradeoff – it’s essential. When you integrate security into your API design process early on, you build a more durable product that requires less intervention.
Treat Security as a Feature
Imagine you are shopping for a new car. It must get you and your family where you need to go—essential functionality comes first. But while additional features like heated seats and a high-performance engine are enjoyable, safety is non-negotiable. If you knew that one car manufacturer had a much stronger safety record than another, your choice would be clear.
Thinking of your API as a product requires you to see it from your users’ point of view. As you consider more than a car’s basic functionality, your users evaluate your API based on performance, add-on features, and security. Increasingly, API consumers are waking up to the fact that security in their API integrations is as essential as safety is in a car.
When your developers and users know that security and privacy are baked into your product from the start, they gain confidence to innovate and build. “Shifting left” on security is an investment in a smooth API journey.
Design Security for the Real World
Let’s take a moment to consider how software vulnerabilities turn into security incidents. The general pattern often goes something like this:
- Developers at Company A write API code that has a bug. No one catches it in code reviews or testing, so it goes to production code.
- A hacker notices the bug and realizes that it could be used to gain access to secure servers with a basic level of employee authorization.
- The hacker discovers several companies using Company A’s code but notes that Company Z seems to have relatively lax procedures for identity verification through its live support.
- The hacker targets Company Z and looks for an opportunity to do some “social engineering.” Eventually, the hacker convinces a support representative to reset login information for an employee account.
- Once inside the authentication barrier, the hacker deploys the exploit of Company A’s code on Company Z’s platform, gaining access to customer data and server capacity.
It’s likely that neither Company A nor Company Z will notice this breach immediately, which means this same exploit could be reproduced on other platforms using Company A’s API.
Not every company using Company A’s API will be equally vulnerable to attacks, though. Notice how many human failures occurred on the path to this exploit! The reality is that a large majority of security exploits and data breaches result from human error.
An API program that leaves security for the “right” end of the cycle is often more susceptible to human error. When your security strategies are all based on real-world testing and patching, you often won’t discover vulnerabilities until they’ve already been released into the wild. A “shift left” approach gives you room to design comprehensive API security from beginning to end. Your security strategy needs to address human error in three ways:
- Reduce your vulnerability by adopting best practices for data and network architecture.
- Implement a development process that makes security as automatic as possible.
- Build a security-first culture to strengthen your last line of defense.
We’ll explore each of these in more depth below.
Shrink Your Vulnerability First
You are already making decisions about data and network architecture to achieve better performance and reliability. Security should get the same attention. In the early phases of concept development and design, your security focus should be on architecture that limits the potential damage from attacks.
Two core principles in security engineering are that smaller attack surfaces make attacks easier to prevent, and data segregation makes the potential damage from attacks less critical. In the case of an API program, this might mean designing two separate APIs to serve data with different levels of sensitivity or locating only access to certain endpoints behind a firewall with added security. In either case, these are choices that you will want to make early in your design process to avoid costly refactoring or unnecessary complexity later.
In addition to “shift left”, another phrase you’ll often hear in security discussions is “zero trust”. It’s an expansion on the ideas above based on the principle of “never trust, always verify”, with the goal of constructing a simple path to provide each user with the minimum possible access level. True zero-trust architecture is difficult to achieve at an organizational level, but taking steps in that direction can minimize risk. Here are a few key zero-trust principles you can employ in your APIs:
- Segregate data, so that your most vulnerable data is never connected to your most widely-used APIs.
- Enforce your strictest protocols for backup data, hiding it behind firewalls with limited access.
- Require frequent renewal of access credentials for internal and external users, even for resources that aren’t highly sensitive, and take steps to improve password security.
- Build your network and data architecture around a “need to know” principle: if only three people will ever need full access to your most sensitive data, only those three people should have access. That access should require multi-factor authentication on a regular basis.
For API-driven businesses, some of these practices are particularly challenging—and as a result, APIs are a frequent target for attackers. Since APIs are designed to make sharing data easier, getting closer to zero trust requires some additional considerations:
- Secure all APIs with tokens, encryption, signatures, and other means. Carefully consider the right authentication and authorization solution for your needs.
- Think about your API users in terms of “user types,” and allow access to the smallest group of users possible.
- Upgrade as soon as possible when patches are released for security vulnerabilities in APIs you consume. A surprising number of attacks happen to third-party users who haven’t deployed all available code fixes—don’t be one of them!
- Build in safeguards around third-party tools you incorporate in your APIs, so your users are not inadvertently exposed to risks.
- Reconsider the Robustness Principle. Convention says APIs should be “liberal in what you accept,” but that comes with risk. Attack surfaces matter in terms of what data an attacker can view and what they are able to send through your API endpoints.
Automate Security Features
The next step in securing your API is building automated security engineering into your development process. Code reviews alone are a terrible way of managing security—they’ve proven very ineffective, and even when they identify vulnerabilities, they push the process of fixing those problems until quite late in the development process, wasting significant amounts of time. Development teams consistently overestimate their ability to fix bugs late in the development cycle, resulting in out-of-band patch releases and breaking changes.
Security engineering works best when it happens at a system level, increasing reliability and creating fewer disruptions. The practices we outlined above are one approach; reducing attack surfaces, segregating data, and making privacy the default will all translate into fewer potential exploits. The second step is ensuring that these practices are implemented consistently throughout your API programs. This approach is sometimes called DevSecOps, and it aims to integrate security into your code lifecycle in a “hands-off” way.
The goal of DevSecOps is to reduce the potential for human error. Unlike code reviews, which rely on individuals to identify small details that have impacts on hugely complex systems, DevSecOps automates code compliance with threat modeling, code analysis and linting tools, image scanning, and other processes built into the software development lifecycle. When you deploy these tools, you are building in multiple levels of scrutiny that apply objective standards, comprehensive bug tracking, and large processing power.
It’s no knock on your engineering teams to say that automation would improve your API security—a DevSecOps approach allows them to focus on designing and building great products, and it drastically lowers the chance that a bug makes it to production. A DevSecOps approach pushes the most thought-intensive discussions of security to very early in your product lifecycle, then uses automated tools to do the daily work of applying the standards you’ve chosen as you are building. The end result is fewer breaking changes and less stress for API teams.
Build a Security-First Culture
Whatever technical solutions you ultimately implement for your API programs, it’s crucial to remember that technology alone isn’t enough. No technical solution is failsafe, especially not as the security landscape evolves. To keep up with the pace of change, your organizational mindset needs to change, too.
Creating a culture of security is not about instilling anxiety in your employees. Instead, empower your teams with the knowledge, engage them in transparent conversations about risk, and create pathways for surfacing and tracking vulnerabilities. Tim Brown, the CISO of SolarWinds, has gotten a lot of praise for his handling of a major exploit in 2020. In an interview with The Daily Swig, he outlined his philosophy: “One of the biggest lessons we can show the industry is that you get respect from owning what happened and then recover. You don’t need to hide.”
Building a security-first culture is an investment in the long term. When you have open conversations about all aspects of risk management—technical and human—your employees can do their work with greater confidence, knowing that there are systems in place to reduce risk and address problems proactively. If you can consistently address security concerns early and identify clear actions to reduce human risk, you will increase stability for your API products and reduce distractions for your organization.
Adjust as You Grow—One Size Can’t Fit All
The work of security is never done. You will need to continually revisit the practices you put in place, re-engineering solutions and re-training employees. Remember, though, that security is a crucial feature of your API programs. Just as you continually iterate on other features of your product offerings, you will need to iterate on your API security, incorporating it into your design review process throughout the product life cycle.
The secret ingredient for a successful API security program is critical thinking. There are no hard-and-fast rules, no guaranteed rubrics. Industry best practices are great guidelines, but they are just a starting point. Work to develop an in-depth understanding of the unique technical and human factors that impact your organization’s security needs. You’ll need to engage people from throughout your organization, from customer support to finance to engineering. Listen to their concerns, learn how they use your APIs, and watch how they handle known vulnerabilities. Then build security practices that address your specific needs.
Design-first APIs can also be security-first. The call to “shift left” can be overwhelming, with so many different ideas competing for top priority, but when you treat security as a feature and move to a proactive approach, you’ll build a better API product that you can deploy with confidence. Stoplight can help with tools for API governance and visibility.
We are prioritizing security, too, making our own efforts to be transparent and collaborative in addressing vulnerabilities. It’s a goal we know we share with Stoplight customers, and we want to help you build with confidence!
If you want to learn more about infusing security best practices in the design stage of your API development, tune into our Security Trends Webinar below.
