Ep. #34, Positive Security with Siren Hofvander of Cybercom

Guy Podjarny: Hello, everyone. Thanks for tuning back in to the show. Today we have a great guest, a CSO, a Security Pony and many other things.

We're going to talk about that in a second. We have Siren Hofvander on our show. Thanks for joining us, Siren.

Siren Hofvander: Thank you very much for having me.

Guy: Siren, before we dig in to the topics that we-- There's a lot for us to discuss. Tell people a little bit about who you are, how you got into security, and what you do these days.

Siren: I got into security a long time ago. All of my friends at the time were developers and I was the only girl, and I was a difficult child and I had difficult teenage years, and they were all developers and it turned out that I was really good at puzzles.

So I got into finding where they missed things, so to speak, which I later learned was pen testing.

I fell into it because I liked making fun of my friends' mistakes. It wasn't a glorious-- It was just the fact that I was a brat.

I started as a pen tester, became a systems administrator. I was turning on people's lights at 3:00 in the morning.

I was super cranky and super salty, and I as many people do, I got really lucky and I knew a guy who knew a guy that was looking for a blue team security person.

I came in that way, through luck, and I started on secure development because I knew a guy that knew a guy.

I am unbelievably further lucky that the guy who took me on from my crazy red team backgrounds was a saint, and tamped down my rather wilder sides, and helped me to fall in love with the blue team and building things from a secure perspective.

I was really tired of finding the same bugs over and over again and it got to a point where you feel like you're kicking someone that's laying down. It broke my heart.

So I did that, worked at ClickTech, Securitas, Verisure-- I did their alarm systems, I was their product head for the Northern systems.

From there I went over and I got into the digital-medical space and I was a CISO for a company called Min Doktor for a couple of years, which was super cool, and I've recently just left that and I've started a secure development consulting team which is super cool.

There are a lot of companies that can't really afford to have an entire security team, so I've setup--

You can hire a team where you hire chunks of time from a range of capabilities as opposed to having to find "We need 30 of different skill sets from 30 different people,"and it's a year later and you're still not done.

I'm continuing my journey of trying to help people stand up.

Guy: Perfect. I think maybe we start from the approach, we start from people not from tech, or maybe from job definition aspect of it.

When you talk about doing security, you mentioned blue team and going into protection or defense, versus just the one finding holes.

You talk about--versus maybe the pen testing, the red teams. What is it that security team to do, even, in the first place? How would you even define the job?

Siren: I would actually avoid defining the job, because I think a lot of the problems come from a definition.

Because security is suffered from being something that a certain set of people do, whereas security is found in everybody's job and everybody has a little bit of security in their job.

Because everyone understands that "These are the risks within my particular function." So if you expand on that to take the security team's job, I would say it's helping people to find and identify the risks within their own areas, and being a supporting function for them in that journey.

That looks different if you're helping the finance team, or if you're helping the office administrator, or if you're helping a developer, but the function is the same.

You're helping somebody else become more risk aware and to treat those risks in a relevant manner.

How you do that can vary vastly, and it should vary vastly. It's the "One size fits all, we're going to document the problem to death or we're going to scare you to death with our pen testers,"that has made it really difficult.

I tend to say that the security team is like a seat belt in a car, or a seat belt in general. It's not the seat belt that prevents you from driving 900 kilometers an hour, but it is the thing that will keep you safe if God forbid something bad would happen.

The seat belt in a spaceship looks really different from the seat belt in a car, but they both have the same function of keeping the driver or the passenger in the vehicle safe.

Guy: Is it the security team's job to help build a seat belt, or are you the seat belt?

How much would you say when you are the security team, how much are you advising and consulting and making people aware of the risk versus hands-on creating, providing tooling, doing some of that work?

Siren: I think in a utopian scenario we would be helping other people to create their own seat belts, because everybody is an expert in their own particular area, and the best seat belt is always going to be the one that's the best suited for the context in which it's in.

That being said, security's done a really poor job of marketing how awesome it is. A lot of the hands-on stuff, a lot of the hands-on know-how, it just isn't there.

So currently the reality is I do a lot of stuff with automation, we do a lot of stuff in infrastructure, we do a lot of stuff with configuration and training and risk awareness and documentation.

But in a utopian state I want to be the person helping somebody else to make a seat belt, because one of the things that's always really bothered me with security is the fact that there's always been an idea of "You have to know this much to be secure," and just saying that it means that we're saying that some people are unworthy of security.

