Insider threats and security concerns for APIs.

Inon Shkedy: I think the biggest threat today with API is lack of, you know, polarization or, basically, lack of fair permission check.

Dave Bittner: Hello, everyone. And welcome to the CyberWire's "Hacking Humans" podcast, where each week we look behind the social engineering scams, the phishing schemes and the criminal exploits that are making headlines and taking a heavy toll on organizations around the world. I'm Dave Bittner from the CyberWire. And joining me is Joe Carrigan from the Johns Hopkins University Information Security Institute. Hello, Joe. 

Joe Carrigan: Hi, Dave. 

Dave Bittner: We got some good stories to share this week. And later in the show, my conversation with Inon Shkedy, a security researcher at Traceable and API project leader at the OWASP Foundation. We're going to be talking about insider threats and APIs. 

Dave Bittner: All right. Joe, before we dig into stories, we've got some follow-up from a listener who wrote in to talk about some special steps that he took when closing for the loan on his house. This is something we've talked about many times. This is a popular place for scammers to try to insert themselves, because when you're buying a house, there's big money in play. 

Joe Carrigan: Right. There's a lot of money moving hands. And they want to get in there and redirect it to their pockets. 

Dave Bittner: Right. And it can be confusing because there's a lot of things going on. There's lots of paperwork. And (laughter) it also seems to be a transaction where many parties involved allow things to happen at the last minute, right? 

Joe Carrigan: Right. Yes. 

Dave Bittner: (Laughter). 

Joe Carrigan: Very frustrating. 

Dave Bittner: I don't know if that's just what happens here in the U.S. But the couple of times that I've been involved with this, that's what happened. And the realtors kind of - they kind of nod and smile and say, yes, that's just how it works. Just... 

Joe Carrigan: Right. 

Dave Bittner: ...It'll all come together. Don't worry. It'll all come together. But at any rate, our listener wrote in to share with us some of the steps that he took. And I think it's worth sharing. He wrote in and he said, despite several other security checks and precautions that I already took well in advance, the afternoon before my closing, I physically went to the settlement office to make sure I knew where it was and that it actually existed. As soon... 

Joe Carrigan: Ah, good. 

Dave Bittner: Yeah. As soon as I walked in, I dialed the phone number I had for the firm. I heard the receptionist's phone ring. And as soon as I saw her pick up, I hung up. I then heard her say, hello. Hello? Hello (laughter)? Then I asked to speak to the settlement agent I had been working with. I asked her to print out a copy of the banking info for the wire transfer. Then after she did that, I asked her to initial the page. The next morning, that's what I brought to the bank for the wire transfer. No relying on email instructions? No relying on text messages? No relying on a phone call - straight from the horse's mouth. 

Dave Bittner: He goes on and he says, I should add that during the entire home-purchase process, I occasionally received phone calls and text messages from the settlement company, the lender and the realtor. No matter who they appeared to be on my phone, because caller ID can be easily spoofed, I never answered the phone directly or immediately reacted to a text message. I had each of them as a contact I created so I could see who was supposedly calling. 

Dave Bittner: But that was not enough for trust, not for me. I had all their known and certain phone numbers in a separate contact I created. And I placed all of their phone numbers in that contact. I also had their known and certain numbers on a piece of paper in my wallet. I would let the phone stop ringing when one of them called. Once it would, I would take out the piece of paper from my wallet and carefully type in the number I had for that person and call them or message them that way. Maybe this was overkill. But I have learned enough from the CyberWire and KnowBe4... 

Joe Carrigan: (Laughter). 

Dave Bittner: ...To know how careful one needs to be these days when it comes to closing on a home. So thanks a million. Well, thanks for writing in. I think a lot of people are hearing this and saying that maybe our listener's taking things a little too far. But why not? I think... 

Joe Carrigan: Yeah. 

Dave Bittner: ...For most people, this is the biggest transaction they're going to make in their lives, right? 

Joe Carrigan: Right. The one thing in here I think might be overkill is keeping the numbers on a piece of paper in your wallet. If you've got them in your contacts as contacts that you have with known good numbers... 

