Great Minds Think Together: Code42 Security Guild

DevSecOps, Positive Security Culture

How do we scale security in development where resources are scarce? The typical answer is via automation, but how do we automate people?

Having worked in security for a few years now, I often find myself with much more work than time. For instance, when I started as an analyst, I had about 10 application teams working with me to ensure security requirements and testing were completed. When I left that position, I had 40 teams requesting that I help them secure their application.

The problem: I am not scalable.

This led me to wonder: how can we support individuals who want to be secure in a way that is scalable? One answer is collaboration.

People can’t be automated, but we can deputize security across the organization. The right way for Code42 was to start by trusting developers to “Do It Right” while they “Get It Done”. We can allow developers the autonomy to learn how to code securely. We can also rely on them to run static code analysis tools and entrust them to include this within their deployment pipelines. If we give developers a safe place to address security concerns, we can achieve more together.

As an added bonus, security no longer blocks anyone’s work. We can simply be available to developers when needed to review any findings or concerns.

Because they have addressed the low-hanging fruit, developers are able to address the hard questions about security: where and when it can and should be applied.

Developers are the experts of their domains. They know how security modules will impact their application, and they know where that can happen in their implementations. Furthermore, have you ever looked for a security professional with extensive software development experience? It can be like trying to find a unicorn. If you’ve found one and happen to work alongside them, consider yourself lucky.

At Code42, we have a Security Guild made up of volunteers from each development team along with members from the security department. These are the folks you want participating in the guild, as they have a general curiosity for how security affects the projects they’re working on, and can take their learnings back to their teams.

Each team’s representative becomes the security expert on their team, and the guild meets regularly to discuss security-related topics. Each representative brings questions and concerns from their development team to review as a team.

The security team benefits, and the developers do too!

The security guild allows developers to grow their skill sets. The security team benefits from the visibility into the security concerns of their developers. Together, both identify and develop solutions as they collaboratively address their concerns.

A great example of this partnership is when we gear up for the annual Secure Code Review training. As a guild, we review the questions, add new ones, and customize them to topics relevant to us in the current moment. We also take time to have honest conversation on whether the questions are confusing or biased and work towards a better question. This collaboration across departments ensures that we continue to further strengthen our relationships and bring value to one another.

How do you scale your security engineers?

My take: I’ve been in this role for a few years now, and I’m still learning and growing. I think the most important thing is to be engaged first. Learn how developers receive and do their work. Choose courage and be the person who asks the “dumb” questions. Find balance and hold each other accountable for security. Lastly, discover ways to be collaborative within the organization, because together we win.

At Code42, we are lucky. Our company’s dedicated and engaged employees drove the success of the Security Guild. We’ve encouraged everyone to see security as part of their responsibilities and inspired our most security-curious employees to educate themselves and grow their skills. With great minds thinking together, security is achievable.

Creating a Positive Security Culture

Positive Security Culture, Security Culture

Why create a positive security culture in your organization?

There’s a lot of buzz these days around having a positive security culture. It was the basis for conversation at this year’s Forrester Risk Summit around Trust. And it’s a key factor in the new Cybersecurity and Infrastructure Security Agency (CISA) Cybersecurity Program Goals (CPGs). The benefits are aplenty; reduced friction between security and other departments, increased collaboration with users and an overall improved working environment, to mention a few.

Despite these benefits, there are costs. Moving your team from a traditional security approach to embracing a new way of working, not to mention a new way of interacting with others around the company takes intentional effort and may not happen overnight, especially if you’re coming from a “no” based security culture. But it can happen and is doing so at increasing speeds across the security industry.

How to create a positive security culture

While every organization will have its own nuances and cultural norms to consider, there are foundational elements to establishing trust and creating a positive security culture – we’re going to give you a roadmap and outline them here.

Part 1: Have a Vision

Critical to most organizational success is having a strong and well communicated vision and mission. CEOs proclaim them from the mountaintop and share them on their websites so customers and potential talent know where they stand, what they are about and where they are going.

This is key information to keep everyone driving toward the same finish line and for top talent to consider whether your company will be a good fit for them or not.

I think most CEOs would agree with this statement:

According to a study by Bain and Company, organizations that align their vision and mission statements with their strategic plan perform better than those that don’t plan their vision and mission statements carefully.*

Some organizations and boards hold tight rein of the mission and vision statements and wish to have only company-wide statements to avoid confusing employees. Yet if those statements help drive success for the company, something similar that roles up to those for your department will help everyone to stay focused on the same goals.

So, maybe we call it something else such as a Team Brand Statement like those used for individuals as they grow in their career paths. This is what our CIO/CISO did at Code42 and it has become The Way or guiding light for everyone on her team. I can tell you it has shaped our security culture in the most magnificent way and at the same time it helps drive productivity.

Part 2: Develop and Implement a Security Team Brand Statement

When building your team brand statement you’ll want to keep it strong, succinct and catchy so it is easy for everyone to remember. It should help others understand what your team does, why it does it, and what makes it successful in building a positive security culture.

A good team brand statement keeps the main goal front and center. What do you want to be known for or remembered as? For instance, as a difficult team issuing roadblocks or a partner team helping departments meet their goals and solve their problems more securely.

Another key aspect of a good team brand statement is clarification of your guiding principles or what you believe in that drives all projects, interactions and decisions.

Here’s an example of a good team brand statement:

SECURITY TEAM BRAND STATEMENT

What do we want to be known for? Remembered as?

We believe in:

Trust, Transparency, Collaboration, Protecting <our company>

We are known for:

We are known as trusted experts who create and maintain a world-class program by building trust and transparency with our stakeholders. We transparently share how we watch data to help build trust with users.

We support a positive security culture by presuming positive intent when risks occur. We are empathetic listeners as we partner with users to lower risk to data. We are enablers of a collaboration culture while keeping the company safe.

Once you have a draft brand statement, partner with whomever you consider to be your trusted advisors for feedback. Ask them:

Are these the top level items we should be striving toward?
Do these position us well to support the success of the organization?
Is this something we would share with our stakeholders and partners?
Are these straightforward and actionable for the team?
Are these memorable?

Take that feedback, run it by the leaders on your team and ask them the same questions. Allow a good amount of time to really dig into it. Consider doing an offsite event around it. Remember, this is important in shaping the culture of your team, so spend the time to get it right.

When it is ready for prime-time, share it with your entire team, going over each statement and adding examples for clarity. Give them a chance to weigh in and provide feedback. Make adjustments as you see fit given the feedback you’ve received.This should now be in its final state and ready to rock and roll.

Part 2a: Implement your statement

Help your team keep these goals top of mind by posting it where it’s easily accessible to them, perhaps in a corporate communication or collaboration tool. If y’all are now coming into the office at least once a week, post it on the wall!

Your brand statements are only good if they’re actually used. When you see small acts by members of your team that align with any of the statements, celebrate it! Calling it out as a win to the rest of your team will breathe life into your statements as the team sees you noticing their positive behavior. As you see more and more of your team rallying around the statements in everything they do at work, and through partner and user feedback, that’s when you’ll know that your Brand Statement is truly alive and well.

Part 2b: Repetition and reminders

As with anything new and especially when we’re seeking behavior change it’s important to help the team keep the Brand Statement top of mind through reminders. Daily is too much, but maybe a quick reminder at monthly meetings at first, spending just a moment on them. Once the team is operating successfully with the statement, you can reduce reminders to quarterly as a check in to keep the statements top of mind.

Use an annual review cycle to keep your documents in line with business changes so that your statements don’t become stale. Doing so annually helps set an expectation from your team on when they might expect updates or changes to the statements. Conduct ad-hoc changes only when absolutely necessary to reduce change fatigue.

Part 3: Build Trust – Every. Single. Day.

Another key component to a positive security culture is to build trust across your team. Trust starts from within the team and then extends outwards to users and partners across the enterprise. Only when employees trust the security or risk team will they come to them with questions, comments, or concerns. As most security frameworks include training employees to report concerns, users are more likely to engage with your team if they’ve had positive interactions with them. This Harvard Business Review (HBR) article on trust sums it up perfectly, “In short, to boost engagement, treat people like responsible adults.”

Positive security cultures and Insider Risk Management (IRM)

