Mitch Ashley – 3 Keys to Continuous API Security

Hi and welcome. Thanks for joining me. Appreciate you joining us at the appsek API security conference.

And also this talk on the three keys to continuous API security. My name is Mitch Ashley. I am principal with texturung research.

I'm also a CTO with Dexron group the organization that puts on this event. And in addition to doing analyst work. I also operate our engineering function and infrastructure and all the things that are involved in putting this and other kinds of events our websites our content that codes kind of things bringing those to you.

So it's nice to be able to talk with you about this particular topic with I've been working in for quite some time just a little bit about myself just a little bit of background. I am both a practitioner and a product Creator. I've been creating products really actually since my first company in college or I created a product.

But anyway in in the primarily in the internet era security products also, you know building applications and running. It organizations running security. So I've kind of just mix of both and that's one of the reasons why API security is particularly interesting to me as well as appsec.

I'm probably going to focus a little bit more today on API security, but what I hope to do is is bring things together and because I hope you've checked out all the other talks that we've had. It's a really I mean, there's some folks who I have great and deep perspect for you know people like Larry matron who talked on API security risks, and of course Mike Rothman who works with me in Textron research who I've known for a number of years and extremely well known in the security space and the cloud security space John Willis, of course renowned devops expert who you always want to check out his talks and I will always refer you to him as an expert in our field. He talked about supply chain, which is a very you know, top of Mind conversation for many of us Caroline Caroline Wong had a really good conversation about Security testing at scale.

So we we don't do the same kind of testing we do at least not the same way maybe the same fundamentals but we've got to do that in a kind of much larger scale, you know thinking about it more broadly and it's a little bit Widow. I'm also going to talk about today. So and there are a bunch of other folks from Orca security salt security threat ax dish, you know a whole bunch of folks.

So and I also want to say thanks to our sponsors who have helped put on this event today some very good companies and I'm not going to talk about vendor products, but you can talk with salt and shift left and mend and thread X and all the folks that are that are sponsoring this for today. So let's get into our topic. There is a really interesting some data that we've collected around API security.

and the area of the third leading concern in some of our data that we've collected is API use by external entities. Now, this is the next sort of top one and two were, you know, data leakage and of course expanded attack surface, which we talked a lot about when we talked about application security and apis but the third one being API use by external entities, and I think that's representative of a lot of which going on it changed about how we think about our applications in our software stack So hopefully this at this point in the program, you've heard a lot of evidence about why API Securities important. I don't necessarily and I've got data we could share with you about and what people are saying about why it's important and what they're doing.

But I think here's where we want to kind of take a deviate from a traditional network security conversation and just talking about purely application security because hopefully we have a mixed audience of folks who are from both depth disciplines, whether it's software or network or traditional security or venturing into the software world. You know, we're not really talking about the same things that at least I used to do, you know in the late 90s and early 2000s and Beyond. Of protecting networks and thinking about how to build perimeters and protections around infrastructure on Prem or offering the cloud third party locations endpoint security identity management, all those traditional things that they're still important.

But many of those aspects of security were about creating perimeters protections walls, and of course those the walls moved in and now we think about zero trust but still it's about a lot of it's about protecting things that are there or identifying people who are part of using the technology and applications. So here's the first key I want to bring up is That we have to change our mindset. It's mindset and stop thinking about it as things and people and think about it as software as well as people as well as things that people but it's really not just software.

It's software everywhere in one things. That's a little bit deceiving by saying abstract is yes AppSec that's important. But it's also it's also the open source that we're using whether it's in our infrastructure part of our application stack part of our platform part of our Pure infrastructure or that of third party.

So whether that be SAS providers cloud service providers third party software, you know, all of the all of that environment of course is running on software what endpoint devices all of that too, right? It's software everywhere. And so we have to think about API security for all of that even though we're not necessarily we of course don't create all the apis for that and manage those ourselves, but that's part of what creates This Much Greater attack surface because it just in Applied software supply chain talk it can be somebody else's software can be third-party.

It can be open source. That is presenting that attack vector. Or a vulnerability that cannot be accessed through an API.

So we have much greater exposure. And that's one of the factors but but there are some others. So I think we we listen as a industry have to stop thinking about security as things and people and thinking about as software everywhere the things and people rely on.

And that's going to require both Security Experts to think about the software stack and what's happening inside it and also how software is getting created and how that's secured. Well all the way down to including API security. So that's our first key.

