Mitch Ashley, Techstrong Research | DevOps Connect 2022

Hi welcome. Thank you for stopping by for this talk on EPS security. My name is Mitch Ashley.

I am CTO at Tech strong group and also principal with techstrong research covering in one of the areas. Obviously on API security. Our talk is apis Rise of API security is 10 pm.

Do you know where your apis are there's kind of a hint into you know, what we're dealing with a really understanding apis how they're used where they're used. And what for what purposes? com Community Security Boulevard Community container Journal text strong TV number of different online communities that help us in gathering some research.

So I'm going to share with you some of the data that we've collected about API security and where organizations are maybe you can kind of Benchmark where you are on this and some of these responses, but also I really want to step back and talk about how this fits into the larger landscape of How we create software and why apis are such great concern today? Yeah, even more great important importance than they might have been two three five years ago. We're going to get into that.

So let's first look at some data. What are your top three concerns regarding API security? Well guess what happens what's transferred over apis?

A lot of it is data that we're sharing either information sending from a client to a service in the cloud or between services and the cloud or different applications. So data leakage, of course losing that information losing control in the authenticity of that information is a great concern the expanded tax attack surface intent something we're going to be talking about here and why that's true and what we do about it API use by external entities apis used to be the things that sort of cross the boundary between Ingress and egress of an application. It's how you talk to the app, right?

It was very well controlled and was very very good very limited things through those apis. They were published to a limited set of people. There's opposite is true today.

They're much they're prevalent. They're everywhere the use by so many different elements of our software almost to the point of if we don't have a handle around this we have great great risk of being compromised in some way across that attack surface. So do you have an API security project in 2022?

Yes, we've got one funded 18 percent. Yes, we're investigation, you know only phase moving into the next implementation 20% You're starting one in 2023 another 21% 40% roughly saying that planning to pursue I'll bet that changes pretty rapidly over time. We'll see.

but I think it's a good sign that we've got, you know through almost three two-thirds of the folks responding saying yeah, it's something either working on or it's on the near Horizon for us to get to How would you describe your API security maturity? Well, established something percent. It's being defined another 21 22.

4% ad hoc. I think that would have been the majority well over 50% just a few years ago where every team kind of did their own thing. They addressed either they did or they didn't they had a security Champion.

They didn't API security was something they thought about or didn't it just happened on a local level. And that's one of the reasons we kind of get to the place where we really have to start getting a better handle on it. What do you rely upon for API Security Solutions?

Not too surprisingly open source software, of course being the most frequent response followed up by cloud service provider. I first blush. I was that's interesting on the other hand when you're moving applications or you're building applications in the cloud very common to use services that are provided by that Provider by issue or by Google by Amazon.

Whatever you're using whatever that might be. It is the only place you can consume and gather API security types of services certainly is very prevalent one followed up by internally built Solutions. Now, I find that interesting also because I would guess that we're not we're not building the entire Suite of Security Solutions to secure apis.

What we're building is kind of an integrated Suite of different tools different products different open source together into a kind of a security Fabric or infrastructure for managing API security. That's my guess. I don't have the data to back that up, but we'll see we'll see to get into this a little bit more.

Why why I think that way Which API practices do you follow most vulnerability identifications? We've been doing that for a long time. So if it's very well into that now that's assuming you know, what the vulnerabilities are to be able to find vulnerabilities and lots of techniques, you know of kind of working around the edges of that but that's that being number one oauth top 10 very frequent frequently used.

Of course as a resource. API gateways are very common frankly replacing application firewalls because of the more sophistication around apis and how they're used and how you can form perfectly correct uses of an API, but it in fact being, you know, a very directed attack at something code scanning other things that we you know, comment techniques that we use. Our off rate limiting is another one zero trust versus On The Rise and and Except so you can see you can see the answers here.

So I want to talk about this in a couple of ways first. Let's just kind of get a basic understanding of API security. Of course, that's the have to talk also about the kind of protocols restful being the most frequently used.

