How can Developers Secure APIs in each phase?

Joe then took the example of a Microservice code to demonstrate how developers can secure it in each phase, and what one an do to get reusability in there, and get tools in there that help to make developers' lives easier - the paved road concept.

To get a better insight into this process, check out the full webinar here.

Here’s the process as Joe describes it-

Planning and Gathering Requirements

Joe explains how the standards mentioned above, such as OWASP OPENSAMM, provide good ways to summarize what happens in this phase. Basically, you're going to say - what are we doing and what are all the security requirements that apply to it?

You need to have code that defends against both the regular OWASP top ten and the OWASP API top ten because they both apply.

Design the code

The code that you just gathered requirements for, you're now designing it or reusing a design that you already did. In Agile methodology, thorough planning and design are essential before diving into coding.

”You need to think about it, you can't just jump in”, Joe says.

By fostering reusability in design, such as creating libraries for common functionalities like OAuth, development efficiency and security can be significantly enhanced across projects.

Build the code

Joe breaks this step down into two parts- Writing the code, and building it.

You've got some requirements listed here, you've got design, and you've got some tests, but no code to test unless you have a developer.

So this is one of the key portions where you have to write the code security, or better yet, you use Secure-By-Design. And in the design phase, you design some libraries which you build once, and then for every Microservice (for example), you reuse the libraries.

But there's still a lot of code writing here because if you build an Oauth library or let's say a logging library, that's nice and simple, the developer still has to call that library. They still have to pass the right information to that library. So there's a lot of integration that always needs to happen, no matter how you try to make things reusable. And that integration can be challenging.

Test the Code

Here's where we start building things and getting tools involved. We've got code written here. In order to test it, you have to use the CI/CD pipeline or some other reusable building methodology.

And that's where you would put some testing in there. Joe outlines that you probably want to get some DAST testing in there that exercises the various different URLs that can be called in this API because SAST testing doesn't know how to track one thing to another.

Acceptance and Deployment

There's a lot of API specific things that need to happen at this stage, like an API Inventory. For example, an API gateway will not route traffic to a Microservice it doesn't know about. And in fact, you have a problem with developers deploying their own Microservices for their own purposes and that may not be known by the company, and may not be supported.

These are called Shadow Microservices, Shadow APIs

The way to stop that is to say everybody has to use the API. No traffic can get to the Microservices without going through the API gateway. And that means you need an inventory. This is exactly what Akto does, check it out.

The CI/CD pipeline is going to operate here, but in addition, you need to ensure that you have an inventory and that you can check it so that you've got a tool that checks which APIs are allowed to run, who is talking to them, what kind of data are they sending there.

You need some DAST like testing that operates on the running Microservice after it's been through the CI/CD pipeline and it's deployed, maybe to dev or test or prod, you need that kind of testing and maybe other verifications as well.

You need to scan the operating Microservices and periodically inspect the traffic, create behavior models, trigger alerts if anything's wrong. Also, there's other types of testing here that would apply to everything, but these bold features of inventory discovery and scanning are kind of specific to APIs. Anything else you build should also be red team tested.

Webinar Conclusion

By designing something carefully, you avoid developers introducing bugs that you have to find in the testing phase by building libraries.

People use it for lots of different things, but Joe believes that ‘shift left’ means you move work from later phases of the SDLC into the design and maybe the requirements phase. And that's where you get a win, because the earlier in the SDLC you fix things, the cheaper they are to fix, perhaps even up to 100 times cheaper to fix versus after you deploy it.

So this is the idea of the paved road. Put stuff that developers can do to improve things in every phase of the SDLC. And that way you shift left.

That way you reduce things and make it easier for everybody, and reduce risk.

Some API Security in DevSecOps Need-to-Knows

How do you convince developers about slowing down CI CD pipeline for security testing?

Usually don't want to slow down the CI/CD pipeline for security testing. You actually want to make your tests run in such a way that it's fast. It may take time to get there, but a lot of people will do a phased approach where they start their CI/CD pipeline, or maybe they start the process of inserting security into the CI/CD pipeline by just starting with a few simple tests that do not generate a lot of false positives.

And you know, when that test fails, it's serious. And that's when you want to stop the CI/CD pipeline and break the build. You start with that, you build developer confidence in that and then you gradually add more things as you get better at writing tests for a CI/CD pipeline. But you make your test fast, and a lot of how you do this is dependent on what kind of company you are, what kind of software you're writing. Emphasize the need for security separately and you build the CI/CD pipeline such that it minimally interferes with development and only when there's something serious going on. That's one thing to do.

And then DAST testing, for instance, would be separate from the CI/CD pipeline, and you could put a different type of testing in there.

In the sea of false positives, how do we deal with alert fatigue?

It varies from tool to tool and environment to environment, but typically there's some kind of configuration that you do to reduce false positives or you change your tests to reduce false positives. But it's a long process, typically, for the Appsec team to dial in on everything.

Maybe you don't want to do API tests unless you're actually testing an API. If you're testing a mainframe application or something that doesn't provide an API, maybe you shouldn't run those tests because they're going to give you false positives.

And so much of this is dependent on your environment. Maybe you should run tests that are specific to what you're testing. Maybe you should clean up and improve your tests. Maybe you should improve the tolerances and the configuration of your tool that varies from tool to tool. To avoid false positives, mention the name of the tool.

To get started on integrating API Security in your DevSecOps pipeline, check out Akto’s resources.

In the mean time, stay tuned for more exciting events from Akto! 🚀