Insights for Secure API Usage in Conjunction with Security Automation

this time this is Cody Bramblett and I'll let him take it from here all right hey how's it going everybody today I'm gonna talk to you guys about orchestration security while using api's like you said my name is Cody Bramblett I work at Johns Hopkins University's Applied Physics lab there I do some software development some blue team stuff with socks automation mainly I spend my sorry over here spend my time on the I a CD team which stands for integrated adaptive cyber defense so who is ICD our primary sponsors are NSA and DHS and our goal is to drastically reduce the time to take cyber defense and act on any Intel any indicators we receive and really empower

the network defenders what is ICD it's a strategy it's a framework it's a state of mind we believe that tools should be plug-and-play you should be able to connect it and its work throughout your environment work together with other parts of your environment I you should be able to bring the tools you already have and connect them together and take your sock sock a net sock analysis to that next level and then finally information sharing information sharing is critical to maintaining that next upper hand on the adversaries but it's not the end-all be-all it's not that Silver Bullet only working together can we improve our state of cybersecurity we're not going to solve all the world's

problems with IAC B so some of our work we've we divided work into spirals 90-day spirals where we can put complete either one or a few experiments so we've been doing this for 17 spirals now so that's about four years and we've done various things with automating ICS networks and detections on ICS networks we've done information sharing sharing indicators yesterday someone gave a talk about a pilot that was wrong on the financial sector several banks and credit card companies came together and became iacv and started sharing indicators and automating the that effort to help themselves help each other and defend their networks more quicker and better so why do we care about api's and their

use today so with the use of security orchestration automation and response that's what source stands for as that increases so does the use of api's we want all these tools to be able to integrate together work together and they do that through their api's as more people use these soar platforms there needs to be more automation and so those api's are more in use most security tools now have these api's so they're easier to integrate into your own network but not all api's are made equally so the usage and the security of their usage should be a consideration and when I when I'm talking about API is today I'm not talking about developing api's that your customers will use I'm

talking about api's that you guys use that your sock uses so I'll go into the ones we use a little bit later but they're the ones your security tools already have built in and not the ones you create as a service and find ways to securely use those api's so our experiment was we wanted to use an API gateway to better understand what ap eyes are being used on our network and how we can gain further insight into exactly how secure they are how securely they're being used we wanted to improve the visibility and traceability of the usage and then explore scenarios of detecting a compromised API key and then mitigating that response in an automated

fashion so again we're focusing on the api's of security tools we set up our network in segmented areas so we have a DMZ we had a subnet for our security tools subnet for our sock analysts and then an enterprise section for enterprise users we needed to determine who was going to be using these api's and then assign roles to those we set up our network so that all api's requests had to be proxied through the api gateway while still allowing humans to access the web console because that's how humans work we like to click see graphs and we didn't want to take that away by fully proxying the tool so we wanted both sides we wanted the API and

we wanted the the use of the web consoles for the users we we are focusing on the validation of the API requests and not the vulnerabilities of the api's so how can we use these api's more securely not is one API specifically more secure than the other so here's what our what our network looked like at a pretty high level some of the tools we use we use it open senses our firewall we used hashing court vaults as our API key managed Tyco is an API gateway and I'll talk more about taiking in a few slides we used carbon black as our endpoint detection and response elastic stack as our sim request trackers our ticketing

system and logic hub as our soar platform so traditionally in your enterprise network your soar platform has all of these API keys configured into its workflows and into its configurations and so that's a lot to manage for the soar platform with the API gateway you allow the the single soar platform user to have a single key that sends it to the API gateway and then the API gateway proxies it to the appropriate endpoint so specifically we use Tyco as our api gateway it's Tyco is open source with a pay-for version we use the developer edition so we got a few of the pay-for features it supports several different authentication methods we ended up using two of them the H

macca authentication and the token authentication we configured it with three different roles role for the soar platform or role for the integration engineer and then a role for just an enterprise user and then we set up different security policies based on what tool was gonna be acts going to be accessed so how often could that API be called or what IP address could that API would be called from so some benefits it allows for central essentially managing and recovering API keys traditionally API gateways are used for scaling so it allows for your internal network to scale with more security tools being added but it also provides that further insight you get to see exactly where

these API calls are coming from in a consistent manner because like I said not all api's are created equally they're not all gonna be logged the same way this standardized is it and it also standardizes a lot of other things like the authentication method we were able to log and visualize the all the requests and many times it's transparent to the store platform so you don't have to do anything special to the orchestrator to be able to use the API gateway and then like I said we can configure different security policies for rate-limiting you can restrict down your api's to lease privilege so not all api is give you that level of configuration for used for permissions