As you build an Insider Risk Management (IRM) program, the components above will work towards its success. You’ll want to consider using empathetic investigations which are uniquely different from traditional security investigations since you’re investigating your colleagues rather than external actors. It’s the right approach if you endorse a positive security culture within your organization. But as with anything, if it doesn’t match the culture of your team it will fall apart. So, first things first, let’s get your security or risk team on the same page with your vision of a positive security culture. For instance, if users get positive replies from the security team every time they reach out with questions or concerns, your insider risk team will be met with a more cooperative user when they reach out to them when, say, the user puts data at risk. It can mean the difference between the user panicking and denying any knowledge of the situation to someone who does not feel intimidated and is therefore more likely to cooperate quickly and transparently.

Of course, there are many more factors to consider when adopting a positive approach, including the benefits of transparency along with trust, which you can read more about in a recent Code42 blog post on the three “T’s” that define an IRM program.

Change can be challenging so have some compassion and remember, when you see someone on the team not adopting the new team brand, take the moment to highlight how they may have responded differently as soon as possible. Old habits are hard to break so it’s easier to simply replace them with new habits or incremental changes. You can read more about breaking and creating habits in B.J. Fogg’s book, Tiny Habits.

Acknowledgement

Most of the ideas expressed here were generated by way of our Chief Information Officeer (CIO)/ Chief Information Security Officer (CISO), Jadee Hanson. She has created a highly positive and productive security culture using several tactics based on a strong brand statement. Many thanks to Jadee for leading the way in a functional positive security culture!

Resources

Bain and Company Mission and Vision Statements

Cybersecurity and Infrastructure Security Agency (CISA) Cybersecurity Program Goals (CPGs)

Harvard Business Review (HBR) article on trust

Code42 Blog Empathetic Investigations

Code42 blog post on the three “T’s” that define an IRM program

B.J. Fogg’s book, Tiny Habits

Captivating through Captioning

Risk Aware Cultures

… and other times security awareness is made better through accessibility

In Security Awareness, we spend a lot of time developing content and activities to get people to pay attention to cybersecurity. We put out videos, we host speakers, we create gamified training opportunities, really anything that we can think of that can grab your attention for a few minutes. When we do these activities, are we also thinking about how all of our employees are receiving that information?

By spending time designing our messages for accessibility, we often find that the messages are enriched for all. Increasing accessibility can in turn increase comprehension (including for people with English as a second language), increase findability, and increase traffic to our sites.

Here are a few examples of how I’ve increased accessibility through our Security Awareness program at Code42:

Burn captions in on every video – this makes the captions always available regardless of where it’s posted
1. There are many ways to get auto caption files. Additional curation is necessary, but the bulk of the work is done automatically.
Transcripts for trainings are available
1. In addition to providing an alternate way for users to engage with the training, it also increases findability when people are looking for information later
Record audio for Slack posts that are longer than 3 sentences and post it along with the text
1. An additional delivery method can help people retain the content based on their learning style
Review how screen readers read your content
1. Especially when I’m posting on Slack and using emojis, I consider how a screen reader will read the emojis I’ve used
Make sure there is adequate contrast between colors used and that color isn’t the only indicator of differences (e.g. using different icons to indicate change)

This isn’t just for awareness and training either. Whenever we deploy a message in our organizations, are we considering accessibility? What I’ve found is that if I increase the accessibility of the message, more people comment on how they didn’t realize they needed this in their life. We shouldn’t wait for the employees who need accessibility to reach out and ask. We should just do it because it makes us all better together.

How We Made Threat Assessments Fun

DevSecOps, Risk Aware Cultures, Uncategorized

At Code42, we move fast, but our security process and the way we do threat assessments has had a tough job of keeping pace with our development teams. Add the pandemic to this challenge and we had a hard time keeping our developers engaged in this critical process. This year, we took the opportunity to rethink how we do threat assessments by making the process virtual and in line with our current development environment.

At Code42, we have been playing Microsoft’s Elevation of Privilege (EoP) game. When it was first created, the game was pretty ideal as a threat assessment tool for application development. It allowed players to use their creativity and think through possible ways to attack their application using the “STRIDE” framework. STRIDE is a mnemonic for Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege, each a mechanism for attacking a service.

