API World 2023: API Security By Design

Event organizer

‍

Welcome everyone to API World 2023 we're in the Expo Innovation stage.I would like to present our next speaker, Timo Rüppell VP of product at FireTail. Please come onto the stage… Hi! You’re all set.

‍

Timo

‍

Alright, thank you. 

‍

So thanks for that introduction and yeah, today we're going to talk about API security by design so thanks everybody for joining me today with this topic. My aim in this talk is, I want to convince you that contrary to popular opinion, security is not a chore and also it should not be that difficult. 

‍

So this talk is not going to focus on the nitty-gritty implementation details, there are tons of great references, great books out there that I'll link a couple of them in the talk. Instead, this talk should give you an understanding of how security considerations can be brought into the various stages of an APIs life cycle. And it should also give you some actionable tips and tools to do so. 

‍

We're looking at some basic foundations first we will do a small threat modeling exercise, we're going to check out some aspects of API development and finally check out the most important tool for a secure API development at the end.

‍

So before we start, let me introduce myself. My name is Timo Rüppell and I'm the VP of product at FireTail I am originally a classically trained theoretical physicist so I will also be available for questions about black holes and string theory or you can email me about those we can have a chat it's fun stuff really.

‍

After my PhD I was looking for something actually hard to do and decided that writing maintainable JavaScript would be a perfect fit so I moved on to the startup world and now roughly two decades later the challenge rating has gone up somewhat writing JavaScript became fullstack development which became designing and building whole services and maintainability has grown to encompass security and so far I haven't regretted the decision.

‍

I'm also coming to you today from Helsinki, Finland and being that I'm probably more aware than most people in the audience of the following fact [WINTER IS COMING] and this is unfortunately true figuratively for APIS as well as it is true literally for um my home country the thing that I should point out though is that it it does take them [GoT] an entire seven seasons for winter to actually show up so this might not be as alarmist as you might assume however if

you take a step back it is easy to see that there is cause for concern there has been an industry-wide shift happening in how modern web applications and services are built and in how existing services provide more and better access to their own APIs.

‍

Indeed there is an entire service category nowadays for applications that specialize in connecting other applications’ API’s together and the driver for this change is the enormous economic value for everybody participating in this free exchange of APIs now as is usually the case where there's economic value bad actors are not far behind and the number of what we would call pure API in incidents are growing year over-year and they are on average also much more heavy weight than traditional incidents measured by exposed number of Records or volume of data for example so I'll also not go into much detail here- for one, I assume that I'm preaching to the choir and secondly, there's a much more detailed talk available on this subject by our CEO Jeremy Snyder that you can find on our website if you're also interested in keeping up to date we have an API security incident tracker on our website the link is at the bottom here and you can sign up and follow that. 

‍

So with the motivations out of the way let's move on to a quick checkup on security principle/ This is the CIA Triad it's an established way of thinking about the security of IT systems. Integrity covers essentially making sure that the data is only ever modified in expected and intended ways and confidentiality is broadly about guarding access to the data. And my personal favorite is availability because without availability the other two are actual

trivialities you could just encrypt your data throw away a key, chuck the data to the bottom of the ocean and you'd have perfect confidentiality and perfect integrity without much use.

‍

So while there may seem like abstract top level concepts, it is actually easy to connect these Concepts to concrete security concerns. So everybody here is likely familiar with the top 10 Owasp list, if not I highly recommend reading up on it, we also again have published a guide on the topic and you can find a recent webinar on our website as well. It should be noted that, although quite extensive, this is only a top 10 list and you can look at the 2019 list for some additional items for example that are no longer on the top 10  list it this list enumerates the most severe symptoms of failures in the underlying aspects of security and I've linked these here um in this in this nice slide.

So when designing an API with security in mind, I would recommend focusing on the three core principles instead of just blindly checking the Owasp top 10 list or any other list. That is not to say that the Owasp top 10 list is useless in fact it is extremely useful because with a good

understanding of the real world attack vectors what you can do is you can figure out how to effectively allocate your resources to your defenses so with that in mind um let's make a quick uh threat modeling exercise let's take a look at how those Owasp top 10 items line up on a typical API call. 

‍

So this is a slightly simplified view of a standard API call for our purposes I have included some of the traditional web security steps like WF and rate limiting we have authentication which can and in many cases is separated and delegated to a third-party solution or centralized solution then we have the application layer by which we mean the part where the request is processed by any middleware and hand it off to a handler function and in this case there may also be calls to third-party APIs many of the important steps around API security can only be done in this

