Mike Rothman – Do This, Not That – AppSec/API Security Edition
Modeled after the popular nutritional book series, “Eat This, Not That,” Techstrong Research GM Mike Rothman will share some stories from the front lines as companies (attempt to) integrate AppSec and API Security into their pipelines and processes.
Mike will hit on the culture and toolchain challenges that have made “building security in” much harder than it needs to be. And if anything, Mike will be entertaining, so don’t miss it.
Transcript
Hi, I'm Mike Rothman. I am chief strategy officer Textron group also general manager of tax form research and I am very pleased to be here at the absec API security virtual conference put on by us. I'm texting group.
So really happy to be here. I actually happy to kind of preview A New Concept in presentations that I'm doing now. I'm you know, I'm trying to be healthy, right?
I'm getting a little bit older. So I want to you know, try to eat a little bit better. So I found these books called Eat This Not That right and it just tell you something you probably already knows right, you know, eat carrots not Doritos, you know, I mean stuff like that pretty straightforward but very helpful and and you know from that's the point.
I think it's it's a nice metaphor for a lot of the topics that we cover in our virtual conferences as well as a lot of research that we do at Tech strong research. So I've kind of adopted or basically PIR That concept and and we're going to talk about do this. Not that relative to API security again.
We're talking absec API security all day and really want to dig in on the API security front. It's just a critical issue a very hot topic something that you know, we'll talk about through the rest of the presentation. So let's give you a little sense about what we do some of you may not be familiar with tech strong research.
It's been part of the company for the last 18 months but haven't really talked too much about it. So what we are dedicated experience analyst providing practical advice of application or strategy technology to drive business outcomes bad, right? What it really means is that what we're doing is we're leveraging the audience that we have within Tech strong.
All 400,000 plus folks that we communicate with right 13 million different page views across our editorial sites as a way to gather industry insights and package them up in a way to really magnify the research that we're doing or the areas right or the content coverage areas that we follow within Tech strong, right? com That's kind of the bread and butter but also security right so devops and security depth secops. We're all so expanding into Cloud native infrastructure with container journal and that's really kind of the home base.
A lot of the stuff that we do obviously cloud is a major enabler of a lot of these technology Evolutions. So again, this is kind of the area and that's where we've focus our efforts on really that intersection of devops security and Cloud native infrastructure. And of course apis are absolutely integral to that process.
And with that let's talk a little bit about what is happening with applications today and their application architecture. So a couple different topics here right first is our applications are smaller. And again, the whole thing is not smaller right application or text Stacks are expanding in terms of complexity in terms of sophistication, but they're being built in a totally different way.
They're being built with micro Services these very small reusable types of components that we are integrating into and really reusing in a lot of different context. So our applications are smaller. We've got these little components We continue to reuse we're moving faster.
Right and part of that is driven by devops, right? A lot of the automation that's inherent to devops gives us the ability to drive in and move faster in terms of how we develop deploy and then operate our applications. So we've got smaller components.
We're deploying them faster at a much higher velocity because our processes are far more automated at this point. Even we're also starting to leverage Cloud native infrastructure, right that's containers native Cloud platforms as they may be but really a way to host and platform these application Stacks as we move forward, but there is a common element to all of these different functions all these different trends that we see happening and that's the fact that epi's are used to weave everything together and you see my little weave picture on the slides and that's really what it indicates again as we have Micro Services. We need to wait for these different components to communicate with each other.
Those are apis they're in totally apis, right but they're apis nonetheless. How do we deal with composing an application that leverages some services that Are deployed via the cloud right? It could be a tax service.
For example, it could be a third party capability that we're bringing into our application space. That's right. They're driven by apis and because we've got to move faster, right, you know kind of we have to embrace this concept of leveraging apis to really standardize the communication between our application component.
So everything is moving faster. Everything is is happening at a much higher velocity in the thing that is really enabling a lot of these new advancements happen to be these apians that we continue to effort. So that's kind of where we are from an architecture standpoint.
But what it also means is the more apis. We have a larger Tax Service, right? So the one goes from the other so, you know, what we have to do up front is to in numerate our apis.
We need to understand what they are we need to. Understand what it is that they are expecting. We need to understand what access they have two different resources within our environment, right?
It's kind of like a lot of other security functions that we've had to deal with for many years. It's all driven and the whole process of security really starts with visibility and that's kind of what we're talking about here and numerating our apis finding and discovering whether they're describe or other open API types of documents that allow us to understand what the API is looking to do, right the API contract from that standpoint. We could monitor Network traffic to see where and what that traffic is looking and what it looks like.
Is it going towards those apis really with the idea that we want to understand what the API does what access does it have? Does it enumerate or provide Insight or parameters relative to what? Application looks like is again, you're that interface, you know kind of really talks about and and shows what the specific component whether it's a microservice or a fully Flex application what that's doing.
All right. So again, the API is really the door to get into that environment. So you can find out all sorts of stuff by looking at the apis.
And by the way, there's another reason why we want to do this, you know systematically and an ongoing basis because our adversaries are doing that right our adversaries the attackers have the same techniques that we do. All right, they can look for these files. They can try to figure out what the API interfaces look like.
They can try to see if The format of day of the application is displayed in any way it's provide, you know access to data they have all of those capabilities as well. So like we talk about with attacking yourself or do pen testing or simulations or any of those other aspects for more traditional security. Now that we're doing with apis we want to use a lot of those same types of techniques.
We want to make sure that we understand what the environment is because I can assure you the attackers are doing that for you. So really is about understanding of what we can see visibility being again kind of the first step in making sure that we can lock down and protect our API environment and our friends and I lost right the open web application security project. So for those of you that aren't familiar with it fantastic organization Community Driven and they do a top and every year sometimes soon because we want to make sure that again we're current but let's point out a couple of different things there and of them here but these are kind of the key ways.
You can break into applications. There's a lot of information out there on the intertubes, right? They can give you some perspective in terms of how to mitigate the music issues, but let's just kind of Through them at least a couple of them, you know get a pretty high level right broken authentication making sure that you're getting an API request from an authorized party.
Right? How am I going to prove that this is the right person an API key or some other, you know mechanism to ensure that you are receiving information from an authorized party right excessive data exposure. That's what I was talking about.
When you looking through the Swagger Falls or the open API documents. What we can do is really kind of get a sense of what data is available via the API which could provide a mechanism to get access to excessive data some insecurity misconfiguration that's numbers seven. Again, that's one near and dear to my heart having spent a lot of time, you know doing Cloud security and Cloud configurations introducing cloud-based applications, right?
But making sure the underlying infrastructure is configured correctly so that I call doesn't open up access to specific services or allow the whoever's making that API call to escalate their Privileges and and really get entitlements that they aren't supposed to have right injection insufficient loggingly monitoring making sure that you are pulling appropriate Telemetry out of all API usage again, what we're trying to do is isolate and find a taxes they're happening. So again API are the Lost API top 10 great resource to help you understand what the specific tax are and and really kind of where you can get hurt relative to API environment from a challenger standpoint. And we've got a lot of controls right?
We've got wax we've got, you know DDOS devices. We've got application security testing we've got firewalls. We've got a scanners we've got all sorts of stuff, but they haven't necessarily been optimized or built to deal with API.
Tax, right so laughs, you know again, they're really focused on on the web application piece of it. Now, we've got broader sweets called WAP WAP and application protection or webin application protection platforms? I think that's what the acronym/waap stands for.
We've got API gateways to continue to grow in functionality to do some measure of security stuff. But again these weren't being these were built to be API security tools. So therefore it's really just bolted on technology that we have think about.
All right, we still want to test our applications. So we want to run scanners especially through the devops process and our apis we're going through devops as well. It's code.
So we do want to scan these apis again not um necessary, you know, but never necessary but not sufficient. That's really the point that we want to make you there are a lot of technologies that we're using to try to protect our applications. In fact, you're hearing about many of them today at the app second API Summit Or API security virtual conference that we're doing here.
So you're hearing a lot about these Technologies and they're all still relevant. Right? They're necessary to be able to lock down my infrastructure be able to ensure that my applications aren't being compromised or misused in any way but not sufficient because apis do have some specific user and and attack vectors that we have to protect against so we want to make sure that we are factoring those unique aspects into our security strategy for apis as well.
So now we get to our do this not that right your visibility not hope you can't secure what you don't know about and I talk about people but we've got places where we can find the Telemetry we can find the api's right our API gateways tend to be a front end think about it as like a Content Network. Everything is gonna flow through these things. So I'm going to see Traffic as it goes through my API Gateway.
Our load balancer would be a great analogy to that area Gateway terminates all these things. I can see the API traffic. I can understand what those apis are doing and why they are there application security testing is I know what the code looks like.
I know a lot of these internal api's I can get access to those API contracts and be able to ensure I understand what's going on there and we can look for traffic on the network right past the network monitor. We don't get involved in. It doesn't have to be in line.
Don't be built into you know, our firewalls or our Network switches or anything like that. We can go passively at this environment and really just monitor the environment see what looks like API traffic and then be able to isolate what API engineer. So again, we want to do visibility.
We don't want to just hope that we find the apis and that we can ultimately protect. We want to do sophisticated detection right? Not much the skin like your skin.
It's the lowest common denominator. And again, you can do that on you know number of different tools. The API gateways are starting to you know, kind of do these capabilities.
We've got a lot of the application and devops security systems that are increasingly able to scan the API layer, but we want to do is kind of go to that next level, right? You know again, we don't necessarily is super computer that we show on this picture here just because I like to find old pictures of stuff that dates me, right, you know, crazy super computer was really a thing back when I was kind of getting involved in early on in technology. So I do like to you know, kind of refer to these things time and again, but what we want to do is is have a basis for better analytics, right?
We want to kind of aggregate you see kind of data analytics types of capabilities security. Olympics capabilities to profile what the typical interaction with these apis is going to be right and then look for anomalies could be indicate misuse could be an overflow situation where somebody's trying to use a denial of service attack against the API, right? We want to make sure that we've got those Analytics.
In place so that we can profile and and find the patterns throughout these apis are used and then ultimately look for things that are not normal again, not a lot different than a lot of the detection techniques that we're using elsewhere just really focused on that Epi highlight right that API traffic and ultimately if we do see misuse and we do see an attack we want to be able to block it right we want to be able to enforce our policies but that tends not necessarily to be something that our API security pool or product is gonna do although it may be able to do that if it's in line and we'll talk about that second. Maybe I say a couple minutes on that front. So what we want to do is is make sure that we're we've gone through the process how we going to remediate how we going to enforce these policies.
Do I have to integrate with the API Gateway and tell it what accept and what not to accept directly to do it somewhere else on the network that we do it up within the Location environments but you want to have those discussions especially because there's security folks. You may not necessarily be in control of the controls that are going to enforce these policies. So we want to have those discussions fairly early on to make sure that you understand where and how you're going to enforce the policy.
So do sophisticated detection not just relying on scanning leveraging big data leveraging security analytics to profile what the apis are used for and looking for anomalies there. We want to do outer band maybe right not just in line an easiest thing to do and this is our most security folks. I I came out of network security.
So I totally get it right, you know put a box in place, you know kind of use it as the choke point and for us our policies there so in line deploys within the data path enforce policies and block attacks right tends to be either a purpose Bill box or something that layers in Tower API gateways and if their past Services, right and that's something that your cloud provider or Cloud stack, you know, kind of managers going to implement and be able to deliver from that statement and then that's fine. Right but requires installation of code, right it requires us to architect the environment to be able to see all of those capabilities. All right, so, you know again bringing a lot of use cases, that's fine.
But we also think that again at best practice you will be to consider an outer band solution, which is really just Monitoring the traffic I can help out discover the hidden apis that we're just talking about before right, you know kind of does the analytics so because it's monitoring it's pulling all this data about API usage making sure that the API usage is in alignment with what the policy dictate is possible and then gives you a situation where you can enforce if you need to but by integrating with the active controls the block the attack so and you know, this is certainly from an architectural standpoint. Just something to consider because you've got apis happening everywhere the idea that you can build it into each application and that requires overhead. You've got to get the developers to play into it.
So an out-of-band solution maybe a little bit of a path of a lesser resistance, right? I didn't say no resistance. There's always resistance but maybe a path of last resistance to the you know, the ability to you know, kind of look at those.
Apis monitor them analyze them and again kind of try to detect misuse from that situation. And we also want to collaborate with our developers right now mandate fixes without contacts. We want to be a collaborator as is shown in the picture there, right a collaborator.
We want to be a good corporate Citizen and this is a big problem culturally as folks Implement both devops and more of an API Centric strategy in that things. Got to get fixed right in the security folks tend to think that their stuff is more important and a lot of other things and you know, what, And a lot of cases they're right, right some of the stuff that we deal with on the security front or critical issues to fix as quickly as possible yet the developers. Maybe they don't see it that way right because they're developers and they've got different incentives.
They want to get new features out there. We want to maintain competitiveness in the market. They want to ensure that they are meeting their specific goals and security may not be one of them.
Now, they're not gonna tell you to be clear. They're not gonna tell you that security is not important to them but they're gonna show you that it may not be important that because they're gonna prioritize other things within the Sprint unless it's like a forearm fire and you've got, you know, kind of data breach situation or some other type of leakage that's happening there and a lot of cases like yeah, that sounds great. We'll put it on the list and we'll get to it kind of when we get to it.
So we want to collaborate with these folks. We want to educate them in terms of why Asking them to do how we're asking them to fix things why that's important. Right because security said so that because we're in a big swingers and we've got to be able to do this and and we're putting everything at risk and Chicken Little right?
That's not the way to get things done with developers. And again, we'll take a page from our devops Brethren and and you know folks in order to relay a lot of the same Concepts that we're talking about all day, right? It's working.
It's grooming the findings right grooming the issues. So that developers have context and an understanding about why they need to fix things and what's important about it and how to do it better next time right helps them understand why they're doing things there's another concept, you know, we talk about again specially specific to developerate this idea of security Champion. That's the idea that we've got developers folks that are associated.
With the development team that have been trained in the art of application security. So they're kind of the representative of the security team on that development team, right? And again same thing what happened for the folks that are building out the API layers within the application stack as well.
We want somebody representing Security's interest there that has been trained and understands what to do. They can put the findings to the errors and the defects within the context that they need in order to understand how to prioritize it and how to fix it. So again a best practice here do collaborate right don't mandate right do collaborate.
Don't Mandy think about something like security Champions as a way to ensure that again, you've got the right type of relationship with the folks that are building these applications so that you're not coming in from a Security State Point as an owner is or a security folks are here and tell us what screw everything up and bad right? That's not what we want. I what we want is the ability to have a very focused and and candid and impactful conversation with the developers of the understand what it is that they should be fixing and why they should be fixing it.
So again to collaborate don't mandate do runtime monitoring not burying your head in the sand and that's the fact that you know, For the application layer read all this stuff at the API layer. We can lock these things down to the greatest degree we can but stuff happens. Attacks happen drifts happen change happens right operational change happens and that can create issues.
Right that can create exposures that open up the API layer to some type of misuse. So we want to make sure that we are monitoring the infrastructure as well. Remember what again?
It was a long time ago. Well, maybe 20 minutes we talked about the owoss API top 10 locking and monitoring right? That's a key aspect of one of the best practices that we have to bring forward.
So again runtime monitoring ensures that when something happens outside of our specific application per view we know about it, right and then we can fix it. We can you know, kind of get involved and make sure that your workers Annapolis. It was caused by an application issue you fix that obviously if it kind of puts the infrastructure danger we have the fact that into so do runtime monitoring do not bury your head in the sand.
so that is the do this not that of API security. So let's just kind of highlight is happening at the API layer in numerate all of those apis because I assure you the adversaries are doing that and making sure that we understand if there are some types of excessive permissions or excessive exposures that the apis provide access to right so that's step one. Right we want to do sophisticated detection.
We want to be able to track who and what is interacting with these apis. What are they doing and look for misuse look for anomalous usage of that API, right? We want to do our band monitoring Maybe.
Right. So if you have control the application, you can build in the agency you need in order to you know, kind of do active API protection. That's great many great more power to you.
If you want to you have a broader perspective find those hidden apis. Make sure that again you're not missing anything and really provide a basis for Fairly sophisticated and Analysis. The outer band approach could be something to consider right?
That's a maybe but how to band approach could be something consider collaborate with the developers. I can't stress that enough the importance of security Champions the importance of making sure that the developers have contacts or why they have to fix these issues when they have to fix them. And ultimately we also want to monitor our environment while it's running right in prod to ensure that it drift happens or if we have some other type of infrastructure challenge or even kind of related to the applications.
We know about it and we can in a great with it very quickly. And address those issues. So that is our do this not that for API security.
I hope you learn a little bit of something. Hope you are enjoy. I hope you're interacting with all of our wonderful sponsors that are here at the absec API security Summit.
So do that interact with these folks. I ask questions in the Q&A and we can you know, kind of get answers to you. com.
We'll get you to us if you have specific questions, or just want to chat a little bit about your environment and I want to thank you for your time. So thank you on behalf of tech strong text from research and everybody here. I appreciate you hanging out with me for a little while to learn a little bit about API security.





