How to Secure Your Data Using API Best Practices

Episode Resources:

• Resilience Cybersecurity & Data Privacy
• Best Small Business VPN Services – Resilience Cybersecurity & Data Privacy
• The Best Cloud Backup Services for Small Business – Resilience Cybersecurity & Data Privacy
• 8 Useful Small Business Cybersecurity Tips You Need to Know – Resilience Cybersecurity & Data Privacy
• How To Destroy Perfectly Good Cybersecurity Policies – Resilience Cybersecurity & Data Privacy
• Out with the WAF, in with the WAAP – Imperva
• Hackers Stole Data on 37 Million T-Mobile Customers – Gizmodo
• 5 Ways to Determine if you do Cybersecurity or Cybersecurity Theater – Imperva
  

Episode Transcript

Ryan: Hello and thank you for tuning in again to another exciting episode of The Fearless Paranoia podcast where we take and break down the ever growingly complex field of cybersecurity. My name is Ryan Maltzen, and I’m a cybersecurity architect and specialist. And I’m going to be joined today by my co-host, and excellent friend, Brian, the cybersecurity attorney. And we’re going to pick up where we left off last week talking about T Mobile and the hack of 37 million records through a misconfigured API connection. Last week, we talked a little bit about these API connections, what they are, how they work, and why they become so popular in the development and in turn in the hacking communities. Today, we’re going to pivot and talk a little bit more about the API security, how to make them more secure, how to judge your risk level when using them, and how to get a look at the security behind those APIs. So how about that T-Mobile breach…

Brian: They were able to shut it down. It did take 24 hours, though, to shut down the access. And that was after the hacker had been in for over a month.

Ryan: You know, I’ll be honest, that’s a story that we hear a lot with a lot of businesses. Companies as big as T-Mobile probably has a semi decent sized security department as well. And it still took them a month and then 24 hours to react properly. And to be honest, they were still in some cases, one of the faster ones. And that’s scary. The field is just notoriously overburdened, understaffed. And mentally, the tooling that’s there is impressive, but it has to play catch up, the offensive tooling is outpacing it and the level of automation and the threats and the automated attack changes that are being put together. Now it is growing in sophistication pretty rapidly, and APIs being what they are, are gonna continue to be front and center as a huge point of attack and compromise.

Brian: Okay, so now that we know that the sheer level of access APIs have is the main reason why they’re so popular with hackers, what is the best way to protect your system from penetration through an API attack?

Ryan: There’s a lot of good best practices to follow. First one is, is if you don’t need your API open to the general public and you know where your inbound traffic is coming from, put a firewall in front of it and limit the traffic coming into it to be just from the areas that you want it from. If you reduce your attack surface, right before you even get to the API and get to the application and you filter the traffic at that level, the level one step ahead of that your API is immensely more secure, because that means now they have to come within your scope range to even touch your API. So in order for your API to get access, it’s going to have to come within your we’ll call a trusted range. I hate that term. But that’s effectively what you would have.

Brian: What you’re essentially saying is that only authenticated users and authenticated connections are even going to get to the point where they reach the API, right?

Ryan: We’re not even at authentication, yet at this point, we’re at accessibility. So, by its nature, something like Facebook is generally open to the public, that’s part of their business model they need to be in order to be successful. But so I’ve got a gaming server where I do some gaming on my friends is a perfect example. So, this gaming server I started to see in the logs over the last eight to 10 Weeks was starting to get significant number of hits against it from just general scanning activity, looking for open ports looking for things and the software I was running, I don’t know if there’s vulnerabilities, I don’t know how safe it is, I don’t know how secure it is to gaming software. So, it’s really low risk to me. So, what I did is I went through and got my few other friends that I have joined the server with me and we put an application firewall in front of the server. And I said, let me get your siter ranges, the range of IPs that your ISP uses to connect you guys. So, I took the entire block from all four of those friends. And I added those as allowed traffic into my firewall. And then it denies all other traffic. So, if somebody’s not connecting from one of the residential ISPs have one of those four people, you can’t even touch it, you can’t ping it, you can’t hit the web interface, you can hit the management interface and nothing all that traffic gets dumped before it even gets there. So that’s immensely more secure, which means now all the general route traffic scanning on the internet has to come from either a Comcast or whatever one of the few other ISPs that one of the other focuses on those of the only…

Brian: Which is not insubstantial.

Ryan: But it’s a much lower number than it’s less than 1%, of what the attack surface was prior, which is a significant drastic reduction. So that in and of itself is one of the quickest, easiest ways to do that is just firewall off the traffic. If you have all known traffic. Again, if you’re a public service, that’s not even an option, then it’s definitely not scalable in any fashion. That’s not a scalable opportunity. If you can’t go to that level, or even if you can, and you want to put that in place, obviously the next thing you hit is authentication. So now that you’ve allowed access to the API, now you have to make sure that you have secure the access at the API. So again, if it’s public, if it’s Wikipedia or something you don’t care, because it’s all data that you just want to be public. But if it is private data, let’s say you’re Wells Fargo, and you’ve got an API, obviously, you don’t want everybody popping on the API and just go and woohoo, here’s all the bank accounts. So, you set up some sort of access to your trusted partners and say, “this is how we’re going to deal with access. We’re going to provide you a set of identifiers and we’re going to provide you a secret,” which is basically your set of username and password combinations that this is what you’re going to use. Every so often that’s going to revoke and we’re going to have to provide you a new one and that’s that’d be nice forest rotating a password for you effectively…