and then you can you can restrict the use of the api is based on different IP addresses or subnets so we really broke down what defines the security aspects of an API request so we broke it down into these four sections the who who's using the API is that a user username is it an API token where is it being called from what IP address MAC address what's being called is it the firewall and they want to block an IP is it a request off to virustotal to check a hash value and then when is it being called this one's broken down into two different aspects how often it's being called and then what time of day and using these four

attributes we broke we broke our experiment down into these five different scenarios so because our responses because our responses were all based on revoking the who aspect the API key we put a fairly low weight on who because if someone requests an API with an invalid who attribute we can't revoke that so that one's weighted lower than the rest and then we're what and when are all weighted equally and I'm not gonna go into the specifics on each different scenario but we configured the API gateway to block if any of the attributes were invalid so like I just said the API gateway is configured to block if any of the attributes are invalid all of the requests are logged

to Tyco and then those logs are forwarded to our elastic stack seam and then any suspicious API requests kick off an automated workflow to investigate that enrich that log data and then make a decision to alert the analyst or to take the automated response and revoke that API key so at a high level this is what our workflow looked like we received the alert we investigate it we determine if it's compromised or uncompromised if it is uncompromised then we log that if it if we believe the key to be compromised we were treated the key create a ticket in our ticketing system and revoke that API key our specific investigation looks like this we start with gathering

our log data and then enriching it we then score each of the attributes based on whether it was valid or invalid and then we wait all of those differently and then aggregate that score so like I said who was waited a little bit lower so we waited that it's a point one of the total and then where what and when we're all weighted equally at point three we aggregate those scores check the scores and then if the score is high enough we automatically revoke and reissue that key if it's kind of in the middle where some of the attributes were invalid we launch into some additional manual analysis and then if it's scores low enough we silently log

that so here's what our workflow looked like in logic hub so the top portion is us aggregating and enriching that log data the middle portion is the scoring and then the bottom portion is creating the the tickets in our ticketing system and then launching the automated revoke and reissuing responses so what we found is we were able to visualize the API usage in tike we were able to log all that and send those logs to our elastic stack we standardized our authentication methods reducing the number of different API keys that we needed and then adding a little bit more integrity checks with the H Mac authentication and we stored all that in our our vault server we use

the logs to alert on suspicious usage of IP API requests and then we revoked API keys and reissued new ones several in less than 60 seconds and then we tracked this whole process using our ticketing system so here's some data that we can visualize of the API usages so we have both graphical and tabular data you can see the logs in this is Cabana in elk stack so we were able to forward those logs we standardized the authentication method so this is what vault looks like and we stored all of our API tokens and HVAC secrets there and then we were able to alert on the suspicious activity in our sort platform that lets us kick off automated

responses and the text is probably a little too small to see but it analyzed nine different API requests in less than 40 in less than 41 seconds and to manually look through that probably takes 40 seconds to look through one and then we logged everything in our ticketing system from the initial looking at the API requests all the way through revoking and reissuing a key and what we found is you really need to know what api's you have on your network before getting started you need to identify who's gonna be using those api's and what level of access do they need on those api's specifically put those users into roles and manage tike allowed us to manage these privileges in

a role based access format and then assign the security policies to each role into each API limit how often an API can be called limit who and where it can be accessed from I'm in segment your network so that all API requests have to go through the API gateway so you get that visibility into your network and then if you're thinking about whether an API gateway is if you need one or not you need to consider what authentication methods it supports what type of logs and visualization it provides and then how can you configure the the security policies and roles and the lessons that we learned is it provides that consistency across the API logs you don't have different formats of

logs from different vendors you you've standardized that across the board it allows you to secure and protect your API usage you've now given all of your api's a the same format for username and password or API token you're able to better monitor and restrict because you've segmented the network in such a way that you can see all of the traffic and then it allows that least privilege that that we were used to for LDAP and then provides that scalability as well as security but again this won't solve the problem alone it's all a combination of your corporate policies your architecture of your network and the technologies within that so thank you we have a few demo videos that should be up

on YouTube that go into this specifically we have we wrote a paper about this work as well so now if you guys have any questions I'd be happy to entertain some questions

yeah

so so we wanted to reissue the key to the proper people so it and it depends on what attributes were invalid so obviously we're reissuing a valid key and we're reissuing it to the tools that should have that correct key and

then I don't feel like that answered the question though can you repeat it if you if you suspect that the key was compromised automatic reissuance of it without investigation wouldn't that be you know basically giving the potential attacker or adversary the valid key while it was you know so maybe in I can see that that is valid if they got the key once could they get it again it's quite possibly but how long are they gonna will it take them longer if they think they have a valid key and then it stops working they they'll have to go through their hooda loop decide that that's the reason that the keys not working again go find the new one and

that gives the the sock analyst time to go through see why that key was revoked and dig deeper in that so we we specifically focused on revoking and reissuing but yeah there would definitely need to be additional manual steps to go in or different automated steps to go in and determine why what happened why was that key compromised thank you

are there any other questions all right thanks [Applause]