layer so for example sanitizing request parameters validation, authorization, etc. and that is because usually at the network layer you don't have visibility into these aspects of a request.

‍

Also note that in some of these steps they should be applied to the response objects or response payloads as well so let's investigate where the Owasp top 10 issues appear in this VI so we'll skip points eight and nine because those affect the setup and management of the API as a whole and not individual API calls as such I'll also go slightly out of order to uh have this

flow nicely so the first one is broken authentication and this can be completely external to the application layer if indeed it is being handled by a separate process or a third party. 

‍

The other thing that can be handled by traditional web security functions is unrestricted usage of an API however this depends on the application there may this may have to be dealt with during the validation stage or or by the business logic itself this is the case when instead of repeated requests you can simply set a query parameter to a high value and that way get unrestricted resource access again this is not something that a WAF can easily help you with so the next three items on the top 10 list are all failures in authorization and finally the last two items sit in the application layer as well. 

‍

So when you look at the top 10 Owasp list in this process you can appreciate what we mean when we say that the traditional web security does not really protect you against the current Owasp top 10 so obviously you should still do TLS and rate limiting, etc., but with the exception of authentication and in some cases the unrestricted access all of the Owasp top 10

issues are application layer problems and of these the top three are authorization issues.

‍

So this exercise should give you a good idea about where to spend time and attention when working on the security of your APIs next I want to take a look at two important meta aspects of APIs or software development in general. Number one is the fact that your API is going to affect many different parties who will have entirely separate needs and requirements from your API so just the existence of multiple stakeholders yields one of the most important top tips for API development in general which is documentation so this is key for any form of collaboration obviously but I want to stress that even for a single person company you should absolutely not work on an API without documentation even if you're working on an internal API that does not have external consumers your future self from two years in the future will thank you for properly documenting all your weird but brilliant at the time design decisions speaking from experience here. 

‍

The other universal truth about all software development is that it's never truly finished. Instead, it goes through a feedback cycle of continuous improvement and refinement so during this cycle features may change, be replaced, or removed and as a rookie developer the first time you end up with a feature in the retirement bubble is exactly the time when you realize the second most important thing about API development which is versioning so this obviously primarily helps API consumers in their own development cycles but it also helps with security issues like debugging and incident forensics, it can allow the DevOps team to verify only allowed versions of an API are deployed and for maximum effectiveness you should consider to have the version information present in responses and logs and most places that are useful also consider that it should not only be the endpoints themselves that have versioning but data models and response data formats as well especially if these are complex.

‍

So if we spread this field open we can get an overview of some additional factors affecting the API ownership experience and this is a lot of stuff here and this is where handling all of this may definitely feel like “difficult, difficult lemon difficult” but it's not as bad as it looks. I have highlighted the part where most people put most of their effort and it is not entirely bad that they do this single item can fill an entire university course by itself. And as already mentioned at the top of the talk I won't get into the nitty-gritty of all of these best practices such as never use integers for anything that's not a quantity always have limited strings, etc. so I'll only point out a couple of very good practical resources on the topic so JJ Geewax and Arnold Lorrett are both experts in the field and they've written reference grade books on the topics of API best practices I can highly recommend these for anybody working on an API.

‍

So my job is to convince you that it does not actually require that much effort to take care of all of these other boxes. So we already talked about the collaborative aspect of API design for a given feature you usually start out with the expected usage patterns and and data content that a consumer needs, this leads to data models functionality concerns importantly access control and access control again can include admin accents and admin functions or function for the security or customer success team separately.

‍

So in this process, overall, if I were to guess the most neglected part for most APIs is the compliance teams box and here I must admit to having slightly fibbed- this box is not

actually “difficult, difficult lemon difficult” but it is boring. You should consider the fact that large GDPR fines are on the rise, as is consumer awareness of privacy issues so there is really no way around but to RTFM on this and again it might be boring but you can also find a person like me who thinks that this is actually quite interesting. 

‍

The law is actually not that complicated it's been around for close to eight years there are good resources around and few excuses not to be up to date on this. You'll need to figure out what kind of data you process whether it contains personally identifiable information- you may need to figure out what is personally identifiable information if you're just starting out, you need to figure out what regulations you might need to follow and what kind of practical requirements those may bring to your functioning of the API overall. 

‍