Across applications today by far graphql on the rise, very popular more structured more control kind of in terms of what you request and deliver back through an API. Google's help this kind of revitalize RPC in a cloud world with grpc. So I mean you could you could You could say Kafka and it's streaming apis might be another type.

There's all kinds of different apis. But these are the most frequently used and of course along with that. We we have data interchange formats of Json XML yaml others that you could list here, of course to Now when we get into the topic of API security usually starts with Discovery, you know in the security World.

Well, we always talk about we can't secure what we don't know about and that's one of the challenges is how do we know about all the apis? We're either creating using and or consuming. In the software world and Beyond so discovery of apis and it's usually done through some form of a catalog or directory where we contain some kind of information about the apis across the organization, but this has to be a continuous process and it's something we're going to talk about why that that is the case as opposed to manual methods and why they just can't keep up with an aren't keeping up with how we need to understand what we're securing, of course, identity authentication authorization, you know, often different techniques for we're essentially doing machine to machine Communications, of course as well as people to machine.

So that's much more frequent. We need to make sure we know who is, you know, as someone authorized to use this API, what are the access control access permissions within it? And this so they can get access to the services and not to other things, of course in a preventive capacity.

And you know, there are other things. I'm not a comprehensive list. I mentioned API gateways is a very common strategy rate limiting blocking, you know defense catches you very even used to to defend against like a DDOS attack against an exposed like search algorithm or something might be exposed openly through your application testing all kinds of testing and and code scanning analytics number of things that fall into this category and I hope we get a chance maybe another time we can delve into some of these things in a bit more detail, but I want to sit the stage for What we're trying to secure and as we look at those things.

What we need to address and why so I'm gonna just do a real quick recap on how software and how we create software has changed. This is not a lesson on waterfall development. But you know long ago, maybe not that long ago a few decades ago software took much longer to release because it took much longer to build much longer to Define and design it was a linear process and let's be honest.

I used to say any software release greater than three months. We'll always be late and I don't know if I was ever wrong that because I'm smart. It's just obvious things change things come up things get introduced requirements are out of date new things come into play and that's why we have more modern and contemporary approaches to software development agile introduced the idea of a scrum a team across functional team product developers test security Etc working in concert to be able to deliver.

Software on a much more frequent and regular interval more of a time-based approach rather than saying here's our scoping document and we're going to when we get all those things done, we'll deliver it the it's kind of the opposite. It's we're gonna go into two week release cycle whatever the frequency is four weeks. And and this here's the stories that we're going to put into this into this cycle.

And from that we either gonna when we get to that point where we've reached the End of Time what's ready? We'll go into production what's not we'll continue on and be evaluated whether it moves into the next Sprint or not. So it's a much more continuous process that can respond to me more adaptive to changing environment requirements business needs strategies, whatever it might be that's one of the reasons why it's been so widely adopted and then of course devops coming into the scene devops brings with it some other very interesting characteristics of how we create soccer.

We're talking about agile and going through this cycle every two weeks or before weeks, whatever define interval that we're using devops is much more to continuous process where all those things are happening in parallel. Now, you've probably have seen this devops infinity loop I happen to not be a great fan of it because If you unhook one from eight and lay it and end, it's a linear process devonopsis not a linear process each one of these steps as I mentioned are happening parallel. So you have design activities happening planning activities coding the building test going through release Cycles all the way to you know, a subset some some grouping of maybe even a single a set of capabilities.

It's delivered into production or a patch or fix to a vulnerability or something about things like that, but they can all happen in parallel so we can have 50 different things that we're working on and coding and other 30 that are going through a test process each independently, but in parallel all going into, you know from a similar or the same code base into a cicd process and it's it's one of the great unique things about it is we can do many things in parallel and the things that are ready come out at the end of the pipeline if you will. To be deployed and then Mona operated and monitoring can happen when they're ready. They don't have to wait for everything else to be ready to to necessarily go now there are dependencies and they can get complex especially across different applications different workflow pipelines.

So they're the there is that and I'm going to paint the picture. This is sort of a Nirvana it all kind of happens magically by itself. You don't have to worry about anything that you do.