Dave Bittner: Yeah. 

Joe Carrigan: ...Chances of those being changed by an attacker are pretty remote. And that's going to require a lot of effort on their part and probably not the modus operandi of these kind of scammers. They're going to try to insert themselves with business email compromise, which you've kind of protected yourself against here, and by inbound phone calls, which you definitely have protected yourself against. 

Dave Bittner: Yeah. 

Joe Carrigan: There's absolutely nothing wrong with picking up the phone and going - and saying, hey, you need to talk to me? I will call you right back - verifying it that way or doing what this listener's done and just let it ring. And then as soon as it's finished ringing, calling them back. 

Dave Bittner: Here's what I like about having them written down in the wallet, though, is that by doing that, it inserts an automatic slowdown, right? 

Joe Carrigan: Yes. That's true. 

Dave Bittner: It makes this person slow down, get that piece of paper out, look at those numbers. And we've said this until we're blue in the face. Slowing down is a great thing to try to short circuit some of these scams. So I think there's some usefulness there in that. Thanks to our listener for sending this in. I think it's interesting stuff and worth sharing. So we do appreciate it. We do like to hear from you all. You can write us an email at hackinghumans@thecyberwire.com. 

Dave Bittner: Well, Joe, let's dig into some stories this week. Mine is a story from the folks over BleepingComputer. And they're actually warning folks that the Social Security Administration inspector general, whose name is Gail Ennis, has issued an advisory concerning a new wave of scams that are impersonating government employees in order to trick people into sending money. Now, I don't know - have you ever received one of these calls where they're claiming to be from the Social Security Administration, that you're in big trouble? 

Joe Carrigan: I have not. 

Dave Bittner: OK. I have. 

Joe Carrigan: I wish I had because I would do nothing but torment these people. 

Dave Bittner: I have. And evidently it's a pretty common scam. According to the inspector general from the Social Security Administration, the scammers have taken this to the next level, and they have created fake badges. I know what you want to say, Joe. You want to say it. 

Joe Carrigan: I do. 

Dave Bittner: I know you want to say it. 

Joe Carrigan: Badges? 

Dave Bittner: Just go ahead. 

Joe Carrigan: We don't need no stinking badges. 

Dave Bittner: There you go. Do you feel better? 

Joe Carrigan: I do. 

Dave Bittner: (Laughter) All right, so... 

Joe Carrigan: I actually want to go badgers from the Weird Al Yankovic "UHF" movie. 

Dave Bittner: So they're creating badges that look just like the real thing. And this is not terribly hard to do. It's not hard to go online and find a copy of probably just about every official government badge that there is. So what these folks will do is they have these badges made in their own names, and they use this as proof that they are who they claim to be. Of course they're not, but... 

Joe Carrigan: Right. 

Dave Bittner: They'll send you a text with a photo of one of these badges, and that helps to convince you that they are who they say they are. And evidently that's working on some folks. 

Dave Bittner: The advisory from the Social Security Administration has a list of things that that they will never do. It says they will never text or email images of an employee's official government identification. They will never suspend your Social Security number. They will never threaten you with arrest or other legal action unless you immediately pay a fine or a fee. They will never require payment by a retail gift card, a wire transfer, internet currency or by mail in cash. They will never promise a benefit increase or other assistance in exchange for payment. And they will never send official letters or reports containing your personal information via email. Basically, what this comes down to is if you're going to get interactions from the Social Security Administration, it's going to be a letter in the mail, snail mail. 

Joe Carrigan: Right. 

Dave Bittner: Old-fashioned stamp-on-an-envelope snail mail. So I think it's a good warning here, a good reminder that these folks have kind of upped their game a little bit. They've amplified what they're doing by creating these fake things enough to the point where the inspector general of the SSA feels it's worth sending out a little reminder. So I think it's good information. 

Joe Carrigan: I like to think of it this way. You've got these scammers out there working, and they're looking for anything they can do that can increase their results, right? So why not make themselves look more official? I mean, I'm reminded of the movie "Napoleon Dynamite," where Uncle Rico says to Kip - he says, we need some way to make ourselves look official, like badges or something, right? 

