As a part of ProgrammableWeb's ongoing series of on-demand re-broadcasts of presentations that were given at the monthly Washington, DC-Area API meetup (anyone can attend), this article offers a recording and full transcript of the Oct 1, 2019 discussion given by Epigen Senior Information Security Architect Trevor Bryant regarding his attempt to bone-up on API security. Although he is a security architect that works on federal government systems, his area of expertise did not include API security. But with the increasing emphasis on exposing government agency datasets through APIs, it was only a matter of time before he would have to add API security to his domain expertise. Sadly however, as you will see, there was no single go-to source for Bryant to educate himself. The information is out there. It's just scattered in a way that sent Bryant searching for various needles in various hastacks.
The DC-Area API Meetup almost always takes place on the first Tuesday of every month. The attendees consist of API enthusiasts and practitioners from all around the federal government as well as businesses and organizations that are local to the DC Metro area. There is no charge to attend and attendees get free pizza and beer, compliments of the sponsors. The meetup is always looking for great speakers and sustaining sponsors. If you're interested in either opportunity, please contact David Berlind at David.Berlind@programmableweb.com. If you're interested in attending, just visit the the meetup page and RSVP one of the upcoming meetups. It's that simple.
Here's the video of Bryant's presentation:
Developers Rock Podcast (special edition): Government Security Architect Attempts to Learn About API Security
Editor's Note: This and other original video content (interviews, demos, etc.) from ProgrammableWeb can also be found on ProgrammableWeb's YouTube Channel.
Editor's note: ProgrammableWeb has started a podcast called ProgrammableWeb's Developers Rock Podcast. To subscribe to the podcast with an iPhone, go to ProgrammableWeb's iTunes channel. To subscribe via Google Play Music, go to our Google Play Music channel. Or point your podcatcher to our SoundCloud RSS feed or tune into our station on SoundCloud.
Full Transcript of: Government Security Architect Attempts to Learn About API Security
The following transcript is from Trevor Bryant's presentation, transcribed as best as possible from the video above. As with many transcriptions of this nature, some sentences may run on, or may appear fractured. Our goal is for the transcript to be as true to the presentation as possible.
Trevor Bryant: So my name is Trevor Bryant. I am a security-minded dev ops nerd. So yeah, I've been doing, I like to fall more in the information security rather than cybersecurity. I'm not too into the offensive or defensive operations. It's more things like FedRAMP, meeting regulatory compliance.
The number one rule of FISMA is actually cost-effective security, so we have to design, build, and implement information systems in the government that also meet a cost-effective security objective. And I mentioned FedRAMP again, but it's really interesting going through FedRAMP, rather than a traditional assessment and authorization process, which is part of the risk management framework underneath FISMA.
You trade administrative overhead from, rather than having something on-prem to [being] in somebody else's data center, which is pretty interesting and significantly more expensive. Turns out, you might get a budget for $300,000 to migrate your application from on-prem to something that's FedRAMP cloud service provider.
And then, you find out your 3PAO is $300,000, so that's got to go back next year and ask for more money and then work on your project plan to eventually get to the cloud in five years in the government. I think Gray is probably one of the few [people] that knows the struggle of that.
Gray: That's why I drink.
Trevor: Actually, it's true. I've known him for several years and pretty much all we do is drink. So the night of NIST part, it turns out if you spend an entire weekend reading about FIPS, encryption and then you go back to Ron Ross's team and you email them that you found a lot of contradictions and you're not really sure what you're supposed to follow, they'll just respond back like, "We hate it when you do this, but stick with the latest round of guidance."
And in this case, it was like, so when am I supposed to have FIPS enabled? You're saying that we're supposed to have the data encrypted in transport and that's sufficient enough. But then over here, in all of these STIGs you're saying that we have to do everything in the operating system and the operating system has to inherit it. And they're like, "Dammit Trevor."
So I've always been an auditor and an analyst and an engineer. Now I'm finally an architect. Evidently, when you get that rise to the title, you get more interesting conversations and I've been getting a lot more into technical policy. There's things like the DCOI, the Data Center Optimization Initiative. Cloud Smart just came out, which is going back to more of the cybersecurity focus and then also the workforce provided in that with the government.
This past weekend we actually had the, was it called the President's Cup Cybersecurity Challenge Competition or something like that. They basically took a generic capture the flag sort of challenge, where we're all hacking into a system, finding vulnerabilities, exploiting things, finding strings or credentials and then eventually working our way to a defined string, which is like flag and then in curly brackets is like some bleep speak and then you go and enter that into a jeopardy style board and then you get points.
So the President actually came out with one last, came up with the executive order last year and then we finally got to play it this weekend and it was a lot of fun and also pretty interesting. I'm also an instructor at DC Tool and that's the open organization of lock pickers. We have a meetup tomorrow, 6:30 at The Board Room, which is just a right up the street. We'll teach you ethical lock sport.
We'll teach you the first two rules and all the laws, depending on what state you're in. We're in DC, so we're okay. You don't have to prove that you're not a criminal if you have a lock pick set on you and just have a couple of drinks and pick some locks, just meet people, just pop locks.
I'm also a conference organizer and volunteer, so if you have been to the DevOps DC meetup, I'm one of the organizers for there or the DevOps Days Conference, at least for the DC chapter. I'm also involved in a lot of the BSides organizations, which is literally like a flip of the deck.
If you don't want to make it to DevCon or you can't get into a talk or you want to speak in these conferences, have like thousands of people submitting, but only 12 can speak. There's the BSides, which are seemingly, there's over 260 now in just about every major city. So no matter where you go, BSides Augusta, is about to come up and they're just really fun conferences in general.
And there's my website. So Gray asked me to come in, talk about API and I was like, oh, I'm a security person. I'll come and talk about API security. And this entire weekend, I spent just nothing but Googling and learning about API security. And this is what I realized, I know about myself is, as a security architect, I know so little about APIs.
I mean, nobody watches Game of Thrones? No. Dumbledore dies. So I always start off with a Google image search like, oh I like that prettiness. I'm going to go find a website or some YouTube video that just appeals aesthetically and I'm going to start there and go read and I'm going to go search my favorite government website because being a nerd in the government, I like to stick with those government definitions.
And so I went to NIST and this is what I found. Awesome. Right? Yeah. WAT, so that was just fumbling around for five minutes and I'm doing a lot of this. Does it work? Yes. Trying to find around an API security checklist because my ultimate goal here is, can I find government standards that are used by the government on APIs? And,if I can find standards, then maybe I can find a security checklist and instead I find this GitHub repository that does, it has a long list of just checks and balances to go through like maybe, you should use Oauth or something else. Don't let data go in plain text, don't have the thing, actually I have a really good slide for that. I'll get back to that. Input and processing have just high-level stuff here.
And I'm just like JWT, what is that? So then I had to go learn about that. And then I go to OWASP, everybody's actually, so they just had APPSEC 2019 in Amsterdam and I think they had APPSEC here in DC some months ago or maybe last month. But they have, so they come out every year with the top 10 OWASP security recommendations, which could be similar to the CIS top 10 or 20 recommendations for security as well.
But what I notice a lot here is that they're things I already know, which is APIs expose a lot of data. And this made me realize or made me remember that one of my favorite websites here to practice how bad I am at penetration testing, has a little challenge to get into it, right? You have to generate your own invite code and by doing, I'll look at the source code and then I see something particularly interesting, which is the make invite code and then execute the make invite code.
And then we get a base 64 encoded string, which I load up in CyberChef and decode and it has further instructions. And then I make a post and it comes back with more base 64 encoded string and there's my invite code. It's like, okay, maybe I do know a little bit more about API security than I thought, which is actually just how to abuse it.
But how do I actually protect it? Where do I go and find recommendations or guidelines of how to protect this? So I go back to OWASP and I find this cheat sheet series that they have this entire project for. And I think this is relatively new because I didn't find this about six, seven months ago when I first started this effort.
And they have so many things listed that made me realize like, I won't know or how to become an expert about this overnight. I was really hoping for an easy button. Sometimes you can go to any of these NIST special publications and just control+F to victory. Be able to just take out all of the statements and throw them up on a slide and be like, this is what I know.
So breaking it back down to the top 10, then I realize, here's something I can actually work with. This is more of the language I speak, security misfit configurations. I know that Verizon puts out a breach and breach report every year and 99% of all breaches are due to a misconfiguration.
It's like, okay, well the Capital One thing came out a few months ago and that made me realize two things, which is nobody still truly understands how the cloud works and if a web application firewall is redirecting commands to an API gateway and it's accepting just about any command, then maybe we want some input validation in there.
I've been having a lot of conversations actually about the Capital One thing because people are coming and asking me like, isn't AWS supposed to be secure? And I'm like yes AWS is secure for AWS, not what's above AWS. That's what you're supposed to secure. So I continue searching NIST and what I find for APIs is security strategies for microservices. Like, okay, we're doing a lot more research on Kubernetes. We're looking at how to implement these things in the government. If you're familiar with OpenShift, OpenShift has Kubernetes inside of it, but with a FIPs certified cipher, so you can actually use it in the government.
And a lot of those are just things talking to other things. But what I see a lot here in this publication is microservices. And so this entire thing is focused on microservices and isn't really teaching me so much about an API or where to find standards on an API or where to find how to secure an API.
So I go to the TTS chat that Gray invited me to forever ago and so I just ask a generic question and I get a lot of responses back. And so somebody pointed me to the cheat sheet series by OWASP and then there was a lot of internal back and forth. By the way, this is public, so this is why I took screenshots.
And so the summary of my journey here, like 30 hours this weekend is what I spent on this probably, is that OWASP has an API security check project and they also have their cheat sheet series project, which is extensive and so I'm going to be spending a lot more time there. You see it now?
Yeah. But also if you know Gray, evidently Gray might be publishing an entire federal standard on how to use APIs in the government, maybe. Maybe, it's somewhere in here. Yeah.
Gray: This is an outstanding way to pressure me to follow up on a commitment if you ever want to.
Trevor: This was-
Gray: Get me to write it down somewhere and then later that day, in a presentation, post a screenshot about it.
Trevor: Yeah. So he told me anywhere between eight to 12 minutes. So that's what I built my presentation for. But the whole theme of this was, as a security person who's supposed to know this, where the hell do I go to learn about this? There has to be somewhere better than, just ask Gray.
Trevor: I mean you can only buy him so many beers, right?
Gray: Not true.
Trevor: So if you'd like to drop some knowledge on me after you realize this is one of those presentations where the speaker made it for the speaker and not for the audience. So where would I go out and find how to learn more about APIs? I've exhausted the resources that I know of. I always start with the government. There's this man right here, that everybody's pointing to, or if you just have any general questions for me. I can tell you a lot about lock picking or I can tell you a lot about FedRAMP or FISMA or traditional assessment and authorizations process, which is called the ATO process now. But when it comes to APIs, my response is still, ask Gray.