It has its complexities too, but it is much better getting out software up more quickly and addressing needs more quickly as well. It's one of the things that frankly let's businesses. Take greater risks because they know the software team can respond if they find something a problem when they when they've got into Market with a new capability of testing in a new region through some cloud provider service that we're using.

We find out that's not working out. We can react very quickly and deploy you fixes or new code or change the capabilities very rapidly instead of taking weeks and months can happen and days sometimes hours. Now the other big factor that changes the landscape for apis is just how we're using them how why we're creating so many of them across our applications.

Hey, if you've heard of cloud native you've heard of microservices and it's one of the elements containers and container orchestration some other elements of cloud native. But microservices are really one of the fundamental components of it. And just like we've taken Sovereign how we can build it design.

It created code to build it deliver it. We've done the same through our software architecture. I mean, that's how we do that.

We couldn't take a large application and send it through, you know devops process in a matter of hours or a few days and release code. It's just too complex. You've got to break it up into much smaller and smaller bits or bites components and that's what microservices are matter of fact.

Our applications are built of hundreds even thousands of micro services and the applications talk to each other or leverage the microservices within each other's applications both Insider organization and outside as well. So this this idea of a mesh service mesh or a grouping of microservices each doing a discrete function each having all the code that it needs to perform that function in the services libraries sidecars, whatever it might be the goes with it inside a container. Also that's a scale elements of the application up independently.

So as we see a rapid increase in this case, this is my model or part of my model for a media business, you know, we need much more capacity and delivering playing meeting media. Whatever that is video or audio some combination of things. It could be VR for that matter.

So we need to to scale up. The number of microservices that were instances of that that were running in our production environment our scale that back down. Maybe it's a geographic where that happens and then I can all be done through things like container orchestration kubernetes Etc.

But that's one of the great things about it. But the point is all those microservices are talking to each other through one of those types of apis we talked about before like a rest API probably in most cases, but they can also talk to external services and this model example, we might be talking to a subscription service the third parties providing for us a license manager payment system fraud detection. Now those are kind of big groupings of things but inside that are microservices apis that parts of this app talk to in performing some function.

So there's a lot of capabilities that we then deliver through a web. We deliver through someone else's application provided as a streaming service might be a mobile. Mobile app on the front end on a device but it's all talking to microservices across multiple providers in the cloud our app and others so you can see now why there are so many more apis that we're creating in our apps as we do Cloud native as well as in third-party services.

There's also this concept of APA first and the role of apis is really changed from being something of just kind of a technical mechanism an RPC call of how we, you know, a talks to be an interchange data across across that connection through some format. Of course, that's much more sophisticated with other with the graphql and rest Etc. But the point being we now design applications where the app the API is the application.

The API is the interface to the application in many cases. People consume this app or the services that's provides me never talk to a GUI. Maybe they just set up an account provide their credit card number get their token security token to be able to talk to our service.

But all the rest of it's all through apis. I mean a lot of the services that I consume in my business that we consume happen through apis. You might say well really I mean is this that common of a thing?

Well, my best example when people ask me about well, I don't use apis do I A great examples whenever you say well I want to log in with my Google a credentials into the service instead of creating a new account and password or with my Facebook or whatever. There's of course oauth and kind of SSO type functionality that's happening to to you know to create session and minimize the that you don't have to create new credentials for each service. But the point where it brings up the screen and says now if you do this before you click OK you're allowing application to exchange data with application name with application B, and that can be sharing things like your history your search history your maybe it's pii.

Maybe it's just your email address all kinds of your calendar your schedule your contacts, whatever it might be once you cook. Okay, that's all happening through apis crossed those applications one or multiple. And of course we do that a lot in just our everyday use of applications and services.

Across the net on our computers on our on our mobile devices Etc. So this idea of API first is the API is the product. The API is to gooey API is the interface and that's how you consume Services as well as well as potentially mobile and web uis and things like that.

Okay, let's talk about API first approach. Is this a great concept? But you know, we're kind of scratching ahead about how we do that.

This is like technology looking, you know solution in search of a problem. No, it actually isn't looking at some data here. Do your software teams take an API first approach.