Brian: Anyone who has a bank account set up through Venmo knows exactly how that works.

Ryan: That’s how you do those secure exchanges at that level there. So those are really important and whether that’s username and password, if it’s some sort of light touch, preferably MFA gets really tough with APIs, because a lot of time you’re doing application calls that can’t process a second factor easily. And the third real big piece beyond that is you limit access, you control authentication, and then you control access and privilege level. So you need to make sure that unless every user that connects to your API is allowed to have access to all the exact same things, in which case, you can just set one user one validation point and let them go. But in a lot of cases, you have users with different privilege level or applications that actually have different privilege level like, again, Wells Fargo, let’s say Wells Fargo has got an API, obviously, they’re only going to want me if I connect to the API to connect to my account info and get only access to my account info. Same with you, we should not be able to see each other. So each individual account that’s granted access to the API needs to also have an access privilege schema of some sort set up that controls what it has access to on that back end. And that needs to be regularly audited, controlled and logged, somewhere remotely audited, I would think, yeah, so that activity is very clear. And again, the reporting frequency comes down to the importance of the data and the likelihood, severity of the data getting compromised in some fashion. Again, Wells Fargo, if I were them, I’d be monitoring every API call closely, Wikipedia same but not as much, which is why a lot of them tend to get in a lot more trouble because they also have that same approach of well monitor but not super critical it until it hits you in the face.

Brian:   You’re listening to the Fearless Paranoia podcast, we’re here to help make the complex language of cybersecurity understandable. So if there are topics or issues that you’d like Ryan and I to break down in an episode, send us an email at info@fearlessparanoia.com or reach out to us on Facebook or LinkedIn. For more information about today’s episode, be sure to check out Fearless Paranoia.com where you’ll find a full transcript as well as links to helpful resources and any research and reports discussed during this episode. While you’re there, check out our other posts and podcasts as well as additional helpful resources for learning about cybersecurity. Now, back to the show.

Brian: And they’ve also got the sheer volume of information that’s being used on their API. And the fact that the reality is that most of the information that’s being accessed is in fact, public, they can kind of put their hands up and say, well, a ton least notified about a problem here, I’ve got no obligation. And even from my perspective, as a cybersecurity and privacy lawyer, I can’t fault them for not fixing problems they’re not aware of now, that is not the same thing as being willfully blind to the problems, I want to be clear. But the systems deal with so much data, you have to give them the chance to fix something before you can find them negligent or otherwise legally at fault for something you can’t be negligent if it wasn’t something that you could reasonably foresee. And if you have no way of being notified of an issue, because of the sheer volume of information, then you can’t really be at fault.

Ryan: And that said APIs are just hugely important. They’re going to be an increasingly important tool going forward in the future as we continue to build more applications, more connected technologies. And we have to start working on data sharing and collaboration between those. It’s got a lot of standardization behind it, which makes it a really powerful tool because it’s very usable by all sides. And everybody understands what the iterations of it look like. So it’s very important that as people keep putting those technologies in place, they follow the same general best practices, and we’ll all live a great connected life together. But the more people that go out there and don’t follow those best practices, they continue to keep me employed. So thank you to you guys that do even though I don’t agree with the premise behind it, I appreciate the opportunity. So…

Brian: Oh, yeah, it’s definitely something that falls under the cybersecurity reality that there’s no one thing that is going to perfectly fitting solution that is sufficient for addressing everything related to that one thing, you need a holistic response to cybersecurity. The bottom line is yeah, having a firewall is great. But if you don’t have endpoint detection and monitoring and internal auditing, you’re not going to know when someone you gave authorization to is misusing the authorization. They have remember, Cambridge Analytica had the authorization to use Facebook’s data, they used it badly.

Ryan: You can have all the logging and all of the visibility in the world if there’s nobody watching it or doing anything with it. All it’s doing is sitting there taking up space and not serving you any benefits.

Brian: And someone’s probably getting a whole lot of extra things out of that than they should be. Well that’s all the time we have for this episode of Fearless Paranoia. We hope you enjoyed hearing about APIs and how amazingly great and horrible they are all at the same time. You use them all the time, you probably use several just to get to the podcast today. They are incredibly useful and powerful tools and we want them to stay secure. So listen to Ryan’s advice on that. Please, we want to thank you for tuning in today. For more information on APIs including our sources and some useful links check out this episode’s post on Fearless Paranoia.com. You can also find information on how to improve your own personal cybersecurity including various tools and applications at Resilience Cybersecurity.com. If you have any suggestions for topics or things you’d like us to talk about, you can send us an email at info at Fearless Paranoia.com or you can reach out to us on any of the social media accounts that have not been blocked yet. For the record, I think they actually reopened our Twitter account. I still haven’t done anything with it, but I’ll try to get to that. Also don’t forget to like and share our podcasts on social media. We rely on your support to help us get the word out about our episodes. Once again, thank you for joining us for Fearless Paranoia. I’m Brian.

Ryan: And I’m Ryan.

Brian: And we’ll see you next time.