The 6 Pillars of Effective API Security

Jeremy

‍

All right welcome to today's webinar with firetail today we're going to be talking about the six pillars of an effective API security strategy uh we're going to try to keep this webinar to 40

minutes or less let's see how we go but the six pillars that we're going to talk about today in some level of detail are discovery visibility observability assessment enforcement and audit and just as a quick bonus towards the end of today's session we're going to talk about what doesn't work in API security and give some reasons for why certain traditional approaches to security don't really work specifically for API security and uh with that I'd just like to take a few minutes to introduce the speakers for today's session so myself my name is Jeremy Snyder I'm one of the co-founders here at firetail and you know my background is in it and cyber security going back

about 25 years the first half of my career spent as a practitioner day-to-day leading it initiatives and cyber security efforts across a couple of SAS companies and video game company before transitioning into more of a product Le role and I'm joined today by Timo Rüppell, Timo do you want to take a few minutes to introduce yourself to the audience?

‍

Timo

‍

Sure thanks Jeremy yes I'm Timo eimo and my background is in theoretical physics uh which I hope nobody uh uh holds against me uh I have been in the startup game for at least over a decade and I have built uh several API-Centric products uh I've been through security audits um and have a fairly well-built understanding of security issues that affect API systems overall.

‍

Jeremy

‍

Awesome awesome and I know some of that experience that you bring to today's conversation is going to be especially relevant because you've lived a lot of this stuff first hand specifically as it relates to API so I'm sure that you'll have some great uh insights to share with our audience today.

‍

So let's kind of start with the first real fundamental basic and that is you know to protect your APIs you first need to find them so what can you tell us about this topic and you know some of the things that you might share with the audience around API Discovery?

‍

Timo

‍

Yes, so this is definitely uh one of the most important things about API security is just knowing what is out there uh many security incidents are basically a variation of “oops we didn't know it was there” so you have zombie and outdated API versions that are just stood up and left there without being updated and having their vulnerabilities uh taken care of you might have APIs

that are stood up by the Dev team as experiments and then just forgotten this is a very common occurrence.

‍

You also have to take into account that modern applications are built in complex Cloud environments where you have multiple accounts Network segments and things just get lost easily so with these sort of fast-paced changes in Cloud environments if you have a manual process that you're just keeping track of APIs that you're deploying with a spreadsheet for example it is extremely difficult to stay on top of what APIs you have deployed so if you're a company and you're embracing DevOps and DevSecOps it is extremely challenging to keep abreast of what you have out there and that is uh really critical for security because one of the fundamental rules of security is that if you can't see it you can't protect it.

‍

Jeremy

‍

yeah I I think that's absolutely true and you know that kind of leads us into our next point around visibility so you know discovery is a is absolutely essential as you mentioned and what's the outcome of discovery and the outcome of discovery is having that visibility and when I think about visibility I actually think of it as kind of a two-part thing so one is that discovery we just talked about and then two is keeping an inventory you know there's a cyber hygiene is I think an often overlooked core principle of cyber security if you you know you know what's out there and you know the context of what's out there that can be really uh that can be really kind of gamechanging in terms of understanding the risk associated to any particular API so if you think about for instance what cloud account and API lives in whether it's an internal API versus an external API or an API specifically used for interactions with one uh particular partner those have different levels of risk associated with them and so having that that visibility and awareness around the context of an API is very much a critical aspect and a critical benefit that comes from that visibility.

‍

The second aspect of visibility that I really want to emphasize is along with that context you need to see into the application layer and we're going to talk a lot about that as we get further into today's conversation so uh on that point you know context is critical I think is the is the key highlight that I would say there and if we think about looking at let's say a sample Cloud architecture that we've got here this is just a reference architecture from uh this one happens to be from AWS but it really applies equally to any of the cloud environments you see here that we've got a real variety of compute infrastructure components everything from things like

workflow engines we've got serverless platforms we've got containers but we've also got multiple interface points right we've got interfaces that are outward facing going to end users and application but then we've got interfaces and connections that are back to corporate data centers or to a corporate office over a private API Gateway in a VPN and so again the level of risk for any of those kind of connection paths would be very different and understanding that context when you get the discovery process that leads to the visibility is going to be very important for any organization to try to understand.