Dave Bittner: (Laughter) Right, right. 

Joe Carrigan: And then they print up a couple of badges with their names on it. What does that mean? I mean, it's nothing. It's just a badge of the picture and your name on it. And they're going around selling Tupperware or something (laughter). 

Dave Bittner: Yeah, yeah - reminds me of the old TV show "The Rockford Files." Jim Rockford would have a little Rolodex in his car that was a lot of other people's business cards. And he would go... 

Joe Carrigan: (Laughter) Right. 

Dave Bittner: ...And present himself as being them just by handing someone the business card. He'd say, hi; I'm, you know, Joe Lebivowitz from Ace Insurance Company, and I was wondering about such and such. And it works. 

Joe Carrigan: Right. 

Dave Bittner: It absolutely works. All right. Well, that's my story this week. What do you have for us, Joe? 

Joe Carrigan: I wanted to talk about those Tom Cruise deepfakes. Have you seen these? I first heard about these thanks to a tweet from Rachel Tobac. There has been tons of media buzz about this. These are deepfakes of Tom Cruise doing things that are not - you know, just playing golf or doing a magic trick or talking about Mikhail Gorbachev. But they're not actually Tom Cruise because the deepfakes are posted on TikTok to a fake Tom Cruise account. And Tom Cruise is not on TikTok. 

Joe Carrigan: David Gilbert over at Vice has a story on this, and we'll put a link in the show notes to it. And he says that, you know, a lot of people were reacting strongly about it. They were saying that they're concerned about it. I'm actually very concerned about how good these deepfakes are. I showed them to my wife, and she was like, that's Tom Cruise. And I'm like, nope, that's not Tom Cruise. 

Dave Bittner: (Laughter). 

Joe Carrigan: But there's a lot of effort that went into creating these videos. They are the work of a Belgian visual effects artist named Chris Ume or Oom (ph). I'm not sure how you pronounce it. But he's part of a group called Deep Voodoo Studios, which is a deepfake studio that has been assembled by Trey Parker and Matt Stone, who are the guys that are responsible for "South Park." These are well-known American satirists who will make fun of just about anything. 

Dave Bittner: Especially Tom Cruise. 

Joe Carrigan: Especially Tom Cruise. Right. 

Dave Bittner: (Laughter). 

Joe Carrigan: The way they've done this is Ume and his team work with a guy named Miles Fisher, who is a Tom Cruise impersonator. And they worked together to produce a video in 2019 that showed Tom Cruise announcing his presidential candidacy. That was not Tom Cruise either. It helps that this guy looks a lot like Tom Cruise and kind of sounds like him, too. And the voice in these videos sounds like a younger version of Tom Cruise. And I don't know if this is an impersonation that Miles Fisher does of Tom Cruise or if they're using other audio deepfakes to make the voice sound more like Tom Cruise. I don't know what's going on here. There are some very good impersonators, people who are very good at impressions out there. You think of people like Frank Caliendo. Do you remember Mike O'Meara from "The Don and Mike Show"? He still has... 

Dave Bittner: I do. 

Joe Carrigan: ...A podcast out there. 

Dave Bittner: Yep, yep. 

Joe Carrigan: And there's a guy named Charlie Hopkinson from England who is remarkably good - right? - at doing famous voices. One of the things that the Vice article points out is that these deepfakes were fooled by a lot of the better deepfake detection tools, which I think is interesting. Tom Maxwell over at Input Mag has a story on it, too, and he notes that tools by a company called CounterSocial did detect that it was an inauthentic video. 

Joe Carrigan: But TikTok - and this is really the crux of the matter. TikTok does not attempt to verify any video as authentic or synthetic when you upload it. It just puts it up there. And Maxwell points out that this retroactive detection is like closing the barn door after the horses have already run away, right? We've got now all these fake video out there that tons of people have already seen. And now you're going around, saying, nope, nope, nope. That's a deepfake. That's a deepfake. It's going to be difficult to get in front of those if you don't detect the inauthentic video or synthetic video before you publish it. 