I can tell you from personal experience that retrofitting mechanisms for legal holds or lockouts or consent tracking is not something that you want to spend your time on none of those things are rocket science they're really simple and if you do them from the get-go they it takes no time to incorporate them so that is that is sort of the caveat. Fortunately, the rest of these items that are highlighted are all covered by documentation and versioning and these are things we are already doing you just need to use a documentation method that will actually help you keep track of all of these things and help you with all these things and more on that in a minute so the next big chunk of work relates to how your API is deployed and how availability is ensured- again, entire university course material here- however, the singular easiest tip to help with most of the security issues around DevOps is infrastructure as code.

‍

There's nothing more satisfying than being able to deploy your entire service with a single command, having return time objectives of less than 4 hours for example, start using Terraform or CDK or similar tools if you're not already and the eagle-eyed among you may have already spotted what the remaining items have in common and that is monitoring. 

‍

Now monitoring may be the easiest of all of these to slap on after the fact but again I sincerely hope that instead everybody implements monitoring from the get-go. Again, not having monitoring is like flying blind- it's technically possible but it's an accident waiting to happen so this topic includes everything from application logging API request logging change monitoring for your deployments, etc. and there are tons of tools to help you and again visit our website to sign up for a demo of a really fantastic one. 

‍

And voila! That's it. With just these few things you have pretty much everything covered and greatly expanded the security stance of your API so now let's take a look at the biggest impact item here which is documentation. There are a few options when it comes to documenting your API. The current King of the Hill is open API which was formerly called Swagger, it is operated by the Linux Foundation it's a solid project and together with API blueprint which I think is by Oracle, they sit in the documentation as code cam which is to say that they are document formats that can be used by automation tools. The opposite of this is code AS documentation which is represented by GraphQL and Protocol Buffer which is used by GRPC um and then you have sort of a middle ground Json Schema which is a generic Json validation framework which can be used to roll your own and it is also Al used internally by some of the tools that operate on Open API specs, for example, especially in the request and response validations.

‍

Now abstractly, the greatest function that documentation has is as a single source of truth. This is why it's so good for collaboration. these formats make it possible to take this truth and turn it

into automation for all the things. Remember the thread modeling we did earlier? So using Open API and tooling like connection or Express Open API makes it actually trivial to ensure proper authentication, validation, sanitization- there are literally hundreds and hundreds of tools for mocking linting testing fuzzing or IDE integrations, etc., etc., however, for example, authorization is not covered by the open API spec. We have a project in closed Beta around this and again if you're interested send us a message sign up at the website if you're interested in talking about that but overall look at this list when you look at which problems automated documentation solves and when you take into account where documentation helps in the stakeholder and life cycle stages you can see why we say that documentation is actually the single most important thing that you can do for your API security.

‍

So we're finishing up a little bit early but I hope that this talk has provided you with an overview of some of these things that you can take into your API design process and has given you a new perspective on how to approach API security and get the most bang for your buck when you're working on your API.

‍

Events organizer

‍

Thank you so much Timo for your presentation. I hope everyone gained some insight from his talk. I'm looking forward to  finishing up today everyone. Thank you for joining us in this session in our Expo Innovation stage. Please feel free to ask questions and connect with Timo here and- oh, I think we have a question right now…

‍

Conference Attendee

‍

I'm not sure if this was covered but can you speak about making a threat model?

‍

Timo

‍

Yes, so in general the general concept of a threat model is a good thing to understand so it basically means that you need to understand what kind of things are possibly harmful or going to adversely affect your APIs for example this might be depending on what kind of an API is it is it the financial application is it does it contain healthcare information that is sort of part of the threat modeling for example another part of the threat modeling might be how it is actually connected to other applications, what kind of customers are you serving, etc., so in our example I was using the Owasp top 10 list because that enumerates the sort of most prevalent  attack vectors, SL issues with APIs and that sort of gives you an idea of where to look for um problems that you might have in your API development again there's a good talk about about recent incidences incidents and how they have grown over the past years and in that for example we can see that  authentication and authorization are the line share of all incidents for example that happen so that again can help you figure out where to actually put most of your development work effort when you're trying to secure your API, this is a an important step in in sort of planning your development cycle.

‍

Events Organizer 

‍

Great, awesome to hear. Thank you again so much, thank you everyone for joining us here and please make your way to your next sessions and we look forward to seeing you here at API World, 2023. See you guys. 

‍

Timo

‍

Bye-bye!