‍

So next I want to talk about you know once we've got that Discovery and visibility going let's talk about observability what can you share with us about observability Timo?

‍

Timo

‍

Sure, like the main thing here is that once you do have visibility the next thing is to actually understand what is happening in your infrastructure like with your deployed API real estate so you need to get understanding about how these apis are used what is their expected usage

patterns what kind of types of API are there and how is the data processed that these APIs are are shunting back and forth so this not only helps you obviously with performance uh related improvements that you can make but it is also a critical aspect of security where changes in usage volumes or changes in the way that data is suddenly processed can indicate that something serious is happening so actually like the combination of these three items uh discovery visibility and observability are just fundamental for being able to then get a very good picture of what is actually happening and then using that to define what you want to happen which which then turns into the actual governance uh of your APIs which is the next thing that we want to talk about.

‍

Jeremy

‍

Yeah and I think you know that point is really well taken that you know governance is is kind of what you want to have and then having that governance should actually lay out a clear path for developers and for the organization as a whole in terms of let's say launching new APIs and the desired configurations and the desired security controls around any of those APIs.

‍

And so when I think about that the thing that comes to mind mostly on the basis of everything that we've talked about so far kind of that discovery visibility having contextual awareness and then having observability is to then assess APIs and assessing APIs I think of as kind of the two-part thing so one is understanding the risk or the threats around an individual API which is partially informed by the context of the API and partially informed by things like let's say an Owasp API top 10 list that describes the common and the most exploited uh attack techniques against APIs. 

‍

And so when we looked at assessment and we thought about you know what are the types of assessments that can be most impactful for an organization implementing an API security strategy it really comes down to a few things one is examining the specification of the API itself which is really kind of the the basis of describing the desired behaviors of an API where should an API be accessible, what actions should be posed to call and Implement and how should an API let's say be authenticated or API usage be authenticated second we look at kind of security configurations in the environments around the API and that might have to do with things like network uh infrastructure that an API sits behind or uh communicates through.

‍

And so that is that assessment step, and I think of this as really you know the outcome of an assessment should be to tell you where you have very specific kind of line by line Point by Point risks or misconfigurations around an API that you might want to deal with and ultimately what you should have from an assessment process is you should have a continuous feedback loop inside the organization so apis get designed they may get tested in kind of development and staging environments before they go into production but once they're in production they get observed as we talked about in our previous observability step and the the observations combined with this assessment can then feed back to the people who can actually make improvements to the APIs which in most organizations is going to be the development teams who own those APIs. 

‍

So Timo, let's talk about enforcement.

‍

Timo

‍

Yeah, so this is like the the other side of the coin what I would say to what you've just been talking about where the enforcement of the functioning of an API is a what we call a runtime protection meaning that not only is your API configured in the correct way deployed in the correct way and changes are managed in the correct ways but now uh you actually get into the details of having a specification document that lets you dictate how the app API should actually behave like how does it actually process the data and this runtime protection needs to be in the runtime.

‍

So there are traditional security methods like having AWS or having API gateways and these are very useful in limiting certain types of attacks uh but as we have uh discovered and as has become obvious when you look at the Owasp top 10 rules for example a large part and the top three threat vectors are authentication authorization and poor data management by the API which are logical problems that can't really be dealt with at the network layer.

‍

Jeremy

‍

So, to align the enforcement with your desires you really do need to have a mechanism for enforcing the API behavior at the application layer and this can generate a sort of zero trust model with your API where it you have like a safety cushion or a safety net to catch misbehaving API behavior and so really on that zero trust model point I just want to dig into that for a second if you think about something like an API specification that should really describe the only acceptable type of communication and interaction with an API if I understand that correctly.

‍

Timo

‍

Right, exactly, so you have things like uh I mean the King of the Hill is open API specifications which distinctly they listing of the allowed responses that the API is supposed to give uh they detail the parameters that the API is supposed to consume and they can have very strict definitions for those and any uh any any sort of uh deviation from those can then be effectively blocked and or at least alerted on so you get a very good picture also just for how your API is working.

‍

Jeremy

‍

