Security Theater, Now Playing: When Security Is a Sideshow Instead of a Strategy

All right. Good morning, folks. We'll kick stuff off. How's everyone doing? Slight I'm not very impressed with this crowd. Last last session was uh more energetic. I think the coffee is wearing off, but we're close to lunch. [laughter] uh middle room uh in the middle of the conference. Um but welcome to day two of besides Las Vegas proving grounds. Uh this talk is security theater now playing what happens when security doesn't understand the product. Uh and it'll be presented by Mia Kowitz. Uh before we kick off, I'm just going to do a quick spiel here. We'd like to thank our sponsors, especially our diamond sponsors, Adobe and Aikido, and our gold sponsors, Formal and Profit. It's their

support along with other sponsors, donors, and volunteers that make this event possible. Uh, also, as a quick note, this uh presentation is being recorded, so as a courtesy to those that watch later and those in the room, please remember to silence your cell phones. Um, also, if there is time at the end for questions, I'll be uh around the room with a microphone uh just so that folks on the recording can hear it. Um, with that I will pass it off to Mia. >> Awesome. Thank you. So, to dive into this a bit, this is going to be our schedule. We're going to talk a little bit about me, where I come from, go through acts one, two, and three of this

play, and then some takeaways that you can have for your auditions. So, a little bit about me. I'm a career changer into tech about 5 years ago full-time. Before then, it was just a lot of pin testing and red teaming engagements that I was doing on a contract basis. uh but decided to move into this full-time. Um before that I did mental health coaching, retail management. I was acting CFO of a wealth management firm and set up a broker dealer for them. So definitely more from that background and then career changed in formally into security. Um my degree is in sports medicine premed. I did not go to med school. I worked in pro sports

for three seasons. That's a story for a beer as to why I decided I would never do that again. Uh but [laughter] decided to move on. Uh, as far as the tech stuff goes, always in startups, SAS products, um healthcare gaming fintech retail and currently I'm the head of security at, uh, my current company. So, let's dive into act one. So, setting the scene here, when you come into that new security org, they always tell you all the great things, right? They're like, we have frameworks. Look, we follow ISO and look at um all the things that we're doing with OOASP and here's the NIST stuff that we do. Look, we have these certificates. We have security. It's a

priority to us. That's why we're willing to invest in this headcount. Who else has seen this story before? Then you come in and you're like, "Oh my god, what did I just walk into?" Because we have a bunch of compliance and we don't really have security. And the reality is a lot of companies get into security after they get product market fit, especially in the tech startup space. So, it tends to be this after the fact bolt-on, how can you help us do things? It's either because they got popped um or because maybe a contract is pending the fact that they have a more robust security program. Um tend to be the two big ones as to why they start to invest.

And so let's take a look at a situation that actually happened uh at the company I'm at now. Executive leadership uh along with our CISO at the time and product security, we were all at a table and they came to us and said we're going to make a payments app instead of what the current app is. As security team, I know a lot of us bells and whistles are going off about how that is going to change our posture significantly and all the things that we need to do. What executive leadership was looking for was sign off from the CISO and what they got from us was a ton of reports. Now, our team had come from one of the big four

accounting firms. So you can imagine all of the paperwork that we see as proper due diligence of a feature review in a market pivot. That is not what they expected. So you have risk assessments. You had my team going and doing threat models. No one had seen a threat model before. And so they're getting beat over the head with report after report after report and not really seeing that this is the due diligence we should do in our role. In the meeting, executive leadership was like, "Whoa, this is way too much stuff. You guys got a 100 plus pages of docs. You have the 60page slides. Just tell me what's going on. Give me the TLDDR." And

we were like, "This is a no-go. We're not ready to do this yet. and see what happened. Well, there was a lack of education on both sides. They wanted more of a highlevel review in that sort of a meeting. We were trying to provide them all of the due diligence that we knew of and that led to this mismatch of expectations and the perception that we were trying to block the business because this wasn't just something someone thought up one day with maybe we'll do payments. This was a directive from the board saying you need to convert and now you have security saying but you can't do that. And once we started to run at odds there started

to be this loss of faith in the program and why we were actually doing what we were doing. We lost our seat at the table at a lot of really important meetings that we desperately needed to be in because again they saw us as a blocker. It was like how do I avoid these people? maybe bolt them on at the last minute to get a rubber stamp and not really hear them out. And when it came time to start to defund things, we all know how this works. If you're not getting hacked, there's a lot of times we're like, h maybe I can skim a little of the budget from the security program. And that's

very much what we started to experience as they wanted to cut back in volume. So that brings us to the second act. All the world really is a stage when it comes to security. We have our cyber security Shakespeare with his famous quote uh letting us know that we all have our entrances and exits and we play many parts in this role. So the expectation from the business was that we were going to do that due diligence. They knew we were going to produce all of those artifacts. They wanted that to be more internal. Maybe we follow up with some of the more implementation teams with that. But they were not expecting to get this report thrust upon