I like the seat belt analogy, because a seat belt doesn't say "It has to be a good or a bad driver, or a good or a bad person driving the car." The level of security should be the same.

I really dislike the idea of "We're going to blame the user, we're going to blame whoever it is for not doing something."

An agnostic consulting role is the ideal state. The reality is, I have literally picked up someone's dry cleaning to help them have more time to do security.

I have written the YAML files, I have done automated testing, I will literally clean your bathroom, because the end goal should be a more secure system so I'll do whatever it is.

Guy: You're very much describing security as indeed this supporting entity. Oftentimes, in many organizations, it's not like that and for a lot of people security is the big stick.

It's the one beating you down on the head when you misbehave, versus something that's looking to uplift you.

You've got the Security Pony handle, you're very much about positive security. How is that different?

How do you approach implementing this notion of support or positive security when you work with development teams?

Siren: I've led a couple of teams and I've always said that our job is always going to be to keep showing up, because security has done such a poor job of marketing and it's taken such an aggressive and offensive tone for a really long time that people are afraid of what we do.

We can see that as "It's not fair," and you can scream into the night, or we can be the person that's constantly showing up picking up your dry cleaning.

Because if our end goal is to have a secure system, then that has to be an agnostic approach. That can't be "I'm only going to do it if you're nice to me," because that's not an agnostic approach.

So you have to be able to give people space to be afraid of what you do, because they come from history, so it's constantly showing up with "OK. So this is where the problem is and this is how I can help you to fix it," and to be looking for a context and looking for something to make that person feel like you're there to help them.

Because that is truly what the security's function is. We are there to help, but we've done a poor job of presenting that help.

We've hidden it behind pen testing and documentation and being the big stick, whereas if you look at a lot of the really big security fails, I can guarantee that there were people on the inside that knew about those that were too afraid to go to the security team or to tell somebody.

They became worse than what they needed to be. Had they had a culture of "If you see something say something, we're here to help you and we can do this together," I think a lot of those could have been handled in a much better way.

Guy: How do you--? Practically speaking, when you run, how do you handle the typical size delta? Typically there's one security person to many.

If I focus on developers, because that's the core principle. Many employees, but also specifically many developers.

How do you do that? If you come along and you can only pick up laundry or dry cleaning for so many developers.

Siren: Exactly. Let's say the ratio is one to 100 developers, probably. One of the biggest areas I see that people--

Where security teams fail is that they try and apply more security onto a development team that probably is overburdened as it is.

Even if it is 100 people, they're working full-time. They're already doing something full-time, so you need to find ways of scooching security into what they're already doing rather than trying to give them--

"We're going to run static code analysis in a tool that's going to slow down your build with X amount of minutes," that's going to have an extra process, that they're not going to be able to see any return on investment or anything that actually helps them.

Rather than trying to take a standardized approach, you can do a lot of really good security tests in unit testing.

You could use dev tools and you can use a lot of the tools that developers are already using, and rather than take "These are our square Excel requirements," you can look at what they're already doing and manipulate security requirements to reflect that better.

Because I guarantee that a lot of development teams are already doing a lot of security work already. The problem is it's not visible.

So, they might have really good session handling despite the fact that there aren't any security session requirements have been written.

Why don't you write those requirements and bring that effort that's already being done to the light of their managers, to their bosses, whoever the case may be?

Because it's never the case that's 100 people that think clear text is awesome, MD5 is the way to go, and "Whatever. Throw it over." That's not the case.

But the work that they're already doing should be made visible so that they can get credit for something they're already doing, as opposed to showing up and being like "All of the standard security tools aren't here, the standard way of working isn't here, therefore you're doing nothing."

Because that's simply not the case, and it sets you up for an immediate adversarial relationship.

Because I've never met a developer that comes to work and says, "I don't care about security. I'm never going to do anything. I just want it all to be wrong." That's not the case. But what they are classically lacking is the ability to make what they're already doing visible and seen.

Guy: I think I understand and relate to the notion of celebrating the work of developers for the good security they do.

Let's hone in on that and then later come back out and talk about the tips and tricks on how do you prioritize. Give us some examples of how have you celebrated success.

You highlighted the session handling, or the likes. Give us a few other examples of this positive mindset.

Siren: We have "Cake for no reason" day. We've had "Cake for all the things that didn't happen," because the system didn't fall over so let's celebrate that.

I am a big fan of trying to spread knowledge in a way that people actually understand.