Yeah awesome I know that um you know jumping to runtime protection on day one for a lot of organizations can be a little bit of a challenge so maybe talk for a second about the kind of the adoption path that we tend to see with organizations as they do Embrace an API security strategy how how have we seen that play out?

‍

Timo

‍

So I mean obviously as we've discussed the very cornerstone of the foundation is discovery and inventory so that is where where most application where most organization just start off and then they discover that they actually have maybe more APIs that they they actually knew about before and so via this observability they then can formulate policies for how these API should behave and uh they perform assessments and and slowly move from that policy stage then into attack prevention and also getting centralized auditing in place and that sort of brings the government governance aspect of API security in into play which is sort of the end goal for most organizations um to have a sort of fully protected and and well-managed API.

‍

Jeremy

‍

Yeah on that point let's let's talk about audit trails for a second you know and I know the question comes up a lot of the times you know why are audit trails important and what can we actually do with an audit trail so I wanted to take a minute to kind of talk about that and there's a couple things that we've heard pretty consistently in talking to organizations around auditing API activity and one is that you know continuous monitoring assessment is something that generally people like to do from a security perspective they want to understand what's going on one of the challenges around apis is if we think back to that cloud architecture that we looked at that was a one simple architectural uh example but it showed multiple API interface points and it also showed the multiple compute environments that are pretty common in modern Cloud platforms so what that means though from a audit trail perspective and why that's a challenge is that all of those things log to different locations by default and the layers of visibility that you get from those different log file types is quite different so creating a centralized API audit trail is not very easy if you don't kind of look at some instrumentation or Telemetry data around your APIs.

‍

Second is that if you just try to log from various different data types and various log types into one central location and you've got this kind of data irregularity and you then try to put in place alerts on top of that, you tend to go with the least common denominator which is that you put in place alerts around any kind of potentially malicious condition and that leads to a really high level of noise and you know the classic alert fatigue symptom that we see from a lot of organizations where they're just overwhelmed with alerts that turn out to be mostly false positives and it's just kind of novel behavior of an API um where they don't necessarily have runtime protection that might have blocked a potential threat or something like that. 

‍

And the last thing I want to stress around this is from a compliance and Regulatory perspective a centralized audit Trail for your APIs is crucial one is to just understand that and to then pass things like regulatory requirements Soc-2 audit HIPPA PCI, etc but another is that increasingly what we're seeing from governments around the world is more legislation and more kind of Regulation around the reporting of cyber security incidents and if you either don't have a good level of visibility or you don't have a centralized audit trail it's going to be a very difficult exercise to try to understand the scale and the scope of an API breach if and when that day does come to your organization and so having a central audit trail of all of your API activity with kind of a common structure around the log data makes it very easy for a security team to understand what is going on to apply the right thresholds for where to generate alerts and notifications align to the risks and the threats of those particular uh APIs or those context environments and then of course on terms of report reporting and in terms of disclosing breaches you've got great data to start with you can automate a lot of that in fact and you're in a really good position for you know if and when that day does come all right okay.

‍

Timo

‍

I know I know I know you want you want to go for this no I know you want to go for this you have some ideas for what doesn't work 

‍

Jeremy

‍

Yeah I mean I'll start it off and feel free to chime in because you know we we hear a lot about like okay that's all well and good let's just apply anomaly detection across the board because you know we've got so much happening in our API environment and a lot of organizations that we talk to are in the millions if not tens or hundreds of millions of API calls uh per month or per week the challenge around anomaly detection is kind of twofold one is that if you think about high volume APIs how do you distinguish a very successful service from an service that is actually under attack so that's that's one challenge that we've seen.

‍