Dave Bittner: Right. 

Joe Carrigan: The fact that TikTok doesn't have that on there is not really significant to me. I mean, it's just going to take somebody who wants to publish an inauthentic video finding a service that doesn't try to identify synthetic media to publish it there. I mean, it's just a matter of finding the right service to publish it on. 

Dave Bittner: When you look at just all of the variety of Snapchat filters are out there, you know... 

Joe Carrigan: Yeah. 

Dave Bittner: You alter your face. You alter your voice. And, you know, look at how many people post videos of themselves where there's some kind of anti-wrinkle smoothing algorithm. You know, it looks like... 

Joe Carrigan: Like Vaseline on the camera lens, right? 

Dave Bittner: Right. How is a filter like this supposed to differentiate between that, something that's - that is intentionally distorting what you look like and something like a deepfake? I don't know the answer to that. 

Joe Carrigan: That's a good question. 

Dave Bittner: With all that in mind, it doesn't bother me - I would not expect someone like TikTok to be filtering these sorts of things. 

Joe Carrigan: Right. 

Dave Bittner: Now, if someone brought it to their attention, then maybe they should tag it as such. But... 

Joe Carrigan: Yeah. 

Dave Bittner: ...I wouldn't expect them to go after it proactively. 

Joe Carrigan: And that's one of the things that Rachel Tobac and a lot of other people are saying - is that we need this inauthentic video or synthetic video to be tagged as synthetic video. Microsoft says they're working on a way to counter this with some kind of digital signature tool, where companies who produce video can then sign the video. This is, I think, a good solution. I like the idea of a blockchain solution that you can combine with digital signatures. In fact, you pretty much have to do that for a public-trusted blockchain anyway. You have to have digital signatures to authenticate the transaction. I mean, you can build a blockchain without digital signatures, but that kind of defeats the purpose of building a public-trusted blockchain. 

Dave Bittner: Right. Right. 

Joe Carrigan: It's just a data structure that's out there. But you put digital signatures into it, and only the people with the private keys can sign these transactions, like somebody saying, this is my news article here. I think that provides an added benefit, as well, to allow for the perpetuity of a news story. It's what prevents the Orwellian memory hole - right? - where people go around and change news stories or delete news stories. You can't do that once you have a signature of a hash of the news story on the blockchain with a reference to it or maybe even the entire text of the article that you've written on a public blockchain. 

Dave Bittner: Yeah, I think we saw the beginnings of this in this last political season. There was one making the rounds that was - looked like Speaker Nancy Pelosi was drunk or tipsy or - you know, so you had people modifying videos to make people not look their best - things like that. 

Joe Carrigan: I saw a remarkably large number of people on my Facebook feed sharing that video. 

Dave Bittner: Yeah. 

Joe Carrigan: This is why I say that these social network platforms are no place for political discussion. They're just not. They are prone to this kind of attack, this kind of misinformation. And they're also prone to people behaving inappropriately and feeling good about it because they are reinforced by other people who feel the same way politically as them. 

Dave Bittner: Yeah, it's interesting. You know, it makes me think about - I have a plug-in for Twitter that I think we discussed on this show. It gives anyone posting on Twitter - it gives them a percentage rating as to the likelihood that they are a bot versus being a person. And I wonder if we can have something like that for videos, where there's some sort of plug-in that, you know, looks at - if we had something like a block chain solution, it could look at video and say, OK, you know, we have with this amount of confidence that this is authentic or this is unaltered. Or, hey, we don't know anything about this, so tread carefully here. 

Joe Carrigan: Right. Yeah, well, the Microsoft solution was a signature on the metadata. One of the issues with building a signature on a file is you need to have the entire file before you can verify the signature. And that doesn't happen online. In fact, with, like - with a video streaming service, you generally don't get the video. You just get a stream of the video, which your computer then forgets, right? 

Dave Bittner: Right. 

Joe Carrigan: But you can sign the metadata about it and say, we're verifying that this is our video. We're asserting provenance of this artifact, whatever it is. The digital signature is easy enough to check. That's the thing. So you could do that with a plug-in, or you could do it with the webpage itself. 