As a DevOps shop, we definitely find STRIDE has a lot of potential for threat assessment, but the EoP game as-is doesn’t address all areas of development at Code42.

DevOps has reshaped traditional roles and responsibilities in application development. The lines of who is responsible for what tend to blur between different teams and the cloud computing environments in use. When we used to play the game, some of the attack scenarios were pretty outdated and only focused on a small fraction of the space in which our teams are creating products and services.

We needed the game to be relevant for the microservice architectures our developers use such as on-demand functions, containers, virtual machines, load-balancers, web stacks, authentication tokens, and the like. And still, we want the game to represent both the endpoint application development environment, and reflect cloud services, micro-services, and distributed computing environments as well.

Furthermore, we want to focus on the challenges of our highly distributed development environment where teams are focused on UI/UX, front-end interaction, back-end databases, metrics and telemetry, and infrastructure deployment. We want to ensure we capture a broad view across all development environments that are needed, and not just focus on how an endpoint application is secured.

With the greater power that is DevOps comes great responsibility, and we wanted the game to challenge our developers to think more broadly about the systems and environments for which they are developing. This approach gives the developers and the security team more insight into our product so we can better defend against future attacks.

For those reasons, we found a new way to conduct threat assessments, with … another game!

To play, we start off with a review of the type of feature being developed, its infrastructure and architecture, and any additional components in play.

One of the most crucial roles in the game is The Scribe (aka facilitator). This person will guide the conversation, take notes of any findings, drive the threat modeling conversation, and award points as needed. The second most crucial role is that of the Subject Matter Expert (SME) – they can be called upon to clarify an attack or validate a proposed remediation. The Scribe will divide up the attendees into two teams, and ensure that a SME from the scrum team is on each team.

To get started, the facilitator calls on a player and offers a STRIDE category scenario. To score a point(s), the player will read the attack listed and then provide an example of how an attacker could use that particular vector against the application. If the player cannot think of anything, they open it up to other players on their respective team to offer an attack scenario in that category. Additional points will be awarded to the team who can come up with a viable attack, regardless of severity, and to those who can provide the mitigation technique (especially if it’s one we’re already using).

If the player requires help, they can ask for a hint on the application or “phone a friend” and call on the SME. For the hint, we draw from previous experience in pentests or the latest CVEs that have been reported. To keep the game moving, each category will have five minutes for discussion and brainstorming. The opposing team will then have one minute to provide further attacks or mitigating techniques. This will be played until at least all of the letters in the STRIDE Framework have been reviewed.

The team with the most points WINS, but really, everybody’s a winner when they play with the security team!

The goal of this game is to get developers to put their security hats on and think like an attacker. Given the nature of DevOps, we will continuously refine the threat modeling scenarios to make this a better learning experience for all involved.

At the end of the day, we believe playing games will allow our developers to stay engaged with the security team by seeing attack vectors from the perspective of an attacker and at the same time, have fun in the process.

Don’t Throw Away Your Phishing Program …Yet

Phishing, Risk Aware Cultures

I’m hearing more and more discussions on how the act of phishing employees actually creates more harm than good. The arguments in favor of ditching your phishing program are compelling.

It can tick off employees and consequently create a rift between them and the security team for a variety of reasons through:

Enticement/misleading promises
We’ve heard of companies using phish templates that promise enticing things like bonuses, free products, etc. The employee gets excited (feels good) just to learn it was a company exercise (feels tricked). Resentment toward the security team ensues.
False Positive Results
These are common and are usually due to other security tools “checking” the links. See Nathan Hunstad’s post on the latest issue we noticed with our phishing program. A false positive shows up as a click on that employee’s account even if they never clicked, in fact, they likely even saw and reported the email in good, secure fashion. Any additional training that pursues from this “click” is bound to cause resentment and is unfair.
Training overload
As if our employees don’t already have enough required security trainings, some companies send additional training to “clickers”. This results in training overload, burnout and resentment. Not to mention it’s ineffective.
Smack Down
A new employee joins the company, is excited about the new opportunity, has good will all over the place and then gets “tricked” by the security team with a phish. All that was accomplished was either embarrassment, disappointment or even resentment toward the security team and potentially against the new employer. Eek.

