Captivating through Captioning

… 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.