Dave Bittner: All right. Well, interesting story. We'll have a link to that in the show notes. Joe, it is time to move on to our Catch of the Day. 

(SOUNDBITE OF REELING IN FISHING LINE) 

Joe Carrigan: Dave, our Catch of the Day comes from a listener named John (ph). It's really a story he sent along from his son. You want to read this? 

Dave Bittner: Sure. It says, hello, Dave and Joe. I'm an avid listener from episode one, and you both do an excellent job providing valuable information in an entertaining way. Well, thank you, John. 

Joe Carrigan: That's very nice. 

Dave Bittner: I appreciate that. Yeah. 

Dave Bittner: I very much appreciate your efforts and passion. I had a situation recently that I would appreciate your opinions on. Here's the story. My son informed me he had interviewed for a job online and needed to send a photocopy of his driver's license to complete the hiring process. When I inquired for more details, he said he had responded to a job posting on LinkedIn and been through a couple of interviews on Google Hangouts. This seemed a little strange, so I dug a little deeper. The name of the person and the company he was interviewing with matched a LinkedIn profile for an HR director at a legitimate company. But it seems strange to use a random Google Hangout for interviews. 

Dave Bittner: Not being the suspicious person, he sent the photocopy, and then things got more interesting. Through the Google Hangout, he was notified he had the job and that they would be sending $5,437 in a check that he was supposed to deposit and then use his own account to purchase a high-end Apple MacBook Pro from a specific vendor website they do business with. The next day, an overnight FedEx envelope arrived with what seemed like a legitimate check inside. The person on the Google Hangout followed up to verify the check had arrived and that my son should deposit the check right away through an ATM and not go through a teller. Another red flag. At this point, I had him contact the local law enforcement since this seemed like a money laundering scheme of some sort. The local officer said this was a common scam, and my son should just stop communicating and forget it. 

Dave Bittner: I had my son file a complaint with the ic3.gov since we had the complete Google Hangout dialogue, a FedEx envelope, a check from a bank that seemed real and a supply company that seemed real. My son did stop the communication, and I had him go to the local DMV and get a new driver's license in case identity theft was part of the scam. From my understanding, this seemed like a money laundering scheme to me, but I would appreciate your take. P.S., after six months, there was no response from IC3, so I'm guessing this is too small for them to consider. Kind regards, John. 

Dave Bittner: All right. What do you make of this, Joe? 

Joe Carrigan: I don't know about the IC3 part. Maybe it's too small for them. Maybe they just collect the information and then try to go after things. 

Dave Bittner: Yeah. 

Joe Carrigan: Everything you have, in terms of your Google Hangout dialog, the FedEx envelope and the check - that's all pretty much worthless unless they can maybe get fingerprints off of it. But they're probably not going to go through that kind of effort here because your son actually was not injured during the course of this, except for the fact that he did send a copy of his driver's license. 

Dave Bittner: Right. 

Joe Carrigan: I think it's a good idea to have him go out and get a new driver's license, especially if you can have him get a new driver's license identifier. I don't know what state John lives in or, actually, even what country, but I'm assuming it's the U.S. This is probably just a check floating scam. It's probably not a money laundering scam. We had another listener send us an email about something very similar, where someone was actually scammed out of money this way they deposited a check into their account, and then the alleged employer said, well, go buy a FedEx gift card for 500 bucks and send us the picture of that. And that's how they scammed that guy out of 500 bucks. What happens with that check is the next day, the check bounces, and you are out any money that you spent. 

Dave Bittner: Right. 

Joe Carrigan: That's how this works. So it's really just a scam to get your money. A money laundering scam looks just a little bit different. The checks will actually clear in a money laundering scam. And you may or may not be aware of the fact that you're a money mule. 

Dave Bittner: Right. Right. It seems like John did all the right things here. 

Joe Carrigan: Yeah, agreed. 

Dave Bittner: And happy that we caught this. 

Joe Carrigan: Yeah, you saved your son a lot of money, I think. 

Dave Bittner: Yes, a lot of money, time and hassle. 