These are real concerns to which security teams need to pay close attention. But the answer is not to throw the phishing program out the window because a GREAT phishing program can avoid these pitfalls and at the same time strengthen defenses against phishing threats, a long-standing vector for attackers, especially in successful breaches as noted year over year in the Verizon Data Breach Investigations Report (VDBIR).

Email filters can be effective and greatly reduce the number of malicious attempts that actually make it to your employees. But they don’t catch 100% of the risks and even if 1–3% of the attempts make it through, as you are well aware, it only takes one click for the attacker to get the upper hand. The occurrence risk is low but the impact risk ranges from high to incredibly high, depending on the damage that could ensue. And until that magical day when our filters are guaranteed to be 100% effective in catching all malicious emails that come our way, you can quite easily engage your employees to be your human firewall without damaging relationships and the reputation of your security team.

To do so you’re going to need a plan and the right folks to carry it out. Luckily it’s easier than you think but you’ll need to make the INTENT of the program clear to all and then follow up with a risk-based approach. If damage has already been done at your organization, it might make sense to take a few months off to give your employees some time to cool off and for you to rewrite your program. It’s doable. At Code42 we’ve brought our click rates from upwards of 25% to less than 3%, on average and our employees actually enjoy the challenge. We didn’t get there overnight, as you’d expect with any good outcome, it took time and patience. Here’s how we did it.

You Need Their Help
It is so critical that employees know why you phish them, what it means for you and for them and how they can be a part of reducing risk for the company. They have a vested interest in the success of the company — that’s where their paycheck comes from and where they spend a ton of their time. They also likely hold pride in their work. So most everyone will understand it when you tell them that the security team alone cannot protect the company. We need them to help keep the company secure. We won’t be nearly as successful without them. Instilling this call for help appeals to most people. If that alone doesn’t do it for everyone, read on.

Intent
Your employees must know your intention for the program. It should never, ever, ever be about trying to “catch” anyone. In fact if you are choosing templates because you are sure it will cause people to fall for it, you better be darn sure that it is a template that you see coming from the wild and making it past your filters. If not, what risk are you addressing? Work with the team who sees what types of phish emails are making it past your filters. That is your real risk — that’s what you should mimic. Anything else is a futile exercise that wastes time, achieves little and frustrates many.

If you are seeing phish attempts in the wild that may hit close to the heart of your employees, such as free virus testing or vaccines, consider communicating about those to all users and include a screenshot rather than sending the phish, as the way to inform them. This is a more ethical approach and will help avoid the emotional roller coaster of good things promised followed by, what they’ll perceive as a slap in the face. Believe me, I learned the hard way on this one.

The Goal
Make it clear that it is not your desire to “catch” anyone. In fact, the goal is to catch absolutely no one (achieve the elusive 0% click rate). To that end you are going to give them opportunities to practice, because we aren’t good at anything in life unless we practice. Natural abilities only get us so far.

At Code42 I have the luxury of following up with everyone that clicks after each exercise to learn more about what happened because our click rate is so low. I tell them at onboarding to expect me to reach out but it is only for two reasons 1) to check if it was a real click or if technology interfered (see Nathan’s post mentioned above.) And if they say they didn’t click, I will absolutely believe them. I’ve had colleagues laugh at what appears to be gullible innocence. The way I see it; what’s the point of being skeptical or cynical when it comes to an important relationship? And what relationships succeed without trust? 2) if they did in fact click, I ask what happened (they usually offer it up first) so I can learn where our employees are failing and use that real world information for further education for them but importantly for others (with no names mentioned) about pitfalls we are actually seeing.

What to do about the clickers
We’re human, that’s why phishing works for attackers. So a single click in an exercise should not be seen as a risk to the company, quite the contrary. Guess who is least likely to engage with the next phish, perhaps a real one. This group.

Frequent or repeat clickers are more the risk you want to work on. Know who these folks are and make sure you have ruled out false positives. As a result of the work done by Nathan in his above mentioned blog, we reached out to our phishing vendor and learned that we could easily identify those false positives in our dashboard and remove those clicks from employees’ records. If you are a large company you may have to automate this or take a little time with some v-lookups. It is time well spent. No one wants to have a strike against them that they didn’t cause.