them in an executive review. What they were looking for was more of a thumbs up externally and then internally go talk to the the cogs in the will and have them figure out all these problems. But that's not what we had done. And our expectation was that we were going to do a proper risk assessment. We were going to look at all the observations. We were going to give appropriate remediation steps. they could go start to remediate. They could resubmit for review and then we can continue to iterate from there. But the reality is because this report was so dense and so thorough, no one read the thing. I remember about six months later referring to something in

the report to our chief product officer and he was like, "Me, I have no clue what you're talking about right now." And realizing that I had to go in and come up with a summary of sections of that for him. And at the end of the day, that feature was going to launch either way because it was business critical and we had to find a way to try to catch up. And so, one of the things here is that there's things that they just don't tell you in school about the role of cyber security. You have to find a very elegant way to tell people the baby is ugly. Not even like kind of ugly, like

this baby's hideous and we got to do something. And so, how do you do that elegantly? Because we've all seen this done poorly and then everyone gets their feelings hurt. You have the product manager who's been having blood, sweat, and tears to work through this and now you're coming in at the one yard line and calling this not good enough. And so we had to find a way to do that elegantly. We have to find a way for security to provide value to the business and not just oh well we're safeguarding you guys from something bad that can happen and that's really the ROI. No, how do we actually become a thought partner in the

business and respect it in that way instead of just being this bolt-on later on? And lastly, who are our allies? Because there's someone who championed this program in the first place who thought that this was enough for us to invest in. Let's be honest, all of us in this room, we ain't cheap to hire and we're certainly not cheap to retain. So, there was someone who decided that they should invest in this program. We need to know who that person is. We need to be able to be allies with them and lean on them when we need to. And also, there are probably other people who honestly have some security trauma. Maybe they got ransomware at the previous company.

They lived through log 4j and was like, "Oh my god, never again." Whatever their thing is, we need to know who they are so that they can help champion our our things with them. And that really leads me to our redemption arc. One of the key things that happened that I thought was interesting is that this quote came from an engineering leader who I could have put money on. This man hated me. Um, and out of nowhere, he told his team, "You can't just not tell security that this thing is happening. We don't do that here. You're going to go to them and let them know that this is going on." And in that case, it was a

new endpoint someone had stood up. we'll call it authentication that they put on there. We all know it was not real authentication and we were able to start to retroactively fit and help them relaunch that feature. But really, we have to help them get through this security trauma. We have to start to listen without judgment. This is kind of like that uh meme not too long ago or trend online of we listen and we don't judge. That's kind of what you do in security a lot of the times. So, we'll sit there. We're gonna listen to them. We're not gonna judge even if you really want to because you're like, "Oh my god, who would ever think this is

okay?" Inside thoughts. And then we're able to keep that and start to move forward. You start to really master your timing of your feedback. I like to think about this as like on a video game where there's always the meter of you got to stop it right in the middle middle. Can't be too early. Can't be too late. That's part of our role, too. If you're way, way too early, you're blocking me. You're not letting me ideulate. You're stopping creativity. The business needs to be able to move forward and be progressive. You're going to get that whole thing. If you go in too late now, the features basically launched and now you're stopping them and you're going to

hear, "But we could have 3x the business or raised 10% of transactions or whatever your important metric is that you now have stopped." And so, we want to me make sure that we're mastering our timing. We need to meet teams where they are. I really coming from that product security background. Some of my engineering teams are great. Some of them do not know the basics. Uh there are teams where I've literally had here's pseudo code of how to instantiate a uh a vault so that you can call secrets properly. And if I have to write that sample repo, I will write that sample repo so that they have something to refer to. Uh if it is a team that's a

little further along and it's here's some architectural guidance, here are things principles to keep in place, then we have those as reference docks as well knowing that there are times that we're going to have to hop on to calls with them to make sure that they're able to uh utilize those tools. And it further gives us information as to what needs to be in our next um security advocates meetings that we're training people in. what are the gaps for the business that seem to be more broadspread versus this one team just really doesn't understand this concept. So you got to meet them where they are and then help them take that next step whatever that looks like.

If it's additional meetings or investment in them sure if it is just being able to hear them out and work with their product managers so that they can have more bandwidth to do the security thing absolutely I can do that too. And so really there was a whole strategy we wanted to do. The big theme was we need to go from service to partnership and enablement. Security teams are always small. We're always going to be outnumbered by the development or and by R&D. I would love us to be closer to one to five, but if you're at that, let me know where you're at because I've never seen that. That would be absolutely amazing. We're always going to be a lot