Joe Carrigan: Yes. 

Dave Bittner: So yeah, he should send you an extra-special Father's Day card this year. 

Joe Carrigan: That's right. 

Dave Bittner: (Laughter). All right. Well, we appreciate John sending that in. Again, we would love to hear from you. If you have a Catch of the Day, you can send it to hackinghumans@thecyberwire.com. 

Dave Bittner: Joe, I recently had the pleasure of speaking with Inon Shkedy. He is a security researcher at Traceable and the API project leader at the OWASP Foundation. And our conversation focused on insider threats and APIs. Here's our conversation. 

Inon Shkedy: I think it depends how you look at the insider threats because there are three different ways to define them. But I would say that insider threat is every malicious user to gain access to the system and a few different ways to gain this access and to a few different types of access but in a very high level is someone that actually has access to the system, either if you got it from, like, malicious activity or just, for example, someone who should have the access, like a malicious employee of the company, for example. 

Dave Bittner: And I think it's important to be clear that an insider threat doesn't necessarily have to mean someone with malicious intent. 

Inon Shkedy: Of course. Right. It can be someone just - he's more like a victim. 

Dave Bittner: So when it comes to protecting against insider threats, what sort of things are we talking about here? What sort of recommendations do you have? 

Inon Shkedy: There are a few different points that I would recommend for companies to take in order to protect against insider threats. The first thing is the concept of zero trust. Especially in, you know, modern environments, it's really important to understand that you can't really trust even the devices and micro services that are inside your environment. You should always check for authorization and authentication and apply security mechanisms. Think this is the first recommendation. The second recommendation I would give is basically to think very clearly about the permission mechanism when it comes to access to the most important assets in your company. It's really important to define them and then to make sure that you give access only to the right people because recently, you can see many companies just expose a very sensitive API or even a very sensitive database to all the employees in the company, instead of giving permission only for those that should have this access. 

Dave Bittner: Now, isn't it the case that a lot of times, folks will get access to something that they may need temporarily, but then that access is left with them? It's not revoked after the fact. 

Inon Shkedy: Exactly, exactly. And I think it's one of the results of the working in modern culture because today, it's a lot of work to, at every time, provide temporary access to one of the employees of the company or even, like, a contractor or a partner. So it gets to the situation where in many cases, the DevOps team or the Agile (ph) team, instead of, like, providing very specific type of permissions for a very specific period of time, they would just open the - like, it's like opening the firewall, right? Instead of, like, opening the port in the firewall for, like, two days, you would just open it forever. 

Dave Bittner: Right. 

Inon Shkedy: I think this is a very common way that attackers would get into these companies. 

Dave Bittner: Now, let's discuss APIs. Real quickly, for folks who may not be all that familiar with what they are, can you describe to us what they are and how they work? 

Inon Shkedy: Sure. So APIs, those are interfaces that companies expose. It can be used by different client. For example, you can have mobile APIs. So once you use Uber or Lyft any other application that's installed your phone, behind the scenes it uses APIs to communicate with the servers of the company and to gain information about your account and to perform different action. 

Inon Shkedy: On the other hand, you can expose the APIs to your partners. So, for example, if you are - let's talk about Veem for example. It would use APIs of different bank systems in order to communicate with them. So there are many different types of APIs. And basically, they're use to perform functions behind the scenes. 

Dave Bittner: And so what are the security concerns with APIs? 

Inon Shkedy: When it comes to APIs, actually, I'm one of the leaders of the OWASP top 10 for APIs, which is a list that defines the top 10 threats for API. And, you know, we were working to define these top ten threats - the most common threat for APIs - by analyzing bug bounty reports. And after some work, we assembled this list. And I think - you can take a look at the list and see the 10 different threats, but if you take a look from a high level, each one of the OWASP top 10 for APIs has a sense of authorization or authentication. I think the biggest threat today of API is lack of authorization or basically lack of permission check. 

Dave Bittner: And so what can we do to prevent these sorts of things, or what are the best practices for protecting yourself? 