After you’ve removed false positives, the number of repeat clickers should be low. You need to connect with them to find out what’s going on. They need more direction, meaning a one on one discussion with someone on your team. I’ve haven’t run into anyone who repeatedly clicks but that doesn’t mean they don’t exist. So you should build a process into your program that defines a threshold after which to engage the employees manager, then department leader, then HR. If someone continuously clicks after being talked with and further educated, it may indicate they truly don’t care about the company and you likely have a bigger problem on your hands than a trigger finger.

There is no need to provide names to leadership of one-time or infrequent clickers. Leaders, please don’t ask for these. This can only result in a futile exercise in shaming and will be ineffective. In fact, tell your employees at the start of your program or at onboarding that if they slip up they will not be reported by name. Department heads may get result metrics for their area but with no names attached. Now if the employee slips up over and over again, that’s a different story.

Training
Train your employees on how to recognize a suspicious email BEFORE you start your phishing program. It’s not fair to test them without training them and it will feel like trickery.

Automatically assigning training to folks who click is also likely to tick them off. Besides, if they didn’t learn from your prior training, this isn’t likely effective. They need one on one attention. If you don’t have the staff to do this, consider slowing down your phishing program to give the analyst(s) who run it, the time to connect with folks. Just make sure their intent is to assist the person, not slap them on the wrist. See Intent section above.

Run a Risk Based Program
We already discussed choosing risk-based templates and how to help out true, risk-prone users. Next, adjust frequency to meet your goals. If your numbers are in the acceptable range for your company (VDBIR states that average these days is ~3%) then maybe it will be sufficient to send a phish quarterly. Free up those analysts for other work if your numbers are low. Continuing to phish for the same results is not a good use of anyone’s time. Alternatively, you can take a look to see if there are some groups not meeting that threshold. If that is the case, focus on those groups. Use templates specific to them, and which you are seeing in the wild.

Communicate, Communicate, Communicate
This is not just your check the box that you sent an email, put an article on the company intranet or messaging app. The goal is to influence. If that is not your forte, study up. There are books on sales tactics and on creating meaningful, memorable messages, like Made to Stick by Chip and Dan Heath. Search YouTube. Just know that if you want to be effective, you need to persuade. A good company-wide communication would be around how the company is improving. Discuss success rates, rather than click rates. It may seem subtle but it is all about rewarding good behavior.

Get time during onboarding. If the team who does your onboarding says they can’t possibly fit you in, negotiate even if you only get five minutes. If you can’t get that, help them truly understand the impact a few minutes of onboarding time will have on reducing risk to the company. During onboarding talk about the phishing program and your intentions around it. Be positive and sincere and let them know that the skills they will learn will benefit them and their families at home too. You can even sell it as a gamified way of learning. Don’t underestimate your energy, selling this “opportunity” is worth its weight in gold.

It’s always good to show that leadership supports the phishing program as well. If you don’t have their support, work to get it. If you have it, a message from the CEO or CISO or other C-Suite executive can help build good will around the program. Just make sure it conveys only positive intent and is not a finger shaking message.

So there you have it. You have a choice. Throw out your phishing program and accept the risks that open up to attackers or create a GREAT phishing program that is effective and well received by your employees. There really isn’t a middle ground here. But the latter is doable, more nuanced and will take some time but we’ve achieved it at Code42 and so can you.

The security team at Code42 is passionate about improving security everywhere. You’ll find more great security blogs by our thought leaders at redblue42.com. Or feel free to reach out to me on LinkedIn.

Does Security Have the Ability to Drive a Security Risk Aware Culture?

Risk Aware Cultures

The other day I was drinking my morning coffee reading my daily security news and noticed an email that came into the Security Inbox. Here is what it said:

Good Afternoon Security Team –

I have several large mp4 files I would like to move off my work machine so I wanted to give you all a heads up. There are 13 that I compressed into a 2.13 GB file which I am going to move to my personal Google Drive folder.

If there is anything else I need to do before moving these files, please let me know. I am happy to send a screen grab of the files I plan to move.