One of the prides of my life is developers when they've made a bug and I've helped them to see how to do it, that I see it come up in a code review at a later state and they're helping another developer to not make the same mistake and not involving my team at all.

Because they're like, "I'm never going to write this open redirect again," and rather than "You have to talk to the security team, you have to do this you have to do that," they're taking ownership of that issue and making sure that the next person in line doesn't make that same mistake.

I make sure that when I talk about security success I don't talk about my team, I talk about the person in the development team that found the security bug.

"Did you know that such and such had this really good idea? How can we make sure that such and such really gets time for this idea?"

Because it needs to be highlighting their work first, because we're a supporting function and that's not an ego thing, it's not an us versus them, it's us together.

Where what we're bringing to that environment initially is the ability to highlight somebody else's skill, because a lot of the time what's stopping development teams is confidence.

Taking that first step is really difficult, because there has been a lot of negativity and it's the buzz word, it's the cool thing to do.

No one really wants to raise their hand and be like "This is something I already do," unless they have a lot of courage or craziness, or they're on the dedicated security team because somebody could call them out and that's a really difficult thing.

What you can do is give them the confidence to say "I'm already doing this, and it may be small, but at least it's something."

This is also something where you can come in and say "OK. Management is saying we have all these requirements, but the development team gets no extra minutes to train, to learn, to do anything. Let's use our big stick for good and go beat up on the management to actually give them time to do it."

Guy: This really all boils down to being the developer's champion.

Siren: Exactly.

Guy: Which is a very positive thing, and highlight their work. How do you equip your team to help?

Because you described things like getting down to unit tests, or even uncovering a bunch of these things that you're doing.

Would you hire more coders, or more pen testers in terms of background? Like, to a security team that has that approach?

Siren: I would hire the person with empathy. I've hired a lot of people, and the first quality I always look for is empathy.

If you're a pen tester, if you're a coder-- I've hired really good people that can't code at all, but still work really well with development teams, but it has to be a person with empathy that's willing to pick up the dry cleaning.

Because as a supporting function, we have to keep showing up. It might take three months for the development team to lower their guard and really let us in, but once that's done you can have year after year a positive relationship with that team.

But it means you have to keep showing up for three months, and making sure that you worm your way into processes that may already be there, and it also means that you can't be the type of person that--

Here's where I see a lot of people that come from the really offensive side, this cross-site scripting bug is really bad but if it costs more to fix than the bug actually exploits, then beating the developer over the head with it is never going to be a positive.

I don't think I have a standard "It has to be this type of person," I think it has to be a person with a lot of empathy and that's willing to go the extra mile to solve the larger issue.

Guy: This is inside the organization, we've identified three parties here so far.

We talked about the security team having high empathy and having whatever is right in your constellation variety of skills to be able to apply that empathy and help out, and then you have management that might need that stick still, in the notion of "You need to make time and budget for this because this matters."

Then you've got the developers who are looking to celebrate, because they've got enough work on their plate as is, so you want to highlight successes versus focus on failures.

What about the compliance bit? What do the auditors think of this type of approach, when an external entity comes along with their stick how does that translate into the surrounding?

Siren: I really like compliance work, and I think compliance is another area where it's been misappropriated for big stick people and people that can-- I'm going to be really generalizing here, but can hide their lack of work behind a really big pile of documentation.

To go back to my seat belt example, compliance is a thing that says the seat belt has to go over the person and has to be connected to the car and actually has to work when the car stops.

All of those are compliance regulations written from the law. If they didn't exist it would be good enough to stretch my example a little bit further to throw a seatbelt in through the window of the car.

That is the end of the story. There's no one that I can think of that thinks that's a good solution for a seatbelt. Compliance has this, "You show up in the tie and you're a jerk," and I know a lot of compliance people that are like that and to them I say "Peace be on you. I'm not here for that."

But compliance can also be "Let's make sure that we take the integrity and privacy of our own staff seriously. Let's make sure we take the banking information that they give us in consideration. Let's make sure we treat their health data correctly."

A lot of these compliance rules aren't actually written as "You must do this thing in all circumstances always." That's not what it says, it says "Based on the risk."

A lot of what you can do with development teams you can actually do at a company, because it's based on the risk. It's a lot of "Are you aware of what you're actually doing?"

When I did pen testing one of the things that actually was the greatest return on investment was "These are the systems you have."

A lot of companies don't know what systems they are using, and that should be a huge moment that should be like, "Yes."

If you have packets that are super vulnerable, as long as you know about them and are treating them with due care that's probably going to be OK.