Inon Shkedy: So first of all, I would recommend to think about this access control mechanism - you know, basically to understand which users should have access to which resources and to imply into the code itself. This is something that you can't just think about after you implement a system. You need to think about those things once you start thinking about implementing a new system or a new API. So I would highly recommend start building systems with security in mind, which authorization and access control is a big part of it. 

Dave Bittner: So it can't just be bolted on at the end, this is something that needs to be a part of your considerations from the get-go. 

Inon Shkedy: Exactly. You should think about it from day one, basically. 

Dave Bittner: And where do you suppose we're headed in terms of authorization? What does the future look like? What sort of technologies are going to make this easier for all of us? 

Inon Shkedy: Yeah, so there are a few different aspect of authorization. Because what we found when we created a list of the OWASP top 10 for API, there is no one way to do authorization. Because if we think - for example, if we compel authorization and authentication, these are two different mechanisms. Because when it comes to authentication, it's usually done in one place. You have one login endpoint. You have one provider to provide you access - or maybe a few. 

Inon Shkedy: But when it comes to authorization, it basically a mechanism that lives almost in every part of your application. In almost every piece of code should have some authorization checks - every piece of code that is exposed to the users, obviously. So authorization is basically a very widespread mechanism. You can find it in the API gateway, in the configuration files and also in the code itself. So in a high level, there are some solutions to try to build, you know, this umbrella that can provide you different types of authorization mechanisms under the same framework, and the open policy agent, the OPA, is one of them. 

Dave Bittner: How do you strike that balance between, you know, as you describe it, consistent and ongoing checks of authorization, but also staying out of the users' way, of not throwing up frustrating roadblocks? 

Inon Shkedy: Yeah, this is a very hard challenge. And I think if we take a look at one of the recent breaches when it comes to authorization - and by the way, Dave, the most critical authorization problem today, it's called the broken object level authorization. This is something that was found recently - last week - in Facebook. And we - during the last six months, we could find authorization breaches in Uber, Shopify and almost every big company this specific vulnerability. 

Inon Shkedy: So when you talk about this type of authorization problem, about broken objects of authorization, you can see that these big companies like Uber and Facebook, they have all the resources when it comes to security, and they have very talented engineers. So it's not, you know, like, a mistake of someone who is new in the field. But I think the main reason why we can see so many authorization problems is because of the face of deployment. You know, today with the concept of DevOps and the fact that these companies deliver a few times something every minute, companies can deliver new versions hundreds of times a day. I think this is one of the main problem that opens the door for authorization problems. Basically, the face of deployment, it's too fast. 

Dave Bittner: So we need to slow things down, check ourselves when it comes to that development pace. 

Inon Shkedy: Exactly. Exactly. I feel that, I mean, you can't really slow things down. But you need to integrate the authorization checks and the security checks in general into your life cycle, right? You can't just deliver a new code, a new feature without reviewing them. And I think this is a very important lesson that many companies have learned recently. 

Dave Bittner: So with everyone working remotely these days, you know, thanks to this global pandemic, what sort of problems does that present for us? Does this open up additional vulnerabilities? 

Inon Shkedy: Yeah. So I think the fact that today so many people work remotely together with the fact that many companies moved to the cloud and to microservices like (unintelligible) that were heavily based on APIs, it makes it much more challenging to define the barriers, the security mechanisms. And this is something that you should keep in mind. And I think this is - the fact that we are working remotely today opens the door for many authorization types of attacks, as we talked about. And it's very important to understand what device you include in your network and which of the employees that you give access to. 

Dave Bittner: All right, Joe. What do you think? 

Joe Carrigan: Interesting interview, Dave. One of the things that Inon is talking about here when he talks about permissions is the principle of least privilege, which means that you give the user the permissions that they need to do their jobs for the shortest amount of time you can to give it to them. And when they ask for more permissions, you evaluate whether or not you need it. And you give it to them for - you know, if they only need it one time for a day, then you give it to them for a day. And then you take it back. 

Joe Carrigan: And it sounds like a big security hassle to do this, but there are products out there that help you automate this. The retention of these privileges is probably impacted by the remote work situation because a year ago - or, actually, let's think two years ago - people were operating with a certain idea of what the future was going to look like, right? 