Thanks all.

This simple email is an indicator of a company that has a “Security Risk Aware Culture”. A Security Risk Aware Culture shows up when you get your users to think about security before they take actions. Let’s dive a little deeper. At every company the role of the security team is to figure out what is the risk tolerance they need to drive throughout the organization. This is something that is typically set by the board, the CEO, and the Executive team. It’s our job as security practitioners to truly understand the risk tolerance the company wants to take and then drive this throughout the organization through people via education, process via constant monitoring and following up, and technology via the software you deploy. The goal is to constantly balance the right risk vs rewards for the company.

Driving a security risk aware culture is the responsibility of the security team. There is no question there, but measuring how well you are doing is 100% tied to the actions your employees make. The security team alone cannot protect the company. Protecting the company and making the right risk decisions is something that has to happen throughout the company on a daily basis. Security is every employee’s responsibility. Pause for a moment and ask yourself these questions.

How often does your employee base reach out to security? Not the other way around.
How do people talk about the security team when you are not around?
Do your employees take actions to go around the security controls that are put in place? How often does this happen?

The answers to these questions are a good gauge as to how you are doing in building a Security Risk Aware Culture.

Let me take a minute and talk you through our path here at Code42. I started with the company 4 years ago. At the time we only had 4 people in security and I can tell you, we were a department that constantly told our users ‘no’ and we did not have a fantastic reputation of building trust with our end users. If I were to answer the questions above four years ago, I can tell you I would not be proud of the answers.

Let’s fast forward to today. Today I work with an incredible group of people across the organization that know that security is part of their responsibilities. They understand what it means to be part of the larger security team. They respect the controls that are in place and constantly reach out to the security team when they need help. They are aware of the risks and seek guidance on appropriate actions to take to continue to keep the company safe. So…how did we get from where we were 4 years ago to today?

There were a few key pillars that we followed throughout our journey.

We stopped saying no and started explaining the risks. This simple action allowed us to focus on the risks that exist by taking certain actions. When you start to explain the “what could go wrong” or “risks” involved in a decision, you start to bring the company along and educate them to make the right decision. In some cases only explaining the risks was not enough, we had to show them. In these cases we leveraged or RedTeam employees to exploit a certain vulnerability. This type of activity makes it real for people that don’t live and breathe security like we do every day. This helps to take the theory out of the “what could go wrong” and show people the exact way things could be exploited.
We stopped blocking productivity and starting monitoring and educating. We like to believe that people working for our company are good people, we were the ones to hire them after all. Most companies have good people just trying to get their jobs done. They don’t want to go around security controls or parameters, but let’s be honest…as security leaders we are all guilty of implementing a security control here or there that does not make sense, slows our users down, and frankly just makes everyone mad. We have decided to trust our users and operate in a ‘trust but verify’ way. We have figured out where we can stop blocking productivity and start monitoring for accidental misuse instead. When users make mistakes, because they will, they are human, we want to be there to follow up and educate them on the right way to do things. Things like spotting phishing emails, sharing data securely, and securing cloud resources become education efforts for our team. By the way, this is not solely the responsibility of our Awareness manager, it is a shared effort by everyone on my team to continuously educate the organization.
We stopped solely driving the security mission and started being allies. At the onset of my journey here, the one thing that was not lacking was passion for security. But I’ve learned that that can be an impetus for security folks to want to wave the security flag at every opportunity, even some that may not require it. That passion, without the risk-based guardrails, can create adversarial relationships with our employees. Once we identified that, we turned things around using the steps above. We will never lose our security passion, that’s what makes this field so exciting, we just need to balance it with risk-based decisions in everything we do and to help bring our partners along with us. Chrysa Freeman on my team wrote a whole piece about becoming Allies with the company in a blog post linked HERE. Taking this approach within your company, not only is a more effective way to get things done, it is a way that ensures you have the collective company behind you.

The role of a security team is not an easy one. It requires constant diligence and endless risk balancing. By taking certain steps to drive a risk aware culture throughout your organization, I can promise you that the role of the security team becomes easier and less burdensome. After all, it’s better to have the whole company watching for risks than just the people with ‘security’ in their title.