33% said yes on all new projects. Okay, that's interesting. That's notable.

I guess your attention. Yes on new projects in retrofitting some existing projects. Okay, protecting the effort to go back and really take this design approach on some of the applications.

I've already created. That's interesting too. Another 26% said that another 15% said no not really a big thing for us right now.

Maybe that'll change over time another almost 25% 24 Roughly said not really sure what this is. So it is a pervasive it isn't everybody's doing it. It isn't the kind of the common way of thinking about it yet, but it is something that's in in the widespread adoption curve.

People are starting on that adoption path. So let's go back and look at devops from if you remember I said all these all these steps happen in parallel. And they happen, you know with individual capabilities or bug fixes or whatever the purpose of the change or addition of code that's happening in any one of the steps through that process, but they're all happening in parallel kind of on their own path.

Through this managing horse interdependencies across that as well, but it's not only our code where we're writing and creating apis. It's also other services other code. Here's some examples.

Open source. Probably, you know, I mentioned Kafka earlier, right the only way you're gonna get some gaskets through its apis. Okay, there's there's an easy example and probably just about every other open source piece of software.

You are consuming. It's apis, Infrastructures code even through a gitups type approach it declarative kind of environment you are using apis to create configure operate manage. Integrate your application lets the capabilities of that software or all the different elements of that infrastructure as code software third party packages, you know, if your python person like I am your, you know, everything's a package and that's how you expand the capabilities of the language and the great things that it can do just like with other environments those things are apis, you know, they're they're being libraries with being used within your code, but they're also apis to other services and and make that simplified.

I mean you might be talking to a maybe you're using a package to talk to Google Sheets to insure row and a sheet or pull data out of a sheet that that's a package. That's it and it's doing API calls between it's code and that service SAS application huge amount of apis that we use for that to integrate the the Cape of just look location service and mapping service. Just too simple examples mobile application.

I mentioned earlier our own See apps our own internal apps that we're talking through apis to our apps management monitoring performance observability partners and customers talking together, you know as well as you know, our business across our own applications. That's why there are it's such a large attack serving. We talked about expanding attack service.

Yes. There's the plethora of the different places where we're using utilizing apis, and on top of that each. One of those on their own path is moving to more porous more open more granular services, like like Cloud native microservices approach.

So the number of apis that are being created and consumed is increasing nearly every day just to give me an example of this Akamai. Just some really great reports McKay an old friend of ours from back in the security days was formerly the publisher the editor of many of those reports, and I remember reading one of the recent reports Akama. I was talking about the daily traffic API traffic that they saw between June of 2020 to June to 2021.

So one year During that period multiplied three times threefold. The number of the amount of web traffic that were eight. That was API traffic that was a year ago.

You know, it's well past June now from 2020 or 2022 in July when this conference is happening so I can imagine what that number is now, so it is on the rise and continues to be and I would expect that to continue for who knows how long So is your API Discovery and here's an important part about all of this? If the rate of growth of apis both the creation their consumption their use their importance to what we're delivering in our applications and our service and our business. Okay, how do you know what apis you're having that you're using that you're creating and where they are in their life cycle.

They may be just being created and maybe published they may be end of life and they may be deprecated. It can be anywhere on their own Journey their own path of their own life cycle. So when we asked this question about your API Discovery yacht is that primarily automated 15 little over percent said it is primarily manual 20% Uh, oh, I think that's the problem area to be the hybrid.

You know, they're somewhere between, you know, a combination of automated end manual 30% maybe the bigger I always don't know 33% my point around this is if it isn't automated. It will never happen because it is changing so quickly you could never do this in a manual fashion. You can never do this through someone entering information into a directory or catalog or through just consuming, you know, comments and documentation that's created in code itself.

We all know that doesn't happen in the fashion. We necessarily like it to it isn't as accurate is it should be it's not gonna happen that way it's changing too fast. So it's got to happen as part of our software creation process part of that devops pipeline that's happening.

So let's talk about it is API security integrated into your devops process? Yes, thirty six percent thirty six and a half. Okay, great validating what I'm saying?