smaller. And so we went from being this department of no to more of a department of how. How do we enable the team? How do we problem solve with them? How do we influence their roadmap? We went from being last minute blockers uh with here you can't do this payments feature to let's be in the room when we start talking about even thinking about payments to make sure everyone knows what we're starting to have to walk through. We went from being external enforcers of policies that a lot of times people didn't understand. Uh in fact, I remember one of our founders saying, "Please stop coming to me with these low context edicts. I need high

context solutions." I've heard that more times than I care to admit. Um I probably should have it on a bumper sticker by now, as many times as I've heard it from him. But we were able to change that and really start to focus on outcomes. What are we really trying to get them to do? How do we solution that instead of just giving a rule? We need to go from being this bottleneck to being a safety net. Making sure that yes, there is a baseline of security that must happen and that's going to tear depending on what the feature is. Uh is this publicly accessible, etc., etc. And then looking at transactional relationships. So going from us just

being here's a ticket, submit it to Prodac, we review, we go back and then we make an answer and we reply back to them. We want to have more of this ongoing conversation and this trust between our orgs. And so really what should we have done? Going back to that earlier example, we should have done a risk assessment with more thorough ratings. And with that, we should have given more solutions and guidance in a way that's digestible. And so instead of just here's your 120 pages of bad, can I get this high level? Here are some things that are going well. Here are some things that you do need to improve and then how do we get some sort

of guidance with that? Here are some suggestions to iterate and to make better. We're now involved in joint road mapping. they're going to have a major launch, we we know about it. We're in the room. We're able to make sure that I have the resources to do so. And if you have 10 of these massive things where I need to dedicate this apps engineer and then here's my cloud security architect who needs to be involved. Well, then show me the money. I need another headcount. And so, what can we do to make sure that we're building that business case? And it has worked. and they have given me headcount when I've showed in their road mapping this is

going to be a gap and here's all the risk that's associated we're looking at building security prioritization and frameworks product managers love to rice things or use whatever their favorite framework uh is if you look at the frameworks we're never in there we're never there's no security multiplier it's well you really shouldn't need this security thing to be a consideration because it's an edge case. It's never going to happen. US East1's never going to go down. Um, and we all know that it does. And then you're like, crap, we're in a single region. And so, how do we start to build in this security into our prioritization frameworks? One of the things that I negotiated in was a security multiplier

depending on the risk uh that is associated to the business. Another one here is looking at more of that self-service guidance. So again, sometimes it's sample repos, sometimes it's SOPs, sometimes it's general documentation. Uh, one of the things here honestly that I've started to utilize is our product managers because their security knowledge just isn't quite there yet or their compliance knowledge isn't. Can I at least give them an initial look at general things we're going to ask about? Sometimes it's all right. I do have a checklist of please keep these things in mind. Uh for some of them that are a little bit more junior, that's not enough. Feed it into this this uh system

that I've set up. It'll start to flag certain things to you so that when we have that first conversation, we're starting off at a good starting point and I'm not teaching you uh compliance for the first time. Here's what CCPA is. Here's what PIPA is. Um, we want to be able to start from a really good foundation. We focus on a lot more storytelling. Uh, especially executives. Executives love their stories. Um, they love analogies. That tends to be how they tend to gro things, at least when I talk to them. And so I always think about the fact that I could sit and tell my CD CEO that there's an IDOR vulnerability. Okay, he doesn't know what that is and he doesn't

care. And so what can we do to actually translate that over to something that he does understand? Here is what's going to happen. Here is how this is going to affect profit. And so starting to reframe things that way or the classic, are we building a $10 million uh fence around a $10,000 house? How do you know how do we translate that over? And that tends to be things that they can gro and they'll be able to walk away with. And then the last thing is shared tooling. Uh where I can I want my security checks to go in through the tooling that the devs are seeing so that there is no excuse for I didn't see it

or I didn't look log into your special widget. Nope. It went through CI/CD. You got your web hook that came through on this pull request that said that you made a mistake. Don't tell me you didn't see it. I know you saw it. It popped up right in your face. Let's make sure that we start to work through those. But our tooling internally has actually gotten so good that about a week ago, I started having our dev team say, "Hey, can we actually start to utilize your tooling because your inventory is better? Um the information is more uh live because of how we have it syncing and they just found that our our way of doing things

was better. So now we're teaching them how to protect and how to stay updated uh versus always going the other way around. So, a couple lessons from the film set. Security influence really comes from understanding the business and the product. Um, and it really it takes a lot of time. It takes some humility. Sometimes there's some gut punches uh that that we have to have along the way. And that's okay. And then we have early context that really enables this easy compliance because security really isn't just one role to play. You're their therapist that's got to hear about the guy who said something mean to them six years ago and made them feel bad. And

