Mackenzie Jackson: Hello everyone. Welcome to another episode of The Secure Disclosure podcast. I'm here with Sean Juroviesky. Sean, thanks so much for joining me here today.
Sean Juroviesky: Of course, really happy to be here today.
Mackenzie Jackson: One thing that I wanted to talk to you about today is to kind of dive into a more human element of security. It's something that you've talked a lot about. What always kind of comes up in security is IAM roles and roles and responsibilities. And when I hear that, my instinct is to go to tools that manage it. You think about it a little bit differently. So, I guess to start off kind of broad, why are people in managing people still such a fundamental issue that we have in security?
Sean Juroviesky: I think human people are just complicated. It's difficult to figure out what is needed and how to communicate things and how to just figure out people really, because communication is so key to identity and access and what's needed. And if you don't know every department, if you don't have contacts in every department, or understand how people are doing their jobs, it's really, really difficult to secure those people and ensure they have the proper amount of access, but not too much access.
Mackenzie Jackson: You said something interesting. You said secure those people. How do you secure a person?
Sean Juroviesky: Well, you find a nice room and you put up lots of lots of pillows on the walls.
Mackenzie Jackson: [laughter]
Sean Juroviesky: So, like this like
Mackenzie Jackson: Yeah, like, something like kind of vibe that we've got going on here.
Sean Juroviesky: I mean, my home office is insulation with a white liner over it. So, it really does look like I work from a padded room. So, yeah, securing people is difficult because I think a lot of the time we think about securing the tools, but really what we want to do from an IAM perspective is build a pattern around people that allows them to get their work done without needing to worry about security because if security is natural, if security is easy, if the easy way to do something is the secure way to do something, people don't build as much shadow IT and shadow danger and shadow security issues as they would if security is a difficult thing. If security is something you have to actively think about, it makes it a lot more likely that they'll go out of bounds rather than just keeping everything easy and fluid and keeping the easy path the secure path.
Mackenzie Jackson: When it comes down to access, what are the biggest challenges that we face in security? So, by this I kind of mean, all right, we all have people. People are at risk for security. That's natural. What are the vectors the attack vectors that you can look for in person and then understand their permissions and how do you understand if you have, I don't know how to frame it, but maybe like an insecure human? I don't know. What are the risks that you can look for in your organization?
Sean Juroviesky: I think people are inherently insecure. People just either don't know or they forget and they end up doing something that is then dangerous or risky. What you can look out for are specific patterns or certain individuals setting off alarms repeatedly, and then figure out why they are doing that. What is the root of those behaviors that's causing them to repeatedly set off these alarms? What are they trying to accomplish? Because often times I find it may be not all that rewarding to put effort into helping people do things in a more secure manner or to be more vigilant about security. Security often does not make hiring decisions. So, those people are going to be people you have to work with, so you can ensure that they can accomplish their job in a secure manner. So, often times people who are repeatedly setting off things, they just don't have the tools or the knowledge available to them about how things are supposed to go. You can work with them on bookmarking. You can maybe add extra precautions or extra rules about emails being sent to them. Maybe that individual can have a little bit more of an aggressive phishing filter than the rest of your company if they're often clicking on real phishing messages. It is, there's a lot of balance in it.
Mackenzie Jackson: Because when you talked about them setting off alarms, you're referring to having policies and processes and these tools in place to be able to catch behavior that's risky. And then kind of acknowledging that. So, what are some of those kind of tools and things? How do you start catching those alarms? Because that's kind of my first thought is I can understand if you pointed me to a risky human, someone that probably shouldn't have ample access and all of that. I could understand about doing that, but the process of knowing that that's a risky human?
Sean Juroviesky: I think a lot of that discovery can take place from putting logging around where they're authenticating, right? Are they authenticating from devices that are unusual, that aren't their normal devices? Okay, maybe they just had a session get hijacked from a phishing email, or things like that. You can put analytics around are they repeatedly installing software that's not approved? You should have alerting on your EDR, on your antivirus about unfamiliar applications. So you can familiarize yourself with it either through your company inventory if it's legitimate or tell people nicely, "Hey, that's actually not approved. You go submit that through the approval process." Which is often, I find, a good way of telling people no, if they're now aware that security is aware of the tool and you're asking them to formalize it, they might just decide to not use it instead of going through the effort.
Mackenzie Jackson: Right. Right. It's a lot
Sean Juroviesky: easier to tell people that than just say, "No, you can't do that," and be a villain in their eyes rather than a friendly person reminding them, "Hey, let's go through this process."
Mackenzie Jackson: Yeah. It is interesting that letting them know that something's watching, that there's eyes on this, changes their approach to whether or not they decided they need this or not. Something else that you have kind of talked about is building in security culture. And you've touched on it over here like making security easy and areas like that. Security is notoriously a horrible thing to enforce because you're essentially adding in roadblocks to it. How do you go about building the security culture within a company then, especially large companies like what you tend to deal with?
Sean Juroviesky: I think it's quite difficult. It's a slow process. I think the best first step you can possibly take is don't be a villain. Don't be, you know, the authorities. Be the friendly partner. Be a good positive aspect on things. Be friendly when people bring you an idea that we might find objectionable. Respond to them just nicely and courteously in a positive manner and say, "Let's think about that. Let's figure out how we can do that securely." And acting as a partner instead of saying no, just saying it in a different manner like, "Hmm, that's really cool, but I don't think legal will let us do that or the EU will let us do that."
Mackenzie Jackson: Blame it on the EU. That is such an interesting area. One thing you're talking about is having overly permissioned things. And I find this interesting when you kept talking to this because you brought it up a couple of times. One of the fundamental things in security is about having overly permissive API keys and things like that if we want to get technical. You're looking at it like having overly permissioned things in a human realm in terms of what they have access to. How do you go about uncovering who has access to what and starting to restrict that down? What does that process kind of look like?
Sean Juroviesky: It is an indefinite process. There are constant tools that people are uncovering, that you're finding out about that someone went and signed up for a new SaaS app and this and that. So, it is a process that is just forever. I do really recommend companies that have the ability to have a team dedicated to it, an actual identity access management team, because it is the number one cause of incidents, authentication-related issues, typically multi-factor authentication, but it's overprivileged and it's lack of MFA or even if they have MFA, it's fishable MFA, something like that. But, it is really, really difficult to actually build an inventory. There's a lot of tools you can use which can parse through your email suite looking for "Welcome to X company" and then they parse out a list of all of the various things people signed up for at your company. That can be quite invasive, especially if people are utilizing their email for non-business purposes. You know, you probably already have an explicit agreement with those staff members that you can't use your email for that. You can't use your email for house hunting, for dating websites, whatever. That doesn't mean people listen to that and if you remind people that you saw them sign up for a dating website, they're going to feel fairly uncomfortable.
Mackenzie Jackson: Yeah.
Sean Juroviesky: So, it is a lot to balance. It's a lot of ensuring you're not being invasive, you're not violating any of your staff's rights, but you're being proactive and finding and hunting for all these applications. Then, once you start finding applications, well, you have to turn it over to IT and say, "You need to manage this. We need this to sell on this. We need this. We need that." One method that can be fairly effective for applications, at least that cost money, is partnering and building a close relationship with your contracts team and with your finance team, and ensuring that they're aware that anything that is tech-related should have security stamp on it every single time. And it can be really, really rewarding to work with the finance team and get them on board with this, because there's a lot of also out-of-control spend that they probably don't know is not authorized and is not spend that the company's aware of.
Mackenzie Jackson: It's interesting because I think teaming up with that and having multiple objectives in terms of it's cost-cutting, but it's also securing, it's reducing your attack surface, and in different areas, teaming up with other departments is a very logical thing to be able to do, and can share the bad guy effect, I guess. You know, from that.
Sean Juroviesky: Yeah, it can be really, really effective. It can be a difficult process, especially for smaller things. I've seen a lot of resistance for applications that are like a $5 a month subscription. And the staff are like, "Do I really need to go through the contract approval process for this?" Well, yes, we do. They're retaining our data. We need an agreement with them.
Mackenzie Jackson: Yeah.
Sean Juroviesky: Otherwise, we could possibly be lying on our terms of service. We could have an incident happen, because sure, they're only quickly processing our data, but we are giving them access to it. So, if they have an issue, we now have liability, because they had an issue and you didn't get the proper agreements in place with them.
Mackenzie Jackson: Yeah. I think that kind of comes into an area, too, where a lot of people think about, and especially when you're from our perspective of you're dealing with smaller companies. I've always worked in startups, right? So, this idea of now the contracts and understanding anything, it's such an easy thing to do at a tiny scale, but it becomes exponentially difficult at such a large scale. Is this an area where you absolutely need to implement tools to help understand all of this? And how do you balance that line that you were talking about of being invasive but still needing to capture all the information that you have?
Sean Juroviesky: You don't really need to purchase tools for it. You can use your ticketing system to ingest requests for contracts and software. You can use your SIEM to ingest logs from your email source and ingest and create alerts for anything that says, "Welcome to X company."
Mackenzie Jackson: Yeah.
Sean Juroviesky: And then have your SIEM run that against a known list of known companies and if it doesn't match it, then it creates an alert. You can definitely do it in-house, but it is definitely something that you want to at least start doing because there is just so much shadow things, especially in the world of AI. There's constantly new services. There's constantly new applications. And even if the application itself is not an AI application, was it made by AI? What kind of vulnerabilities are there? How well-known is this company? Is this just a tiny little startup and they start making this one marketing tool and now your marketing team wants to start using it and it's like, "Okay, yeah, this SEO tool looks really cool, really flashy, but it was written by one guy in a garage with his best buddy Cursor. How secure is it? We're going to be feeding it statistics and data of ours as we want to ensure that everything's above board." So, you really need to ingest this information from somewhere.
Mackenzie Jackson: Yeah, for sure. Something that we talked about before in previous series is the idea around, and you mentioned shadow applications there, but you've also talked about Shadow AI in earlier years. What is Shadow AI when it comes to organizations?
Sean Juroviesky: That's a good question. That is a difficult question, but I think it's a question we need to be asking because really what is Shadow AI? Is a known AI tool that a company is using, but it's being utilized for a purpose that we didn't think about, that we didn't approve. Is that Shadow AI? Is having an approved tool that was plugged into another tool and that's also approved Shadow AI if we didn't know that it could plug into that tool and ingest data from there? With the scale that AI is growing, with it being incorporated into so much, or is Shadow AI a tool that you approved that only just released an AI feature and you had no idea about it and your data processing agreement with them doesn't cover AI usage in those sub-processors? Is that Shadow AI?
Mackenzie Jackson: Yeah, because it's interesting because when Shadow AI first came about, I was just thinking of it as in this is like, it's like using unapproved AI tools. But now you've just kind of opened that up as like, yeah, things are moving so fast that a new feature doesn't necessarily get rolled out with new terms of services, but if it is using AI and that has access to your data, like yeah, all of a sudden now we get into all these challenging areas.
Sean Juroviesky: Yeah, it is a wild, wild world and it is evolving really, really rapidly. I think a lot of what people can do about Shadow AI is just user awareness really. Like, hey, it makes me think of like World War II propaganda posters. If you see something, if you see an enemy plane overhead, let us know.
Mackenzie Jackson: Yeah, yeah, yeah, see something, say something. Yeah, I think that's part of the challenge and everything's moving and we have this fear with AI if that if we don't utilize it, we're going to slow down or we're going to miss out or like that. So we kind of have this irrational fear that we need to be using as much AI as possible. And yeah, just not even thinking about what it has access to and how you could do it. I had a talk today where we discussed using AI in CI/CD pipelines and how that you can just prompt inject it with a pull request title. And all of these things that you just didn't think that you had to do. How do you deal with Shadow AI? Another fun easy question. But how do you start this process of mapping out and understanding what all these systems and tools are doing?
Sean Juroviesky: It's a good question and it is a difficult question because there's a lot of resistance to getting all of these directly reviewed and approved. Plus there's a lot of effort because it's not just new tools that want to be used. There's existing tools rolling it out. Those have to be processed and approved and reviewed as well. So, it is a tremendous amount of effort because you already have a thousand applications at your company. They're all introducing AI functions. That's a thousand applications you need to re-review.
Mackenzie Jackson: Yeah. Yeah.
Sean Juroviesky: So, it creates a massive backlog. It creates a massive effort. A lot of what you can do is direct user awareness. At my company, we've been having AI coding weeks. Our company is about two-thirds software engineers. So, about two-thirds of the company are developers. Software engineers of some form or fashion in the engineering function. And we've been having AI coding weeks the past couple weeks. There have been demos about, oh, this new AI tool and this usage pattern of AI and what I've been doing with AI. And throughout these talks, the security team has had a presence. We've helped kick off the talks, talk about the security implications of this tool or this use pattern. And we've been having it as an active awareness campaign. Just slipping the security in without letting them know that we're mentioning it in the meeting. Because if they knew about that, they might not show it. But
Mackenzie Jackson: Yeah, yeah, yeah. That's an interesting way. I think that's the approach is correct, too, because I think a knee-jerk reaction, which I think most people have gone past now, is to try and ban various use cases of AI. I don't think that that works in any way, but it is interesting to be like, how can we embrace it, embrace it securely? And I think it goes back to something you were saying right at the start when we were talking about people. If the secure way is the easy way, or the way with the least amount of barriers, then it becomes the only way. And I think that's kind of true with AI. If you guide people into the correct tools and know what to use, then you can at least understand what's being used and the impact that they have within it.
Sean Juroviesky: Yeah, widely creating policies, procedures, guardrails, pipelines for creating all of these things. If you aid and actively, proactively push AI with the rest of the people pushing it, and you're inserting security frameworks and requirements and guardrails into the AI push, it's going to go a lot better than if you try and stop the AI push, because overwhelming amounts of people's companies are pushing this.
Mackenzie Jackson: Yeah.
Sean Juroviesky: And security team is often smaller, has a lot less power in companies to push it against it, so if you go with the flow, if you aid with the flow and just ensure that you're building in protections as you go along as best you can, and then when you have time going back and improving those protections, it's going to go better than if you stop everything, create a dam, and then start building all the frameworks.
Mackenzie Jackson: Yeah. Yeah. That definitely makes sense. What are some of the more risky areas that you consider when it comes to AI? Are there areas that you look at, like certain tools, or maybe people using AI in certain ways that kind of freaks you out a little bit, or that kind of creates more alarm bells than other areas? And how do you kind of set up to manage that?
Sean Juroviesky: So, there's two key areas. So, the first one I'll start off with, because it makes a big impact on the second, but over-permissioning of AI, especially AI assistants like Claude bot and all the other assistants out there, they might have been the first big one, but I just heard about a new one today, and I'm sure there will be dozens more similar tools by the end of the week.
Mackenzie Jackson: Yeah.
Sean Juroviesky: And so, matching it to rejects to ban it is not going to be all that effective.
Mackenzie Jackson: Right. Yeah.
Sean Juroviesky: But, those are all being significantly over-permissioned. They're being given the same permissions that the staff have themselves. And we really shouldn't be permissioning our tools to the same level that we have permissions because then they can operate autonomously without supervision. And even if you give them really explicit instructions about what to do, Replit just last year had a huge issue where their AI coding bot was being used by a customer. That customer gave it explicit instructions. There was a code phrase on production, "you can only touch the development database and development repos." Over the weekend, it deleted the development databases and rewrote the repos for production. And they had to do a massive data recovery. They had to roll it back, and the AI lied about it saying, "Oh, no, that didn't happen. It must have been something you did. It wasn't me." And then after they the person showed the evidence, it became repentant talking about how awful it was, how it wasn't worthy of the coins it wasn't just it, and it's
Mackenzie Jackson: It's very bizarre.
Sean Juroviesky: Yeah. These are autonomous tools, and they need to have really, really explicitly determined permissions for each specific task. You shouldn't give them a broad range of permissions for a range of tasks they might do. Each task should have a discrete set permissions.
Mackenzie Jackson: Yeah. I think this is very true. When we look at how we, going back to access and control, how we deal with access with AI is to pretty much give our AI agents long-lived, wide-scale, over-permissioned keys to various things because that makes sense. Well, that's the easiest option at the time. But actually segmenting it out into having smaller agent groups with limited permissions is definitely a much better approach to go down. What's kind of the best use cases that you see out there for AI at the moment? Are you using AI tools in your own security workflow? How are developers? Are you excited by the developers using AI? Does it terrify you? Where are you seeing the good stuff about AI being implemented in SoundCloud and other areas?
Sean Juroviesky: So, I just heard a really cool use case internally of someone who had this massive project he'd been dreading for over a year. We had migrated from one coding language to another, and so the service had to be migrated to this new coding language and made to be interoperable with these newer features we were rolling out. And it wasn't complicated work, but it was a tremendous amount of work. It was a tremendous amount of code, but he was able to do what he thought would be a four or five-month project in just a couple days because he was already proficient in the language, but having to rewrite the entire service into that new language was going to be exhausting. The AI rewrote it in the new language, migrated everything over, and then he because he did know the new language, he just didn't want to go through all the effort of doing it or just didn't have time to go through the effort of manually rewriting it. He was able to read through everything, understand everything it said, and okay, cool. This wasn't exhausting, but not complicated issue, and it saved us months and months and made a massive impact on our work.
Mackenzie Jackson: Yeah, it's cool to hear stories like that because I think especially on this podcast where you're talking to a lot of people about security, you often miss some of the cool stories about. And I think that goes just to show that banning AI is never going to work, because when you get use cases like that, it's like this makes so much sense. But it's all about how do we steer people into the right way. I always like to play a game with people before we go on. The game is called Would You Rather? I'm going to give you two shitty options, and you have to pick one from a security point of view. So, first one here, we'll start off one we'd like to kind of just kick things off. This is a regular occurrence. Would you rather have all your secrets stored in a Git repository, private Git repository, but in a .env file, or no firewalls on your public-facing applications?
Sean Juroviesky: Definitely the secrets.
Mackenzie Jackson: Definitely the secrets. I had one person say that he would pick the secrets, but only because you can rotate secrets. Like you, there's mitigation there. With the firewall, there's like not much that you could do. You know what I'm saying? It's like, all right. Another one. Your application automatically upgrades to the latest version of all your dependencies, so no pinning, just pulls in the latest version of everything, or all versions are frozen, you cannot upgrade regardless of the security implications. So, your application right now, this version, stays like that forever for its dependencies.
Sean Juroviesky: I would probably be a lot more entertained by the first option, but I'd probably freeze it. Because then you can, you can mitigate things around it.
Mackenzie Jackson: Right.
Sean Juroviesky: Yeah, you can add WAF here, whatever else you want to do. But if you're always on latest, I think we've seen a lot of fun, fun things from NPM lately.
Mackenzie Jackson: Yes. Yeah, yeah, yeah. Because there's a pretty big malware risk with that one. But the other, that one's an interesting one. I get about 50/50 for the responses with that one. All right, last question, last question here. Would you rather remove all your security tools, so you have no security tools, except you can implement like cloud code or some AI tools to do all your scanning for you. But that's what it does. So like just feeds it to ChatGPT, whatever. Or no AI in your security tools. You're going back to SAST and DAST and it's just pattern matching as we were five years ago. Which would you rather?
Sean Juroviesky: That's a good question. I'd probably have to go SAST and DAST just because I need the EDR.
Mackenzie Jackson: [laughter] Sounds good. Well, Sean, thanks so much for joining me. It's been awesome. I really enjoyed the conversation and I hope to get you back on the podcast sometime. Yeah.
Sean Juroviesky: I would love to be.
Mackenzie Jackson: Awesome. Thanks.
