On this episode, James talks about security culture, shared responsibility, and security in your role. Tackling the challenge to integrate security into the development process? Looking for insights, answers, and practical solutions to avoid getting overwhelmed? Welcome to the DevelopSec podcast, where our focus is your success in securing and improving development processes. And here is your host, James Jardine. Hey, everyone. Welcome to this episode of the DevelopSec podcast. I want to talk a little bit about security culture, maybe. To be honest, I'm not a fan of the term security culture, but I think I understand what the purpose is. I'm sure you've heard of security culture tossed around in different conversations or seen it in post online. It may seem like just another buzzword. Right? The goal, even before we have the term security culture, is to help get everyone in the business considering the security risks and basically everything that is done. This ranges from making sure that each employee understands the security considerations for their job all the way up to the organization making security is properly prioritized. What does that really mean to have security considerations in your job? I've seen some people refer to trying to turn everyone into security people. To be honest, I'm not looking to turn everyone into security people. I don't think you need to be a security person to incorporate security into your responsibilities. Why security culture? Over the years, it has become clear that the security team can't act alone. It isn't feasible. While security can help put some controls in place to reduce some risk, it is not possible to be the most effective because they don't have access to everything. And to be fair, they shouldn't. This is leading into what is called the shared responsibility model where security has some responsibility, but also every user also carries some responsibility. The way I think about is there are risks with everything that we do. For example, think about cooking dinner. While we don't think about many of the risk, there are plenty around. You have a hot stove, maybe boiling water, knives to cut things, all the way down to potentially putting something that could make you sick in the meal. Things like making sure the meat is thoroughly cooked is something we're explicitly thinking about, but the risk of touching the hot stove is probably back of mind. The key here is that we are aware of the risks either by hearing about what happens or actually been through burning ourselves, and we take caution to avoid touching it. We don't inherently know the risks to these situations. Someone had to burn themselves or cut themselves to understand it or share the information with others. Knowing these risks doesn't make me a safety person, just means that I'm aware that the risks and I act appropriately. It also doesn't mean that I will never burn myself or cut myself. We are never a hundred percent risk free. We work to reduce the risk and hopefully know how to respond if something happens. To run your burn under cold water or to bandage the cup. Compare this scenario to a scam email sent to your work email address. From a security team perspective, controls are put in place to help limit these emails ever making it to your inbox, filters that weed out emails based on certain criteria. While this technology is always getting better, it can't stop everything. They may also implement a report email button to give users a path to report something that seems suspicious. Still not going to catch everything. Right? The users also have responsibility to be cautious of emails that seem suspicious. Over the years, some of these indicators have changed. It used to be looking for bad grammar, misspellings, that kind of stuff. These emails too have gotten more sophisticated. Now a common thing is just being wary of attachments you are not expecting or following links that lead you to a login screen. In the end, it relies on the user being able to determine if something seems suspicious or not. This is where breaking that down into roles can be helpful. Sure. There are some common things that everyone might find suspicious, but then there are the targeted emails, the ones that only a limited role would be susceptible to. For example, the email that pretends to be from the CEO asking for all the w twos to be emailed to them at a specific a specific email address because they need to do something ASAP. This isn't relevant for most employees because they don't have access to that information. It doesn't hurt for me to know that that type of scam exists, but it is critical for those in that position to know of these tactics. Being aware of this scenario will help the user take pause, follow correct processes, and hopefully quickly identify whether the request is legit or not. It doesn't matter whether you're a developer in HR or in the call center. There is some level of risk around your role. As you can see, there are some commonalities across all roles, and then there are things that are specific to each role. The goal should be to help ensure that people understand the inherent risks for their roles. As users, we should be open to learning the risks of our roles because it ultimately leads to us being better at what we do. The friction comes in when there is too much pressure to focus so much on the security that we start to lose sight of our actual work. If we put too much focus on security, nothing will get done. This is the risk of trying to make everyone a security person. It strips away their actual identity to try and cover it with something else. Security is a part of our responsibility. It is not the only responsibility. So where do you go from here? Both groups have some work to do. The security teams are already providing some basic security awareness training to everyone. It covers the common issues. The challenge comes when we start getting into specific roles and use cases. This can be difficult to scale, and we shouldn't assume that the security team understands all the roles. As users, we need to find out how to share this key information with the security teams. Security isn't a one way street. Create a connection with the security team and ask them how you can share information with them. Set a meeting to discuss your role and work together to identify the specific risks you might face. In addition, set up a communication path that if the security team sees a new trend related to your area, they have an easy way to share that with you. This opens the awareness up to more than just a simple training once a year. It becomes a real time update when the information is relevant. It also removes the need to create specific training modules for every role in the organization. Let's keep it simple. Real time feed that are specific to the role. I don't like to refer to it as security culture, but I guess if it needs a label for traction, we need something. I like to think of it as people taking pride in their profession, taking pride in their organization, taking pride in themselves. Most people wanna do the right thing, and they wanna do their job well. Too often, when a mistake happens, it has more to do with lack of awareness than anything else. If we can find better ways to share the right information at the right time, we will get closer to the results that we want much quicker. You have been listening to the DevelopSec podcast with James Jardine. To find out more about how we can help you with application security, follow us on Twitter at developsec, or check out our website at www.developsec.com.