No 27% so a little over a quarter not and another 36 almost 37% said it's a work on progress. We're working on making it happen. So you take the first and the last together now you're talking about two thirds of folks who are doing this and they're integrating it.

They're automating it in their devops process. So let's also look at the secops, you know, this idea of we're integrating security and software more closely together into the software process. Not everybody is doing that matter of fact, the last response that we're not doing that currently that's almost 40% So a large part of the audience here is not there yet really tightly integrating or at least somewhat integrating security into their software creation process, but 45% are in API security is Charity, as part of that devsecops process 14% of 15% said no.

I would guess that will change and I hopefully the the last category will change over time as well. So all that to say what are the takeaways from today? I talked about a lot of things API security but I talked about it in the context of how we create software the architectures.

We're using to create our software. The sources of software apis that we consume and utilize in our applications and our services and how all of that creates. Vast fabric of apis that we create and consume in on whatever lifecycle they are of their own journey of being published and eventually deprecated someday replaced by other apis.

And most importantly apis are the app. That's that is the trend that is where we're headed. If we're not already there on so many applications and services today AP ads are equal to code a equal to the functionality.

You need functionality good to you got to have code but it's not the afterthought. It is the thought of how they're going to get delivered. It's also you can't manage this.

Through plain old Network control approaches Network protocol approaches like we might have withhold firewalls and things like that are vulnerability management or intrusion detection systems, whatever it might be you can form a perfectly well-formed API call that is a wonderful attack against your application. So you can't necessarily do it just through protocol inspection matter fact, you can't do that. There are other elements to it and we talked about what some of those are API first I've already talked about that automation is required.

If if you are doing it without automation, you aren't doing it because there's no way at this pace that you can keep up with the rate. We're creating and assuming apis and API security must be integrated into your devops your Dev SEC Ops pipelines and Tool chains in order to be successful at this now as you look at vendor products, and there are many great ones in the space. It's a very active space today and you know, we can name a lot of vendors in the space and I know many of them well And some of them are existing technology vendors who have added to their portfolio or expanded into API security and others who are peer play that's their focus.

They only do API security. It's what they started off doing. That's what they're focus is and each have their benefits and you know what they bring to the table and they're both equally valid in terms of looking at potential Solutions.

For that to me the key is how can I integrate it into the my software process? How can I enter integrate it into my debt psychops workflow pipeline across how I'm delivering and also how I'm consuming apis across that list of and more of sources of apis. That's the point.

So as you're considering Technology Solutions is you're putting together strategies and architectures. That's the context you're doing it in in the environment that you've got to fundamentally address or you just thinking about API security and I so isolation. I don't think you're gonna you're gonna hit the mark and this gives you a better comprehensive approach that will keep Pace with the changes that are happening and how we create software.

So to that point I really thank you for joining me today. Thank you for listening and it's a pleasure sharing some of the data that we have and some of the knowledge we have and and developed research. Developed around API security and how we create software and software architecture.

So that happens Within. I hope that you will also join us for some other things that are happening. com Security Boulevard text front TV container Journal texturung research.

We have great reports. We're some data like this come from it lives in great reports there videos on Tech trunk TV. I do a lot of interviews around API security as well digital cxo kind of the sea level audience.

So those are great resources that are constantly updated with new information about API security. We also have a virtual event eight app second API security happening on September 13th from 11:00 to Eastern time. So go sign up for that.

com super easy to get to sign up and you'll find we're updating the agenda with more and more speakers. I happen to be gonna be keynoting at that conference and I hope it's because that's one of the places we're really gonna dive deep into this. From different perspectives sets of expertise as well, and I'm looking forward to the speakers that we're having at that again.

Thank you for joining. If you'd like to reach out. You can always connect with me on LinkedIn, it's Mitchell.

com slash in slash Michelle Ashley my Twitter ideas Mitchell Ashley. com and more than happy dialogue with you more about this. So enjoy the rest of the conference and the fabulous speakers that we have today.

I'm excited to be a part of it and I'm most appreciative for your generous offering of your time spending with me talking about API security all the best to you.