Insights for Secure API Usage in Conjunction with Security Automation & Orchestration

besides DC would like to thank all of our sponsors and a special thank you to all of our speakers volunteers and organizers hey how's it going everybody today I'm gonna talk to you guys about orchestration security while using ap ice 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 IEC D 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 offenders what is IAC D 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 in that 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 divide 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 run on the financial sector several banks and credit card companies came together and became ia CD inside 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 aap is 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 saw 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 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 is 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 hash e-court vaults as our API key management 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 up 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 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 HFN

ocation 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 fir'd just an enterprise user and then we set up different security policies based on what tool was going to be act 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 standardizes 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 the least privileged so not all API is give you that level of configuration for use 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 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 where 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 retrieve 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 those differently and then aggregate that score so like I said who was weighted a little bit lower so we waited that as a point 1 of the total and then where what and when we're all weighted equally at point 3 we aggregate the scores check the scores and then if the score is high enough we automatically revoke and re issue 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 event ocation 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 an 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 soar 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 request 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 vlogs 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 is a the same format for username and password or API token you're able to better monitor and restrict because you've said mented 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

salad 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 anniversary the the valid key while it was you know so maybe in like an 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 who to loop decide that that's the reason that the keys not working again go find the new one and

that gives the the sock analysts 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]