Transcript
Losio: I would like just to give a couple of words about today's topic, what we mean by best practices for API quality and security. APIs are essential in software development. It's nothing new. It's been for many years now. They are essential to access and process cloud, third party services. In this roundtable, we are going to explain how to protect our API, how to discover, for example, API related security issues. We will discuss how, in general, we can as developers engineer to improve the quality and the security in our API design and management. As well, what tools we can use. For example, API gateways, open standard, can they help us? Let's see how we can implement and manage API projects with a reasonable security strategy and development mindset.
Background, & Journey to API Security and Quality
My name is Renato Losio. I am the Principal Cloud Architect at Funambol. I'm an InfoQ Editor. I'm joined by four industry experts on API quality and security. I would like to give each one of them the opportunity to introduce themselves and give a short introduction on, basically, their journey to API security and quality.
Aravena: I'm Pedro. I'm a software engineer, and now developer advocate for a security company. We basically have two products right now. One of them is related to APIs. We're working on a platform where DevSecOps teams can choose to build applications securely, and all about modern threats. That's my API story.
Malik: I'm Dave Malik. I'm the CTO and Chief Architect at Cisco. I run the Americas CTO function. More importantly, we're working with a lot of our clients who are building cloud native applications and driving large scale automation. APIs are the underpinnings of large scale automation and next-gen application development. We're spending a lot of time with them, and really guiding and learning in terms of, how do we drive security, good API hygiene, and versioning? Then really taking the entire DevSecOps notion all the way to the left, where API security is embedded into the design process and the development process.
Zagroba: I'm Elizabeth. I am the quality lead at Mendix. I'm serving our data and landscape department. I support seven different teams as they build products for our low-code platform. The thing that we build allows our enterprise clients to build their own applications. My department is specifically looking at the problem of, how do you use and share APIs across a whole company? How do you catalog them? How do you drag them into our tool to be able to use them easily? What standards do we support in doing that?
Verloy: Filip Verloy. I'm the field CTO for the EMEA region at Noname Security, which is a startup that focuses purely on securing APIs. Before that I was at another startup for about six years building an API first platform. That's my entry to the world of API. I've been using it as a practitioner. Then I figured out that we also need to secure them. That's what I'm doing next. Today's point we're also looking at API security, both from a developer perspective, so shifting left, as he pointed out rightfully, all the way into production, and how both can influence each other into a better design going forward.
API Quality and Security, the Starting Point
Losio: What do you think is your first advice to someone like myself in the dev world that has worked maybe for many years, as a developer, as an engineer, but has not paid too much attention on API quality and security? He knows that it's out there, but it's not really his primary focus. Where should someone start?
Verloy: I think that's essentially a good description of how most people look at APIs. Everybody knows APIs are out there, they have shifted in function quite a bit. If you go back a couple of decades, or maybe just a couple of years, not so long ago, APIs were mostly used as a configuration function. You could maybe use an API to change the settings of a network device or something like that. That's the assumption that I feel a lot of people still have fun talking about API security in general. APIs are now everywhere, they've become very prevalent. They're the pipelines into the data, as well these days. We need to spend a bit more time understanding really what APIs are, what the capabilities are, and especially from a security perspective, potentially what type of vulnerabilities they would enable. From a developer perspective, it's a good first step to really try and understand the API landscape in general, like what type of APIs are there? Then, what type of coding best practices could you use from a developer perspective to build standardized and consistent APIs? I think consistency is definitely key when it comes to building secure APIs.
Losio: Pedro, I read one of your articles about API security recently. I wonder if you have anything to add and anything to share in terms of how to help a developer that is not really on the API yet, more so on the security aspect.
Aravena: Everything that Filip has said, 100%. As a developer advocate for an encryption as a service company, I would add something around encryption. I think it's pretty important to understand the concept and how to do it. Not only when data is at rest, talking about APIs, but also in transit. I think in this encryption scenario, the API would use TLS. That is pretty important to understand, and authorization tokens to transmit data securely. The data that the API is accessing should also be encrypted. I would also add about encryption, all the data is key for this API development process.
Losio: It's easy as a developer to think, I got the basics. I know that then it's always pretty hard to work on it. More so, it's always pretty hard to work on the quality as well of what you provide to end users. Elizabeth, with your experience of quality and testing on the API, if you have any specific recommendation in that field?
Zagroba: I think I agree with what Filip said about consistency. I would add discoverability to that. Just naming the things in a way where you can tell what is on a deeper endpoint, or having the collection call be the same path as an individual call for a REST API. That's something I'd recommend.
Malik: I think the other panelists are spot on. If you look at, standards are important. In the open source community, you can argue if standards are followed or not followed. The OpenAPI specification is really important, where customers are aligned to in Cisco as well. If you look at some of the tools that are in the market today, such as API Insights, APIClarity, and so on, we will really want to make sure that discovery process is there as well, as was just mentioned. We want to understand what is out there, because most customers don't even know what's out there: most developers. Once we understand what is actually running in our infrastructure, then we can actually start scoring those APIs and seeing if they're secure, or not. Then as new development paradigms and new software is getting pushed out, is it conforming to our standards? One is, you have to know what the standard is. If you don't know what's out there, go discover it, to the point that you made, and then secure it, leveraging mechanisms such as TLS. Then authentication mechanisms, policy and identity integration. Visibility is really important. Then start integrating into your DevOps pipelines as you're driving through VS Code and other tools.
The Shift Left Mindset
Losio: I was wondering, as I say, it's really not my main area of competence. I've been hearing the word shift left for the last few years. I even think at this point it's overused, if I'm the one who uses it so often. I wonder what experts in the field think about the concept of a shift left mindset? How do you address that with your customer? How are you engaged when you're creating and [inaudible 00:11:27] with that?
Verloy: If you think about shifting left from a developer perspective, so I think we are asking developers to do more. There's also now this big push that I see in the industry around making sure that we don't burn people out. The idea is, we want developers to not only think about security early on in the design process, we also want them to think about observability, and so on. We're trying to push a lot of these things left, hence the term shift left, so earlier in the development lifecycle. I think, at least from my perspective, something that could be really helpful is to make sure if you introduce security earlier in the development lifecycle, you do it in such a way that it doesn't really become an additional barrier to the developer.
Dave mentioned DevOps and things like CI/CD pipelines. I think it's important to build tooling that neatly integrates into the existing workflow of a developer today, because we cannot really expect all developers to all of a sudden be security experts. What we can do is we can give them the tools and the standards so they can leverage those in the same workflows they are using today, which will hopefully lead to a better outcome. Giving them those tools and giving them those standards, those can be influenced, of course, by security professionals and security specialists, hopefully, then working together to something that makes sense from a developer perspective. In my perspective, nothing chases the developer away more quickly than saying, here's another tool with another web interface that you need to log into, to develop your code. People won't accept that. It needs to be a natural part of their workflow. I think that's the only way we'll get there, otherwise, shift left I think is dead on paper.
Security as a Consideration, from the Inception Phase
Losio: Shouldn't API security be considered from the inception phase, basically, in terms of design?
Malik: One is, I think we would all agree that security is important. That goes without saying. I think where folks are lacking in the understanding some time, and at the community level, we're all raising awareness, is agreeing on what the security standards are for that organization. Because someone in healthcare maybe have different security standards, or more tighter than someone in a non-regulated industry. Setting those standards at the firm level is super important, and aligning to industry specifications, so these are not custom. Then the developers can start embedding those pieces into their code, and those processes, which are really important.
The other piece is around automation. Security automation is still fairly early in the development cycle, because a lot of our developers are coding on multiple platforms, multiple languages, so on and so forth. How do you ensure we can do things at scale? That's what developers also are really considering, any tool that we build or any process that we build, how can we do it at scale from an automation perspective? Then fix the bugs or fix the code or the vulnerabilities when we find them. Sometimes they're in a backlog. Typically, backlogs, sometimes they take a while to groom. I think we all know that. Hitting left, and at the point of inception of finding a security vulnerability and automating the fixes at scale, I think that is a key area for shifting left moving forward.
Encryption at Rest and Encryption in Motion
Losio: I notice as well an interesting comment about encryption at rest and encryption in motion. There are two aspects: some people forget, and some people take them for granted and they don't mention them. Absolutely, I think that everyone knows about the importance. Sometimes I have the feeling that cloud provider and service provider, maybe they make it harder to use them in the sense that it's just maybe a checkbox, but it's more expensive, or it's not the default or whatever else. I don't know if anyone has any experience with that, or any suggestion on how to overcome any security barrier in the sense of the encryption side, it's often seen as a limitation.
Security Standards for APIs
Which security standards are available for APIs specifically?
Verloy: To Elizabeth's point earlier, she mentioned the REST APIs, for example, so when it comes to APIs under just security standards, so many standards are available. In IT in general, it's something we like to do. We can't really agree on anything so we just create a new standard. From a security perspective, it's hard. What I'm seeing, at least in my customer base is that the vast majority is using RESTful APIs at the moment, probably like 70%, maybe even 70%-plus. We've seen GraphQL. We've seen some gRPC. From a security perspective, if you look at the full picture, and this goes to Dave's point as well, like if you don't have the full oversight, the full inventory of everything that you're using, if you can't see it then you can't secure it. Oftentimes, we see that customers are using SOAP XML. Here, they're using GraphQL. Here, they're using REST APIs. From a security standards perspective, it's a tricky scenario, because, let's compare a RESTful API versus a GraphQL API, for example. From a network security device perspective, REST API for each and every piece of functionality, you have a different endpoint, essentially. You could protect each endpoint individually. With a GraphQL API, you typically have one endpoint. Depending on the query, you get some piece of data back, but it presents itself with all of the functionality that it has from that API perspective. If you put a security device in between, you can't really predict at all, what is going to happen, because almost every use case, or every user talking to that API endpoint is trying to generate something different in terms of output. Protecting APIs, in that sense, becomes really tricky.
Of course, from a security standard perspective, if we look early on into the development lifecycle, I think is where we're converging on. There's many things you can do, for example, linting, making sure that you have consistency in the type of API specification that you can deliver. That's something you can do on the basis of external validation. That validation is something that you as an organization can create yourself. You can have an external rule base that says, if I'm going to design an API, I'm going to compare it with this rule base, so I'm going to do my linting operation. If it doesn't fall into that design aspect that I agreed upon before, then I'm not going to pass it down the line as a developer. There's many ways I think in which you can look at security standards from an API.
Differences between Internal and External APIs
Losio: Elizabeth, from your perspective, do you see any difference between internal and external APIs, and how to approach them? Do you have any suggestion in that sense?
Zagroba: The thing that I see with our clients is just making that first call and making sure that they have the authentication details correct. That they know where to set that up. That that is clear in the specification, and that we have examples for them of how to call the API. Just really having a clear spec or a walkthrough, something a little bit more in-depth even, is really what our customers need to be able to work with our APIs successfully. When you have an internal API, a lack of spec or a lack of a clear spec means you just end up going and talking to the other team. You send them a Slack message, or you send them an email, there are other ways around it. Having a public API, either that feedback loop is a lot slower, or that's not the best way to get in contact with the people who own it. Yes, the documentation is where I would start in having a good quality thing externally.
Losio: Dave, do you have anything to add, recommend in that sense? Do you see from your perspective, any major difference between internal, external, or from authentication?
Malik: Ideally, there should be not much difference. Internal APIs shouldn't be more secure than external APIs. It's the same standards. If we follow the same standard, a lot of our products, if not all of them, we use the same APIs that our customers use internally, when we make calls into our own subsystems, microservices. We treat our development environment just like we would give those APIs to external customers, and we build on top of them. We don't really differentiate. Again, the API standards are really important, authentication, authorization. A lot of the issues that we clearly see sometimes, whether it's internal or external, you'll have these zombie APIs or deprecated APIs that folks built at some time. Externally, maybe they may be less relevant in keeping up to date versus internal ones. The versioning becomes very important, that the version that you're doing for internal versus external should be almost identical, if not maybe one release off. You maybe want to test internally before you publish those APIs externally.
Yes, versioning and deprecated APIs that are just sitting out there for a long time, open source APIs, we tend to see a lot of the folks just being a little more relaxed. That's where vulnerabilities creep in. We have tools from Cisco there we're obviously contributing to in the open source community, that really look at a lot of these problems and making sure they have versioning, do we have the right change log? Can we keep track of everything that was changed in the API? What other enhancements are coming in from a security perspective? Just keeping a closer eye on it. I think that there should be, hopefully no difference in internal and external. We want our customers to use the same APIs that we do internally.
Encryption, and API Security Best Practices
Losio: Pedro, as Dave just mentioned as well about API attacks and security and breaches. We all know, we all read that attacks are increasing rapidly and security concerns are always there. What are some proven techniques? As a developer, where should I start to consider as best practices to improve the security of my APIs?
Aravena: I believe that all network traffic should be encrypted, particularly API requests and responses. As it likely contains sensitive credentials and data, all APIs should use and require HTTPS. Talking about REST APIs, they use HTTP, so encryption can be achieved by using the TLS that we talked before, like the TLS protocol, and its previous iteration, the SSL, the Secure Sockets Layer protocol. These protocols supply the S in HTTPS. Basically, what I would say for if you're not using a platform that will provide free SSL or somehow, your sensitive data should also be encrypted in the database layer as well. I would say encrypting data, TLS, SSL, and require HTTPS when it's possible.
When It's Ok to Have Something Less Secure
Zagroba: Is there a time when it's ok to have something that's less secure? If it's just an internal API or if it's just for a demo? When would you let some of the stuff go?
Malik: I think we should not let anything go. Everything should be secure from the beginning. It should be just built, ingrained into your DNA. I think, if we give too many choices out there, we're humans, we may make the wrong choice at the wrong time. I think security is paramount, whether it's internal or external, because a lot of the attacks obviously, as we know, sometimes come internally within the organization, as well, whether they're accidental or intentional. At Cisco, we follow a very simple philosophy, trust nothing but verify everything. I think that just getting more embedded into our customers as well as we move more towards a zero trust environment, more even in the development side than the networking side.
Why Security Practices are Sometimes Not Enforced
Losio: I was wondering as well, reading that comment about design-first strategy, basically, build the contract, mock the contract, engage with the customer early and get to the consent. Once the consumer agrees with the contract, the actual development with all the security best practices should be enforced. I love it. The problem is, I always wonder, I see many projects where that doesn't happen. Do you think it's because developers are fundamentally lazy, or because it's a matter of time, resources, or not fully understand that maybe security is not as complex as we think it is?
Zagroba: If you're working in an agile environment, or in particular, a lean environment, you're trying to get the smallest piece of software out quickly. You're not trying to get the whole product out all at once, necessarily. It might be that speed and time to market is a higher priority commercially than having everything secure right away, particularly if you have just a small set of beta customers. I find myself more often in a position of finding, what is the right balance? What have we promised people? How quickly can we get enough out to them, and then add some of those things on later, whether it's refactoring or security stuff.
Losio: You're basically saying that often it's a balancing act that we need to get something out there to test it or to prove that there is a market or any way because we need something live. Sometimes security is not a problem but is seen as an extra effort at the beginning, that maybe I'm not saying people are compromising, but maybe they're sometimes taking some shortcuts maybe.
Zagroba: Or as Filip said at the beginning, not everyone is a security expert as well. Particularly if you are working remotely, and you're working independently for a lot of that time, then building and working on something that you're not the expert in, it may be that it's not the highest quality. My recommendation for that is more pairing and more ensembling, just working together with people at the same time rather than doing asynchronous code review at different times, just so that you can shift some of that thought process left, as we were saying earlier.
Quality That Is Not Security Related
Losio: We're really focused a lot on security. What do we mean usually by quality that is not security related? What do you mean by API quality or more so the third phase of a project, a contract, or any other advice?
Zagroba: It depends on the person. Quality is value to some person who matters, said Jerry Weinberg. You have to talk to the people and decide whether the thing that is most important to them is the speed or the accuracy or the security of it. It will depend on your context.
API Gateways vs. Service Mesh
Losio: I see an interesting question about API gateways versus service mesh. North-South, API gateways, East-West, service mesh. API traffic have different semantics in security, are there any set of best practices in terms of security applicable to each arena?
Verloy: I think we do have to differentiate a little bit between infrastructure related APIs and maybe application related API. If we talk about the service mesh, we're typically talking about maybe a Kubernetes environment or something like that. To Pedro's point, it's going to be using mTLS to encrypt everything between all of the nodes, which is a good best practice. From a, how can we validate API transactions and API communications, it's making our job more difficult. We do have to figure out a way to do that. eBPF could be a good way to help us out there. If you talk about a service mesh versus maybe a gateway or a device like that, you mentioned East-West versus North-South, it does play a role there, to go back to Dave's earlier point as well. If we focus on a gateway, we're going to see only the APIs that are routed through that gateway. We're going to miss probably the majority of the actual APIs that a customer has in use. From a security perspective, that's not going to be good enough, we want to see everything.
The idea really is we have to understand all of the pieces, and this is network, all of the pieces of the network where API communication is happening. That's the only way to truly capture East-West, North-South API traffic in an environment. Service mesh can certainly help for some of that. When we're talking application related APIs, we're typically more into the gateway piece of the house. Again, a gateway is very good, but a very focused security control that doesn't really protect you against the most common API type of attacks. If you look at the OWASP API Top 10, number one on the list is going to be broken object level authorization. You're going to be hard pushed to find a gateway that can protect you against those types of attacks. Because those are typically related to some issue in the business logic inside of the API or the application itself. There are definitely tools that can help us. We must take care not to be too myopic, and really understand API security from a much broader perspective. Step one is get a full inventory of all of the APIs that you have, and then we can talk about securing those. A gateway is definitely a good point, but you need to look at the broader picture.
Risk Scoring
Malik: I think it was around risk scoring, things of that nature. That's very important. If you look at the idea of, how do we score our vulnerabilities, how severe they are, and creating an index for our critical APIs? I think alignment is really important with the developer team and the security team. Sometimes they could be at odds, if you have a risk and compliance and security cyber team in the organization, and you have a pure development team. If we can align on how we're managing and scoring the vulnerabilities on API, so everybody's on the same page, that it's very important that we know this vulnerability is a severity 1, severity 2, severity 3. Severity 1 being obviously business impacting, and these are mission critical, because they are external vendor APIs or partner APIs where you're doing commerce, and they could have immediate business impact. Denial of Service APIs are very important as well to keep track of as well.
Authorization Mechanisms in OpenAPI
Losio: I have an interesting question about authorization mechanism in OpenAPI. Is there any benefit in terms of security in using Open Authentication 2 over HTTP, or JWT, or whatever, or both offer the same?
Verloy: This goes to some extent back to, should there be a difference between internal APIs and external APIs? I do agree in theory that there shouldn't be. What we're seeing in practice, though, is that typically, on the authentication and authorization piece, that's when we start to see the difference, like people are doing like basic authentication, getting a JSON Web Token back for an internal API and happy days. Then external APIs are using things like OAuth 2, and so on, of OpenID Connect. There is a difference in the level of trust that you can assume between those different types of authentication authorization mechanisms. The problem is always going to be that the internal API with good intentions is going to escape and become an external API at some point, and then, now you have an external API which uses basic authentication, which might not be the best idea. I am definitely in the camp of shooting for the highest level of authentication and authorization from a security perspective. Things like OAuth 2 and OpenID Connect, I think, definitely have a role to play.
OpenAPI Specs
Zagroba: The best specs are ones that are auto-generated and that people will read. Whether that's OpenAPI, or some other spec, I think matters less than that they're up to date. I like OpenAPI, but it's a personal taste.
Malik: I would agree. Cisco is fully on the OpenAPI bandwagon, and we conform to like actually contributing to it. We like standards. We like contributing to standards. Anything on standards is super important. We embed that into our solutions and our discussions, and obviously, in the developer mindset.
Verloy: I think additionally, like if you look at OpenAPI, because we're talking about security, one of the major advantages there is I think, it allows you to use a security scheme as part of the OpenAPI spec. You can define authentication and authorization rules, as part of the scheme. Just because it's there, it even helps developers think about it. That's already like a really good step.
How to Drive Open Standards in the Software Development Lifecycle
Losio: I always wonder, as Dave mentioned open standards and their importance. I think we all agree that open standards are important and essential more so to drive innovation. How important do you think it is to contribute to the standard? How does it work in the sense, it's just a big operation, it's just hoping for the best. What could we do? Because now, we already mentioned a few different standards. We agree that it depends on taste, it depends on different things, but how to drive those standards, how to embrace them in the software development lifecycle, as well.
Malik: One is actively contributing, contributing code, contributing to specifications and aligning to specific workstreams that we can go after. An API spec or standard is very broad. Whether it's you going after security, whether you go after authorization, whether you're going after encryption, there's a bunch of areas where folks can contribute to. I think more as you get part of the community, and you're interacting with the community in the industry, you gain a lot of knowledge, but you're also contributing. I think it makes everybody a better person at the end of the day, and then just getting awareness. I think education is something that we can all drive further in the industry, and some of these standards organizations where folks are coming together drives awareness and education, hence in better practices. I learn a lot every time I go in and start reading and looking at all the code that's being checked in, and published, and what folks are downloading, what's active, what's not, and how they're using it in terms of use cases. Which is very important because folks are using code in different ways in their software development lifecycle. Just understanding how people are using certain APIs, is very interesting and you learn a lot from a best practices perspective as well, through being part of a lot of these standards bodies and forums.
Getting Started on Learning the API Standards
Losio: Essentially, the things that you mentioned, a bit of that education as well, and learning is an interesting topic for people, for developers like myself that know what is out there but they don't really have a direct experience with learning the standards, playing with the standard. Do you have any recommendation how to start to work in that sense? Where should I start? Should I start on the problem? Can I learn something new in that space? Whatever it is, OpenAPI that you prefer, or anything else?
Zagroba: What I would want to say is, read the whole standard. I don't think that's something that someone just starting out is really going to be able to do.
Losio: Video, courses?
Malik: If we look at what Cisco is doing, whoever holds the organization from a development relations perspective, focuses strictly on the developer. If you go to developer.cisco.com, just to give you an idea, those are infrastructure based developers and pure application cloud native developers as well. A lot of the education doesn't have to be, to your point, reading a spec or going in to a Git repo and downloading code, and understanding. It might be a little bit daunting for folks that are starting out. Basic learning and getting a common understanding and getting access to some of the free tools. There are a lot of free tools out there, take advantage of it. If you go to developer.cisco.com, you could be a novice and start slowly, get the basics and fundamentals, which are really important. Then as we build on those fundamentals, we can start building applications on how to interact with infrastructure, whether it is on-prem or off-prem. Free resources, which are super important, I think to really get access to them is critical, in addition to reading specification of the course.
Verloy: I definitely agree with all that's been said. I think from a developer perspective, I always find that it really helps if you have a specific goal in mind, like learning something to learn something. I can't do it myself. If there's something that I can build, and I'm going to fail 100 times, and then the 101st time, I'm going to succeed to build a small little thing that I'm trying to create, that's going to teach me so much more than watching 100 hours of YouTube video or reading all of this documentation. I definitely agree, as I always tell my teenage son, I'm like extremely jealous. If you go to YouTube today, you can find anything on anything. It's a free library to learn any technical topic almost. We do make it really easy.
I do want to give one shout-out maybe to the OWASP organization when we're talking about API security. They do publish a bunch of open source tools as well. One tool that we regularly use is called the crAPI API or the Completely Ridiculous API. It's essentially a broken web application that you can spin up on a Docker container or something like that. Then what you can see is you have an API that's completely vulnerable. You can go in and then you can see how you can break it. You can start to understand how attackers are thinking when they see your API appear in public, what type of techniques they will attempt to use to gain access. Things like that really gets you thinking differently from a developer perspective, to also see like, it's not about me sending all objects to the frontend and having frontend deal with my stuff. It's actually, I should really set scoping in my standard and so on. I think that's super helpful as well.
Losio: I really like the idea of a tool of something to break or something that might be ridiculous as a definition, or as simple as a project maybe without a real use case, but that really helps to play with it.
API Testing, Beyond Rule Checking
Talking actually about OWASP rules. Would you recommend actually about testing, about any tool for automatic testing the security of an API that goes beyond checking the rules? If anyone has any advice in that sense, like providing malformed input or invalid, missing authorization for firewall setup. I see that there's been a bit of discussion there with feedbacks that are like there is no single tool. I wonder if anyone has advice in terms of testing an API.
Zagroba: You could automate all of those things. Why? I think a lot of that stuff you would catch once and then you'd fix it. You wouldn't need it to be part of your regression suite and things that you're running over and over again. I can recommend the test heuristics cheat sheet as far as just coming up with a list of all the different things you might want to try. It's a really good place to start as far as brainstorming some of those things. Yes, not everything that you test needs to be also automated.
Losio: If you're a member, get access to the SecureFlag, and you get a chance to play with broken web apps. Again, go there and test things, play with things and see how things happen, not just watch the video that might be exciting, but might not help you.
Verloy: From a tooling perspective, I agree that it's tricky. There's probably not a single tool that captures it all. The reason I say that is your attack surface manifests itself in different ways when you think about an API. If you're looking from the outside in, there's probably things that you're doing that are making your APIs less secure that have nothing to do with your API design. For example, you're leaking API keys in your GitHub repository, as a silly example. That could make you really unsecure, but that has nothing to do with how good or bad the developer was in developing the API, or how good or bad the security people were in putting in gateways and firewalls and all of that other stuff.
There is a lot of API validation and security testing tools that rely on things like fuzzing, like throwing a random code at an API endpoint and seeing what happens. It's a valid approach in a lot of cases. The problem with that is that the majority of real sophisticated API breaches are business logic issues, like people misusing the business logic of an API. Coinbase, in February of this year, had a good example of that, where people could trade different cryptocurrencies and then they would hold in their own wallet. Testing business logic, you can't really do with fuzzing, you really have to understand the objects that the API is working with. There, you have to look at really specialized tools, or maybe even pen testers. People who do this manually and know the design of the API and try to figure out how to break in.
Losio: It's not just about automated tests.
Being Proactive On Threat Detection and Securing External APIs
Often, we have seen third party customers having attacks that's bleeding to their use of our API spam, distributed denial of service, can you speak to being more proactive on threat detection, security on external APIs.
Malik: Live monitoring is obviously important to understand if there's a denial of service attack going on. The other area is when we interface with partners, we want to make sure their APIs are secure. One thing is you protect yourself, but you also make sure you protect yourself from others. Then if you look at tools, just to hit the security topic before, we have tools such as APIClarity, as an example, with various different modules. We're looking at tracing. We're looking at how authentication calls are happening, how authorization calls are happening. Are there too many coming at the same time from a flow perspective? Coupled with some of these tools that we have from Cisco, and then also industry shrink wrap tools, we can really look at these denial of service attacks more closely, and then be able to put the right production mechanism in place. We have to be able to trace the problem. We have to be able to look in the header, making sure the header is right. We can't see inside the payload, of course, can we see what the body looks like? Are there versioning pieces? Is somebody exploiting a denial of service attack, because the API's version 3 release is backwards, as an example, and we won't even allow them to communicate with us? Typically, what customers are starting to do, with developers saying, this is the minimum requirement, beyond this minimum requirement we won't even let you communicate with us. It's a tough call, but sometimes you have to protect yourself. I think some of these tools that we have in the market allows us to make sure some of these exposures such as denial of service or misuse of credentials or encryption, we cut the communication off pretty quickly, or start absorbing them in a honeypot and see what that attacker or that threat actor is trying to do.
Preferred API Security Approaches
Losio: For me, I'm using Web Application Firewall, API gateways, and more traditional approaches and whatever against malicious activity concerning APIs. Do you think these approaches are effective? Instead, what else should a developer consider? Is that enough or am I just hiding my head under the sand and hoping for the best?
Malik: WAF and API gateways, they're important into application design. You have the cloud providers that offer API gateway as a service, and obviously Cisco has WAF products as well. In general, they're not good enough completely to shift left. We need deeper level of security into the code at compile time, design time, and of course runtime as well, in addition to API gateways. API gateway, just putting a border at the end and making sure everybody authenticates in and out. It's not going to give us that level of detailed security at the code level that developers are asking for, but API gateways are important. It's complementary, but I wouldn't say one will supersede another one. I think the API gateways do a very poor job of inventorying an infrastructure, inventory tracking, API tracking, things of that nature. If you want to do risk assessment, very difficult for API gateways to do full risk assessment, which security specific tools or APIs typically do today. Some other security angles are missing.
Verloy: I absolutely agree. I think back to the earlier point, the API gateway is definitely a good tool to some extent, but it can only see the traffic that passes through it, and to Dave's point, like most attacks happen after successful authentication and authorization. From the gateway's perspective, the attacker is behaving like a normal user, and then trying to misuse the business logic. Ultimately, these are SIEM user based solutions, they can block known attacks. If you look at an API, and especially in-house, custom developed APIs, these are all different, and they all have their own unique logic. A gateway is really meant to block a transaction. If you look at an API and the amount of communication that's happening across an API, it's really different than a standard web application. The amount of calls that you make across API endpoints from a single user perspective, that's essentially what you need to understand and need to track if you really want to figure out if this particular user can be linked to malicious activity down the line. Linking that particular user then goes back to, how have we authenticated this user? Are we using JSON Web Tokens? Are we using something else? How can we link the malicious attacker potentially to all of the activity that he or she is generating? It's more about context, to Dave's point. You need a lot more context when it comes to APIs than what these traditional tools can provide.
The Adoption Curve of API Quality and Security
Losio: At InfoQ we talk a lot about adoption curve. We mentioned before that ideally, we love that everyone think about API security and API quality. I was wondering, Elizabeth, what's your feeling? Do you feel at the moment it's something like just a few early adopters, or early majority are doing, or it's something that everyone is doing and we shouldn't even talk about?
Zagroba: Not everyone is doing it, I can tell you that. As far as what the whole market looks like and what every developer is up to, I'm not quite sure. Just within my organization, I see a huge variance in where people are in their careers and what is the depth of knowledge they have, and how safe do they feel on their team or in their department to be able to ask for help and reach out to an architect or to a security expert when there's something that they're not quite sure how to build, or if it's in line with what our company standards are. I would imagine that there are probably some of the same issues in other places.
Short-term, Practical Action Items on API Best Practices
Losio: As I said before, I'm a developer and a cloud architect. Think about the typical audience who joined this roundtable, you convinced me about the importance of security and quality in API development. If you have to suggest one action item, something I can do, I think some of them have already come up before, but one action item, something I can do tomorrow morning, in a few hours, something not long term, not redeploy my entire application, rewrite from scratch, because it's not going to happen tomorrow. Just something we can do in the short term, first advice to basically an action item on what we discussed today.
Verloy: Maybe I can give a shout-out to a nice free resource by a gentleman of the name of Corey Ball, who wrote a very interesting book recently called, Hacking APIs. He has this online resource, I think it's called, apisecurity.com or apisecurity.org, where he actually shows you how to break APIs. I think once you understand what the bad guys are trying to do, then from a developer perspective, you really get why you should pay more attention to some of these things. That goes back to my earlier point, if you don't know exactly why you're working towards something, you lose interest. If you see it firsthand, I think it really drives home the message of this is extremely important. We all know APIs are extremely important, and broadly so. I would definitely recommend that.
Malik: The key thing is just to get educated. I think if you go to developer.cisco.com, there's plenty of resources out there, and just trying the free tools. I like tinkering. I'm sure most developers do as well. There's a lot of resources out there just to get started. Really in an environment, you'd have to be super educated in terms of the API security space. To get started, just really learning what you have and running tools against your environment, and you'll discover things that we probably haven't discovered. It's a good way to just start to learn and then seeing what's out there. Then that will be the next step to move forward.
Zagroba: If you're someone who's already working on or with APIs, I think a small thing you could do tomorrow is delete something. Find something old in the README or in the code that's not being maintained, just make the attack surface smaller for where stuff can go wrong and stuff that needs to be updated. It'll be easier to build stuff in the future.
See more presentations with transcripts