unfortunately, you're now the boogeyman who has to deal with that. You're the collaboration coordinator. You've got to pull in legal and let me pull in this person from product and let me pull in this person from R&D. You're going to be that. You're the technologist because try sitting in the room with engineers and not knowing what's going on. Now, no one's going to respect you because they don't think you know your stuff. and then your business thought partner. The other day I had one of our um our chief product officer reach out to me and say, "Hey, what do you think about this feature?" And my concerns had nothing to do with security. It was just I don't

understand why we needed to do this right now with other four features that they were launching. And now they're starting to see us just as a thought partner and not just the security team. And so really, stop the theater, learn the pot, stop being the NPC that they send on random side quests and you come back with 120 page reports. You need to be a part of the main party when you're going out on this adventure. So ask better questions. Try to understand why your business is doing what it's doing. Learn your product better than your product managers. That's a tough tough bar to clear, but if you can get close to being able to get to where they are,

you can really start to pull them off the ledge with some of the crazy features that they may come up with. And then don't assume trust. You got to earn it. Because at the end of the day, most people don't resist change. They resist being changed. So if you can make it seem like we're ideulating on this thing together, they're tend to be willing to go along with you on that. And so our last thing, your audition starts here. Here's a couple key questions you can ask. What does this feature do? What is it supposed to do? Happy path that we all know doesn't always happen, but happy path. What would this feature do? From there, we've got to look at what

does this actually add to the business? What value does this bring to our profit? Is this helping our bottom line? Is this filling some sort of gap for us? What are the timelines? that lets us know how much of this review we can do, how much we can enforce this change or do we need to call phone a friend and see what we can do to elongate the timelines? How could threat actors actually exploit this? And then what could go wrong? Worst case scenario, security compliance legally insert other uh entity, but what could really go wrong? Thank you. [applause]

Do you feel like a step in this process should also be collaborating with the business on defining risk profile and tolerances and thresholds? Cuz like when you talk about defining risk ratings and storytelling and everything else, high, medium, low is so arbitrary. It means something different to every single person. So getting the business to help define what those ratings are, what their thresholds are could help with that. Do you feel like that's also something you should include in this let's say list of precursors? >> Absolutely. Um, one of the things that I did was that I we have a general risk profile uh that we try to have for the executive team. um they tend to swing

wildly between executives a little bit but there is an overall business lens that we have as well. So I know generally across the business what do we consider high medium low critical uh but I also know um our CEO's general stance versus our CIO stance uh versus our CI CFO stance uh so that I know um not just what it means to the business but in the case that we actually have a really strong opinion who is going to be that person that can help champion

Hi, uh thank you for the presentation. Um do you have any tips and tricks uh how to get to the teams who are more stubborn who really don't want to come with the security? >> Yeah. Um so the teams that are more stubborn, I'm thinking of a team uh right now [laughter] that tends to be a little bit more stubborn. Um it tends to be uh the thing that got us in was helping them uh with something that I knew that they could not solve on their own with the skill set that they had. Um and was our support purely security? No, it was you are not going to be able to launch this feature in a resilient way.

Uh and here's the problem with your architecture. and really sitting back with them and then what we have like an architectural guild and them being able to see that we had the chops to really help them tended to shift it. Uh the other thing was that my new best friend was their EM and whenever we would have an on-site cuz we're largely remote um I made sure that I would go and chat with them, get to know them. And so it was this combination of expertise and just building the relationship uh that helped. But I'm not going to act like that was a fast solution. That was a better part of a couple months to really

start to turn them around. You're welcome. Probably have time for one more. So, in dealing with the people in your company that are like AI, AI, more AI, please because so I think you said you work for a startup, too. So, I'm sure you get a lot of that. What kinds of things in your role keep you up at night about that? >> Um, the scariest thing that I have is um let's do AI generated code and then let's do AI generated code reviews and I'm like holy crap where's the human? Uh, and [laughter] so trying to work with the teams to figure out where is the human in the loop because to me AI

really has like three big components for our use case. uh one is innovation within uh the app itself. Before if you search for a pizza shop, it was very much a string search. Let's find somewhere that has pizza in the title. Um building AIN allowed us to innovate to be able to um do more contextbased searches. It was something that a guy named Dave at my company really started to do and I was like that's beautiful and it's this very limited case. Um looking at some of the expertise that it's enabled us with I would say the product teams uh giving them tooling uh to say hey you want to do this here's this very contained instance that we

have lots of control over but you can feed in your PRD to at least give you a baseline for us to have a good conversation and then the last thing is just reducing toil where we can which we're still honestly experimenting with what a good use of that would be for us. Um, but those would be the big use cases. But the thing that keeps me up at night is really we don't need to vibe code and then use an AI to see if we're safe. There needs to be someone in there who knows what they're doing actually helping to steer that ship. >> We'll make it. All right, let's give me one more round

of applause. >> Thank you.