The other one is if we think about kind of anomaly detections in high volume environments you know I'll just take a tangent for a second to try to kind of explain why it strikes me as being an ineffective algorithm around this I worked for a while with an organization that had a very fast growing manage detection and response business MDR as it's often called. And what MDR is really built on is collecting logs from all these various sources usually that's from like end points and networks and user behavioral activities and things like that you bring them all into central location and you try to do correlation across the different data set types and then you look for potential conditions that indicate malicious behaviors or attacks or breaches or what have you. I talked to a bunch of the sock analysts from that team and I asked them how they're dealing with the volumes of data that they had and what they were doing and they described some of the different approaches that they had some technical some human oriented some things where they had a process in place to kind of deprioritize certain types of tickets but the long and short of it was they definitely had anomaly detection algorithms on a lot of the log types that were flowing in and when you ask them how effective it is you find out that actually it's like 80% or higher false positive and what that translates to is kind of 30 hour out of a 40h hour work week spent chasing down things that end up being, okay this is just something we haven't seen before but in the end it was fine and so like anomaly detection as the basis for an effective API security strategy I don't think is effective. I do think there is a place for it and I think it can be supplemental to any of the things that we've talked about today and it can be potentially an initial signal type on top of things like runtime protection but as a as a core strategy on its own I think there's a real challenge around anomaly detection does that kind of make sense Timo?

‍

Timo

‍

That makes absolute sense that is that is that is very true um and know I want to point out like I want to maybe stress one one additional thing that is the the thing that already earlier mentioned about attacks being logical this is a thing that that really is sort of my pet peeve because there there are dozens of things that you do in a normal API deployment that are sort of security best practices like you use SSL you use uh you use WAFs you use gateways and and and none of these sort of like traditional network security issues help against these what we are seeing new types of attacks which come in with uh a token that was leaked and then exploit vulnerabilities in the business logic that gives them access to stuff that they shouldn't have access or even lead to um privilege escalation attacks.

‍

So this really I think is the the sort of thing that that many people maybe don't yet realize when they look at these incidents where millions and millions of data records are being lost. Like a WAF will never protect against those because the people uh who are you exploiting these vulnerability they're just slowly leaking the data there's no uh there's no sort of DdOS aspect to it or there's no massive data exfiltration going on it's simply that there is like a a small sort of error in the business logic that lets you know um Joe whose computer got uh taken over actually see you know everything that's in the uh in the system for example, and this is something that I feel I feel needs a lot of attention still and and sort of also may maybe education on on on everybody's part.

‍

Jeremy

‍

Yeah it's a great point and I mean I think that point about the attacks being logical is one that is not widely understood perhaps outside of the community of those who are really heavily focused on API security as we are you know our own research around it to your point earlier does kind of clearly illustrate that the top three attack vectors are authentication authorization and data management all of which are logical constructs of an application and so um to anybody who's watching this recording or and hasn't uh perhaps seen a couple of webinars ago we actually did a webinar around the state of API security and we talked about the findings of our research and the summary of about 10 years of API data breaches feel free to go back and look at that and you'll see very clearly the data does illustrate that those three attack factors alone I think make up something like 75 to 80% of the breaches to date and you know to that point a WAF or an API Gateway it's going to look like normal API traffic uh so that is one of the real challenges. 

‍

So I want to transition into just you know sharing with our audience a little bit about FireTail how we built it why we built it what have been some of the core design principles and I think you know firetail really is built on these six pillars of an effective API security strategy that we talked about: Discovery visibility observability assessment enforcement and audit, and to that end what I'd love for us to do is to actually walk our audience through a couple of those things so we're going to turn over the screen share to you for just a second Timo- there we go, awesome.

‍

Timo 

‍

Alright so uh yeah this will be a a sort of brief walk through through our application and sort of keeping in mind like how we uh have built this around these pillars of of security that we just went through so starting with discovery uh this land this page is our Integrations page as a SaaS platform what we are here to do is we're going to help you discover all of your apis regardless of where they are sitting uh the main tool for this is our Cloud integration so we have AWS Azure and TCP uh we also have a GitHub uh repository API Discovery tool that you can either use for scanning your uh repositories and letting us discover APIs that are being developed there we also have a GitHub action available that you can use in your CICD pipeline for then not only discovering but also updating your API specifications and this really is intended to let you easily set up your for example uh Azure integration this is targeted to take about five minutes so that you can create a free account for example and test this out you can use this to uh either discover your AWS or Azure GCP APIs and that will then lead to the next uh page. I'm going to take this other API here we are going to see all of your APIs that you then get so this should fill up with the APIs that you have dis uh deployed in your environment and here you can see you can filter by the various uh various types of APIs that are here this is our testing environment. 

‍