Guy: That's another aspect of the security team, or whoever it is that's handling compliance, because now you have that perspective and you apply that perspective internally.

Siren: Exactly.

Guy: Sometimes the auditor that comes in to audit your company, you don't necessarily have as much choice. You need to have--Basically, somebody needs to explain and bridge those gaps, and that's basically it.

The security team needs to be able to match those risk elements and explain that even if that conversation is a little bit more complicated than "Yes, I put this breaking thing or this hard constraint into my development process."

Siren:

The benefit of showing up and being a supporting function is that if you have a positive relationship with your developers and your QA staff, they're going to tell you where all of the dirty bodies are buried.

So when you're sitting there with an auditor, and I've sat with a couple that are shall we say less friendly and less solutions-oriented.

You can definitely make sure that you present information in a way that caters to the audience you're speaking to. It comes back to the empathy I was talking about.

Their job, and they're risking their own certification if they certify a company that's wild and crazy, so how can you make their job easier?

They're probably not technical, so sitting with a giant dump file of a configuration isn't going to help them, but walking them through how the configuration file is created and how you make it safe, the training the staff has.

It's going to make them feel like "Yes, this is a company that knows what they're doing." They'll lower their defenses as well.

There are jerks out there, but I would say that the broad mass of compliance people that I know, they just want to make sure that they're doing their job.

They're not there to eat you either. I would say compliance-- It's a natural part of my job, but it should be a natural part of everybody else's job too. Because no one just tosses a seat belt through the car window and is like "Done." No one does that.

Guy: This is an exciting scenario and model to run on. What are the primary challenges you came across when you were implementing this? Or, that you see around, and what solutions?

Siren: I think there were two major ones. I think the first one was, "It will never happen to us ever, because it never has." Which first of all, most companies wouldn't know, and second of all, isn't a good indicator of anything.

That's a really difficult one, especially if you're working with teams where it's the developers who've written the first lines of code, and it is their baby, and they will defend it as if it is their child.

The second one is, we say it's really important but it's not important enough to get time budget or emphasis in any real way from anybody.

Guy: Let's look into solutions for those for a sec. The first one was more developer-oriented, what have you seen to be successful?

Siren: I think it's not even developer-oriented, but let's focus on the developers because they're more interesting.

I would say you just don't even go into the argument of "it'll happen, or it won't." I don't even engage in that argument because I don't have a crystal ball or magical powers, no matter what myths about me exist.

I would say it's more that I go from a hygiene factor of assuming that this is a thing that could happen, "How can we tackle it to make sure it's less crappy if it does?"

I go at it from a problems perspective rather than a probability. So, if you look at cross-site scripting you can do a lot of that with framing and validation frames.

How can we make sure that the traffic that's passed from end point to end point, whatever the case may be, goes through a filter and make it easier so that rather than having to validate every input, you can do it from a framing perspective or from a back end perspective, and make it a development architectural question rather than a point of "This is where this particular bug is."

Because then it immediately goes from "We're solving something that could possibly happen," to "We're making our product better."

It happens to be cross-site scripting, for me, and that'll probably be what I may emphasize in a report or whatever the case may be when I'm talking to an auditor, but if I'm talking to a developer I want to give that person a problem that they understand and are passionate about.

Which is craftsmanship, it could be hygiene, it could be performance, it could be the latest tech.

I had a really interesting conversation the other day about authentication and serverless systems, where we were looking at security requirements from authentication but the system was serverless.

How can we have a threat model for that where it had absolutely nothing to do with the security bug that I found? It was assuming that we were going to do this, how could we do it better?

Because if it gets into a crystal ball that'll never happen, you can look at risk forecasting and you can make some really educated guesses. The problem becomes if it doesn't happen, you're going to become the little girl who cried wolf. A key risk is you have to be really careful and pick your battles.

They can't just be, "OAuth top ten says," it can't just be the latest exploit on Twitter, it can't be "My friend who does it."

It has to be something that actually delivers value and you have to be really careful that you don't become the latest glittery security whatever it is, it can't be everything that you jump on.

Guy: Do pen tests come in there? Like is there this notion of saying to the world, "This is a real problem we've observed on your code," do you need that? Or is that too little too late?

Siren: I think pen tests are interesting and I think they're more often than not poorly used. Pen testing should be a validation of the flow from requirement to production, rather than an end state check of "This is everything," because it's not.