We have to think about things as software everywhere. The next thing I want to I want to venture into is changing our mindset around the point in time nature of how we have viewed security whether that's when we run scans when we run do penetration testing software turned over to a security team to examine and run tests against we're in a different world today, whether it's Cloud native or kind of approaching going to a microservices in kubernetes and containers, but we're kind of eventually getting there with our other applications. We're changing the way that we're doing software and we're changing the way we are designing software.

So let me talk about the latter first. One of the major changes of course in software is cloud native and that's moving away from you know, traditional Mainframe applications going into more of a SOA service-oriented architecture. It's almost like Network architecture diagrams right where it's a stacked architecture of software and layers and the layer cake just looking at it from a software perspective and services major services that are run between those things.

And now we're designing software. In a way that I think of it more like if you've been Venture back to the old Star Trek series the tholian web remember that with the web that entrapped the Starship Enterprise. That's the kind of Matrix that really the relationship between the elements of software that we're creating today.

And that's what microservices about right taking very small more Atomic or smaller nature services and being able to not only functionally divide those up but be able to spin up multiple instances of those services to handle geographic distribution performance requirements number of reasons why we do that and that's where kubernetes and other things come in, of course, so it is really this kind of web or this kind of crosstatch nature of software that is all interconnected. And of course what inner tax those are apis. Now those apis apis can be communicating through, you know, a primary node and in a kubernetes cluster it can you know, as worker nodes are talking to each other.

It can also be through API gateways and some of the technologies that are technology providers might have talked about today or again. Talk to you about But that architecture lends itself to a couple of things that are very different one is we can make changes to any elements of that software much more easily because it's those are kind of self-contained microservices. They're they're collected into containers that can be replicated and also updated and changed sometimes on an hourly basis the folks that have been doing this.

Well the Netflix and Amazon web services and Amazon themselves, of course, I've been doing this for a while and they do this, you know, really hundreds maybe thousands of times a day. Most organizations are not at that level, but we're we're all trying to increase velocity of how we create software. So the point being is we are under under a constant change of not just the environment that we're operating in but the software stack that we're operating upon because any part of it could change we could be deploying a new container.

That is an update. to Spinnaker deployment software that we use for microservice cloud native applications could be the functionality in our applications. I have a model for our business.

Of what our microservices architecture looks like for spinning up videos and and looking at DRM and and doing analytics collecting data about that. So is it it's all these elements and every one of those RN API. That is talking to some other service and also not just Services internal to our own applications and infrastructure, but also to third parties.

So the continual nature of that change means that we have to adopt the second key which is continuous change assume nothing is static anymore. And yes, if you if you stop the world from spinning and you said what does it look like at this point in time you would be able to see that but the problem is you can't stop the world from spinning. You can't stop what's happening in the application the transactions that are flowing through it the changes in the software stack the changes that are happening at a SAS provider or at the cloud service provider or third party tool that you're integrating with or system to gather data from all those things are under constant change and they're checking in with you and I about the changes that they'd like to make to their services to their software even to their apis.

So that that is under constant continuous change. So we have to think about app security and API security and that content so anything that we adopt can't rely on a I'm gonna Scan my repository once the day or once a week or once every six months or do a pen test every three months or once a year. By the time we've done that scan the scans complete.

It may have changed and very well could have changed so it's got to be built into a much more fluid activity because even the process of how we create software as very much under change. Now one of the interesting points about this, I'm going to pull up a little reference here that I have from some data that we collected. I want to also talk about this concept when we talk about how we're creating software of API first when I mentioned the evolution of software.

From you know traditional Mainframe to SOA architecture client service. So kind of has been as Evolution. We're now well beyond sort of the web web application end of this and the mobile application.

We're Alan in essentially what's called API first. API first is the idea of designing software. That is all API based in the software in its in and of itself is built using its own apis.

So rather than apis being an Ingress or egress from the application or from the database or from some service. It's all an integration of services that are talking to each other microservices using those apis and those apis can be internal and they can be external as well. And another aspect of API first.

So one aspect is that that's how we change our application architecture a second is that that actually can and is the product for many products are being designed today. You may never use a GUI ux to access a product. It may only be through the apis that it exposes for their services.

Think of a matter of doing a credit check for example something we've done for a long time right our systems go and check with the credit bureaus. That's a perfect example something we already been doing for a long while now entire applications are built that way under that assumption under that model. So that that's that's a very significant and dynamic change the third element of that to confuse with the three keys, but the third aspect of that is those apis when we create apis, they have their own path their own Journey their own maturity where they're maybe some experimental things or maybe some things we create for apis that are purely for specific use and purposes that have a fairly use a fairly quick end of life.