So what this then leads next to is observability around these APIs so you can uh for example go into one of these uh APIs here and then you can start seeing uh the kinds of requests that have been made you can see all of the details around these requests including uh execution times and uh response and uh request payload we do some log enrichment around uh findings of what is happening in this specific API request for example and this allows you to get like a good understanding of what is actually happening with your with your APIs here.

‍

The next step after that is um then posture management which will let you um actually see what kind of state your API is in, so for example here we have some events uh where a collection version has changed so an API has been updated the specification file of an API has been updated when that happens we find this uh via the cloud Integrations or via the GitHub Integrations and we run uh an analysis on that API for common misconfigurations things that might be wrong with that and we give you a very good overview of what has happened so here for example we see all of the different kinds of findings that we have uh regarding this uh this change that happened we can also sort these by severity and we see that there's even a critical one.

‍

With these we try to give you some very good context and information about what actually is happening here so this is an end point that we detected which uh does not have security implemented but which previously had security implemented so this should be classified as a critical um finding for from our point because something definitely has changed and maybe this is an accident in your development pipeline for example that the security methods have been removed from this API um so this is sort of the the posture management site where we observe changes for for sort of the API specifications.

‍

The next thing that I can quickly show is actually the enforcement side if that is possible this will be a very quick demo uh of our library integration so we provide a variety uh for a variety of programming languages uh software libraries to help you use our use API specifications in enforcing the APIs expected behavior. 

‍

So here we can see that we have a an API specification file and we have a separate sort of uh security section that is an extension which lets us sort of figure out the sort of um authorization for this endpoint so in order to demo this the endpoint will be serviced by this uh function here and as you can see uh this is a an unconstrained data return so we are just getting the pet for the correct ID and then returning this pet and this is now intentionally very unsecure and you see that we have two different pets in our data we have a single cat that has an owner ID of one which will be the incorrect owner ID and then we have a dog uh which will be the correct owner ID.

‍

So let's hop over to postman and see what this looks like. So here we have Postman we are hitting this end point and we are passing along the pet ID 11 um and we see that we have failed and well we shall look at the actual documentation here, now we see that we actually got a 304 here and we can actually see what actually happened and we see that the response data here the body where we return the error for the authorization is here and here we actually see that our library blocked this this incorrect original body where we would have otherwise return the cat that is incorrectly owned by the wrong owner so when we go here into Postman and try to fetch the dog we see that this works just fine.

‍

Then, there are then there are additional ways in which we can deal with this authorization um if you for example have a more complicated method for figuring out the authorization graph uh then you can integrate with third party providers or even host your own uh authorization graph via open FGA for example. For this I would invite anybody who's interested in to book a demo because uh they can get quite Technical and quite complicated but we're happy to share and happy to happy to show this to people who are interested in this.

‍

Yeah, maybe last is is then like uh uh the dashboard which sort of gives you a nice combined overview of what is happening with your real estate um and sort of lets you also then see and and track what is happening overall in your in your API deployment.

‍

Jeremy

‍

So that's kind of that Central audit trail of all of the API activity across your environment you've got the various end points and all of the HTTP responses from that. Awesome, awesome. 

‍

Well I will you know kind of flip back to wrapping up today's session and hopefully you know for those that are watching either live or after the event hopefully that was a quick demo walk through that tried to illustrate to you the strategies on which FireTail is really built and you know it's really designed again around that question of the six pillars that we talked about and that demo as you saw from Timo really starts by going through the kind of discovery visibility observability assessment protection and audit and great.

‍

And so just kind of wrapping up I do want to put this offer out there for anybody who's watching today's webinar either live or after the event we are offering a free tier of FireTail for any smbs and startups for those that are interested please feel free to just follow the get start started link from the top of our website FireTail DOI and for any Enterprises that are looking for the kind of business plan features that you get uh on top of the startup free tier, please just reach out or you can also start a free trial there directly on your own. 

‍

Again my name is Jeremy Snyder, I'm one of the co-founders here at FireTail I want to thank everybody so much for taking the time to join us on today's webinar and with that,Timo thank you so much for sharing all of your valuable information with our audience and we will call it a session on today's webinar thanks so much bye-bye.

‍

Timo

‍

Bye-bye!

‍