A pen test-- You can take the most talented pen tester in the entire world with all of the tools ever, but you're paying that consultant for a time period, and if that person has a bad week they're looking in the wrong place, they can find things but they may not be the right things.

If there's an overemphasis on pen testing in a black box or a blind state, it can give you an overconfidence in security and you could also wind up fixing bugs that aren't actually problems.

"We found this super exploit on a system that's going to be killed in three weeks." That's not relevant.

Or, "It's a system that only two people have access to and we know that because they have FIDO keys,"and it's this, that, and the other thing.

There are lots of-- and I know there's just the Yubico exploit that came out the other day, but the amount of effort to exploit that bug is so high that it might not be worth it to actually fix.

What you can do with pen testing which can be really interesting is we have had an emphasis on validation from an architectural perspective, let's use pen tests to actually test the validation and verify the work that has been done in that architectural principle of validation for input fields, for example.

"How good was that work?" Because then the bugs that can come up, it can be-- All right, so we use Blue Monday for example. "Did that actually work? Yes or no."

Because then it's not the packer out in Wonderland, it's the developers that were trying to fix this architectural problem and they missed this particular part, "How can we make this more practical and more focused on what's actually relevant for them?"

Guy: Interesting. In this context I think about bug bounties sometimes as this like, less focused but constant. Almost like, I sometimes think of them as a pingdom for security results.

They wouldn't be like a pingdom, they wouldn't necessarily represent user experience. No they don't necessarily-- But they're a bit of a barometer.

How do you feel about bug bounties? Do you find them helpful, not helpful? How do you contrast them to pen tests or other team activities?

Siren: I've run bug bounties, both public and private. A few years ago I think they were really great, I think now they have been oversold and they've monetized bugs in a way that's just-- I don't see it as sustainable.

Because they're $800-900 dollars for a cross-site scripting bug. If that's the incentive of finding the bug, what is the incentive for the developer to fix that bug in three minutes if he or she can go home and earn $900 dollars for not fixing it?

The economy of the bugs just becomes completely skewed, and there's been so much marketing around it that you get a lot of people coming into the bug bounty space that aren't ethical and that have wild "I'm going to make crazy money," but don't spend the time looking for the crazy bugs.

So it becomes, "I'm going to blackmail your company," and all of that time to handle those people and to handle the PR, to handle that person-- All of those hours from the security team cost something.

It could be a really good way to do responsible disclosure and to give the security community a safe and a sane way to report in-bugs, but I think right now it's been so overly buzzword-y that it's become really damaging.

I think it's also because there's been an overemphasis on that. If you look at the budgeting for bug bounties when they first came out, it was super easy to get a budget, but now it's been a few years since and now it's super hard to get budget for bug bounties because the bugs are coming in but they can't be tied back to requirements.

They can't be tied back into business investment, they can't be tied back into strategy stuff, because it's random bugs. So, why are you paying for them?

It can be an awkward conversation if your management team isn't technical security, and most of them aren't. So it's a hard one to sustain, but I like the idea.

Guy: Very interesting. Maybe it's just an evolution element which you're describing around how do you define the scope for which you will get paid for that type of activity.

Siren: Exactly.

Guy: Maybe that's indeed going up and down both on the tooling side, but mostly on the community to company interaction.

Siren: Like I said, I've worked with many bug bounty people. I know a lot of researchers, and I think responsible disclosure is something that's really good, and I know a lot of people that report in because they genuinely just want to help a company to fix good problems.

Giving them a safe and a sane way to do that, I am all for it.

Guy: I think we've talked a fair bit here, like if I just wrap up in the meantime, it's to say we talked about empowering developers relative to security.

I think that's probably the strongest theme here, is around the security team as a supporting entity, and just like running a startup here, this is very near and dear to my heart because we have the same conversations about all the finance organizations or any IT organization, or even the people are HR people in the organizations.

They're really important entities, but their job is to help everybody else do their job better. Taking that angle to security is helpful, it helps developers celebrate their successes more than like bashing them over the head.

You gave a bunch of good examples of it, "Have the security team have a high empathy to be able to achieve that," this all rolls into that.

Then think about practical application of that in the context of software quality, of functionality and correct architecture, or feature building for your systems as opposed to just fixing a pointed bug that happens to be a vulnerability.

I think all of those are great advice. Thanks for sharing that. So, maybe teeing up a little bit, you're doing the security consultancy now.

A bunch of companies don't have-- I don't want to say that they don't have the budget for it, but maybe they just haven't chosen to hire yet.