Dave Bittner: (Laughter) Right. 

Joe Carrigan: And it did not include everybody leaving their offices and going home. So... 

Dave Bittner: Right. 

Joe Carrigan: Now the IT and the security staff have to shift gears without having the time to plan for it or the budget to prepare for it. It's been a real hassle (laughter), to say the least. 

Dave Bittner: Yeah. Well, it's been a year now, though. So I would imagine... 

Joe Carrigan: Right. 

Dave Bittner: ...Most organizations have sort of settled into some sort of new normal. 

Joe Carrigan: Yeah. And I think what's interesting is that there's a good chance that a lot of these organizations aren't going back to having people in the office. They're finding that... 

Dave Bittner: Right. 

Joe Carrigan: ...Their productivity is fine or maybe even better with people working at home. I'm not the kind of guy that likes to work at home. I like to have an office to go to. I like to see people and collaborate with them in person. 

Joe Carrigan: I did not know that OWASP had developed a top 10 list of common vulnerabilities for APIs. I think that's great. And I looked it over. It's awesome. A lot of it boils down to permission-checking or authorization. In the security field, we have this thing called triple A, right? It's authentication, authorization and auditing. And Inon is correct. When you start building anything, you have to start with this in mind. And every piece of code should have an authorization check at least. It probably should also - if you're talking about zero trust, it should probably have an authentication check as well. And how that authentication check happens can vary by the implementation. 

Joe Carrigan: But the idea that most of the vulnerabilities that are in this OWASP top 10 for API are essentially just oversharing vulnerabilities, right? They're giving every user too much permissions. So once they authenticate a user and they validate that the user is who they say they are through whatever means they have, they don't validate that the user is authorized to access the information because the developers go, OK, fine. Well, we've got the user in. We know who that person is. We kind of trust that person, and we're going to believe that they're not going to go looking for things they shouldn't. Well, you should never believe that (laughter). 

Dave Bittner: Right. 

Joe Carrigan: People are going to do that. And not only that, but if a malicious actor ever gets a hold of someone's API credentials, whatever it is, they're certainly going to do it. 

Dave Bittner: Yeah. I think it's a real issue here, too, where people - the longer they're with an organization, they tend to collect permissions... 

Joe Carrigan: Yeah. 

Dave Bittner: ...Over time. If the permissions don't automatically expire, they, you know, say, oh, I need access to this. And they'll get access to it, and then no one really remembers that they have access. And so... 

Joe Carrigan: Yep. 

Dave Bittner: You have someone who's been working for you for a decade. And inadvertently, they have the keys to the kingdom, you know (laughter)? 

Joe Carrigan: Right. Yep. I had something very similar. We had a document management system that I used to manage early on in my career shortly before I became a web developer. I was a system administrator on a document management system, and one of my jobs was to assign permission to people to different folders and projects. And these people needed the access. And chances are they may have needed the access forever, but they probably didn't (laughter). 

Dave Bittner: Yeah. Yeah. 

Joe Carrigan: But they had it forever. You're absolutely right. This is what happens... 

Dave Bittner: Yeah. 

Joe Carrigan: ...Until that person left the company, at which point in time their account was suspended and they didn't have access to anything because, again, we're talking about the difference between authentication and authorization. Once I suspend their account, they can't authenticate. But once they can authenticate, they're authorized to view way too much information. 

Dave Bittner: Right. All right. Well, our thanks to Inon Shkedy for joining us. We do appreciate him taking the time. 

Dave Bittner: That is our show. We want to thank all of you for listening, and we want to thank the Johns Hopkins University Information Security Institute for their participation. You can learn more at isi.jhu.edu. The "Hacking Humans" podcast is proudly produced in Maryland at the startup studios of DataTribe, where they're co-building the next generation of cybersecurity teams and technologies. Our coordinating producer is Jennifer Eiben. Our executive editor is Peter Kilpe. I'm Dave Bittner. 

Joe Carrigan: And I'm Joe Carrigan. 

Dave Bittner: Thanks for listening.