Might be for a test or an experiment that we're doing in Market because we can deploy set of microservices to try a new idea in market and pull that back when we decide if that's useful or not or we've collected enough Telemetry and user experience data from that. But also those apis given that there were using them across so many areas of our applications of our infrastructure stack of third parties. They have their own life cycle.

So they go through a definition phase or an early adoption phase a maturation phase and then they enter some form of an end of life where they may stay as they are they may have new generations of that API developed. There may be kind of the grandfather clause if you will of how long we're going to support the apis maybe sometimes you have to support old formats of that. We're quite some time and we do deprecate those where apis go away and new things take their place and oftentimes, that's how they if an API dies.

It's usually how it happens is some new framework or no some new set of apis come in. So that is constantly evolving along with how we're using them across our software stack. So my point here is If I'm looking for an API security strategy appsec security strategy, or I'm considering technology Partners to work with me.

I want to look at something that is not looking at give me just an inventory of what I have and then I'm good. Or I need to be able to run a scan and find out what's happening or I need a solution like this today that supports this list of apis or Technologies for apis. And I'm kind of good we have to think about that is our technology that the security that we're playing to that has to be evolutionary sometimes revolutionary right along with our software stack.

So that's the second key of think about this as continuous change. When we're designing and and putting together on strategies and solutions for that. So the third key that I want to talk about and that is automation.

Now we talk about automation a lot with its RPA or automating scripts and operations and some of development process. But let me step back a little bit and say why this is extremely important. how we create software the idea behind initially agile, but more so especially with devops as we've adopted that is that because we can design software in smaller elements and we can deliver that in smaller elements smaller components like microservices.

Maybe it's not even there yet, but we can deliver and test and deliver software in smaller increments much more quickly and that's part of increasing velocity of software organizations and of the business, of course. So that process that devops process if you will it isn't a single tool that is in a single technology. It's kind of a philosophy or an approach of building a workflow pipeline all the way from design to deployment that isn't months or weeks but maybe days and hours sometimes maybe days and weeks in most in most cases, but it can be very quick because those elements can be very changed and that's extremely important to the business because not only does it increase velocity for the business, but it also enables the business to both the respond offensively and defensively to opportunities in Market.

It allows us to experiment with ideas pull those things back if we find that we're not not meeting our goals of what we thought a particularly new capability was going to introduce. So that entire workflow pipeline relies on a devops tool chain a set of tools that are either everything from the source code repository to CI/CD for conducive integration and deployment delivery and testing throughout that process. We may be deploying into multiple environments multiple clouds, maybe have instances that are for different customers different parts of the world, whatever it might be those things happen.

On an automated basis. Yes. There are manual parts of how that work gets done, but the flow in most cases on as automated oftentimes up into until the deployment phase and other folks don't do that automated yet, but increasingly so that's one of the things that we're moving towards.

With that security has to also be automated it SecOps shift left the idea of kind of building in security. Well, first of all, some of those things kind of intended that the developers are going to do that for us, which is not going to happen. They have plenty of work to do.

They're not Security Experts. So we've got to design in security both into the architecture and to the software that we're building into the process of how we created. And so when I think about appsec and API security I'm thinking about how does this happen from the moment of developer designs and builds and checks in a piece of software.

Whether it's scanning for vulnerabilities in that software, whether it's the apis that we're using and maybe new apis that that particular component of software is using apis internally or externally we want to know about that that has to be automated of understanding what that is and understanding what the implications are for that. So this is part of the process where we want not only the discovery to happen early in but also the testing the deployment the updating a policies the identity of what machine and machine Communications can be occurring because that can change. What's the deployment of any new element?

And so that has to be automated as well or bring us into the process when we need to make those decisions. So in summary wrapping up the date, I hope you've had a good experience at the appsec and API security conference. I hope you'll think about API security you'll think about app sec.

Differently than maybe the network or the traditional cybersecurity professionals have and maybe we'll think about it differently as software Architects and software developers and engineers and how we build not just our software more secure but we build this into our development process and our tool chains and also our governance and and compliance requirements that can be fed from data out of those tool chains. So thank you for stopping by. I hope this been fruitful experience for you at the conference.

I really appreciate you being part of my conversation with you today. And I'm sure you've walked away some good things. I know how I have listening to you know, John the John Willis and Larry and other folks today who have just tremendous things to offer.

So thank you again. And we hope to see you soon. com site.

We have a lot of free content that's available there some of it around API security some things around. Testing and AI how that's influencing into our testing and also devops processes alternative Cloud that's evolving and changing in the world. There's a lot of free content we offer all of that to you for free.

So stop by sign up and get that. Have a great day.