There is a certain scale budget, and indeed they might just not be able to afford it, or they haven't yet built up a security team.

How do you see that work? Is that a part of what you're trying to do with this community?

Siren: Yeah. I think a lot of companies, not only do they not have the budget but they don't even really understand what they're looking for.

You see this with a lot of small to medium startups, and it's that we know we're supposed to be doing something.

So the first hire, "Who should that person be?" is a really difficult question because it's, "OK. If we pick a technical person, they're immediately going to be overwhelmed and they're not going to have the time to do the compliance and the GDPR, the larger program awareness training. But if you pick just a compliance person, all of the technical stuff may not be possible."

It becomes this weird "We're looking for the magical uniform that has 18 arms and that can do all of it," which is just an absurd-- I'm sure that person exists, but Google or someone else has probably hired them.

Where the truth is most companies need a wide range of skill sets, because there are a wide range of problems that need to be tackled. I have set up a team where it's--

We have security developers, we have security architects, we have people that are really good with encryption, with RF stuff.

But we also have people that can do compliance, we have people that can do requirements, the program my C-level, I can talk board.

So rather than set a company in the position of, "OK. We need something. Now we have to spend six months trying to find these 20 people."

It's a team that can help them stand up on their own two feet-- Not company two feet, figuring out what that means for them. That might be a team of people that might be consulting with other companies to have that help over time, I think that security can look really different for everybody.

It doesn't have to be "It must be this type of person, it must be the skill set." It is that one size fits all approach that means it's really hard to start, because so many people assume it must be a hire, and I think for some companies that's probably not true.

Guy: I think it's a really interesting angle, and frankly that goes hand-in-hand with that perspective on the support entity.

Because when you talk about, "You're too small to have a CFO" or "You're too small to have an HR person full-time." That's a bit arguable, given you can always hire people, but still a lot of companies take that approach.

Definitely a lot of companies outsource IT, and if you're not there then if you have that notion of "This is a GnA function, or like a general supporting entity that you need over here, why not have things that scale before you're able to either hire or fully staff that team?"

Siren: Exactly. I've hired a lot of people, and I'm the type of person that I want to be somebody that's helping other people to stand up.

I know a lot of people in security have that mindset, and so I think that it's a good way to enable them to help people in a productive manner.

Security is a hard job, and so it's hard to be the first person at a company because you get overwhelmed, and burnout is a real thing.

By having different options and "If you want to help people you can do this type of work," because this can't be the only consulting security team out there.

I'm not that genius, there have to be more. But I think the more options that people have to have security within their company, the better.

Guy: I do think it's a new-ish model in the sense of smaller companies. I think the notion of like, "Before you hire" is not one that is typical, I don't know if that's attributed to new approaches or just the rise of profile security people appreciating that they need to do security more.

Siren: I think security has been a buzzword, and now it's GDPR scaring everybody. The "Public cloud," and all of this stuff. So I think it's a new-ish model, but I'm hoping that it makes the community better.

Guy: I think to an extent with GDPR, it's another one that sometimes is often spoken in a negative sense, in a sense but it created a lot of fud. But at the end of the day it's the thing that forces you to build the right seatbelt as well.

It has all the right intention and it has mobilized an industry that has been waiting and procrastinating on a bunch of these things.

Siren: Exactly. I love GDPR, it has a lot of things that are wrong with it but the intention with the law is good.

If the security teams can help people focus on the intention of "This will give us more time to do privacy work."

I think most developers are excited about being able to do things well, I don't think anybody wants to mishandle people's information. We can use this as the ability to give them time to do that.

Guy: Indeed. Cool, Siren. This was a great conversation. We're already, as expected, going a little bit a little bit over time here.

Before I let you go, I like to ask every guest coming on the show if you have one bit of advice or one pet peeve or something you want to give or tell a team that is looking to level up their security. What would that be?

Siren: Start small. Don't add extra tools, don't add extra processes, don't do any of that.

Go and look at ASBS, and MASVS which are standard security development requirement sets and look to find the security that they're already doing.

Find ways to highlight that, because otherwise they're just going to get super conference burned out. "I'm going to do this," and then they're not going to have time to do it and just never do it again.

So, spend time to find and emphasize the work that's already being done and build on that instead, then you can add all the cool tools later.

Guy: I love that, it's super practical. Siren, thanks a lot for coming on the show.

Siren: Thank you very much for having me.

Guy: Thanks everybody, for tuning in. Join us for the next one.

Siren: Bye, everybody.