Building an Inclusive Team
Written in collaboration with Roxie Zaricor (she/her) and CG Acharjya (they/them).
Representation in the security field has made great strides over the past few years but has a long way to go. According to the Aspen Institute, in 2021 only 24% of the security workforce were women. During my tenure as CISO at PayNearMe, I built a team made up of 50% women, far exceeding the average. I’d like to share some of the management techniques I’ve learned in how to attain a well-represented team and to make everyone feel welcome and included so you can retain that team. This all leads up to having a team who feels trusted and connected to the whole. An employee who feels disrespected and distrusted is not going to stick around.
Hire well
To have a well-represented team, you of course have to first hire one. It can feel like a chicken-and-egg problem trying to hire a well-represented team in a field that is very much not so, but it is not an insurmountable problem. The first hurdle to tackle is to have a diverse candidate pipeline representing individuals with all sorts of different backgrounds. Don’t look along the well-trodden diversity categories like gender and race. Look at the stereotypical categories for those outside the norm.
Career backgrounds: did they start out in a completely different field? is there someone from another field within your company or network who shows potential?
Where are they located: I guarantee that someone from New Jersey is going to have a different approach than someone from Northern California
Consider diverse education backgrounds: having all PhDs will be different than having a mix of educational backgrounds
Encourage your recruiting teams to look at many different sources for candidates like different special interest groups or groups focus on under-represented groups. I can also tell you that when you have a well-represented team who respects and trusts you, it will be easier to find a diverse candidate pool. They will reach out in their own network and actively support the recruitment effort.
Once you have that diverse candidate pool, you must keep the momentum going by planning a well-represented interview process. I always make sure that the interviewers are a diverse bunch because they will ask questions from different perspectives. They will also be able to gauge how well the candidate reacts to people from different backgrounds. I’ve seen candidates be vetoed because in a male/female interview panel, they disrespected the woman on the panel. It won’t help your efforts to build an inclusive team if you hire someone who is disrespectful or doesn’t see the value in inclusivity.
Bring your whole self
I always encourage my team to be authentic and part of that is allowing them to have moments of vulnerability. Security is a stressful field and can sometimes lead to heightened emotions. I’ve had one-on-one meetings where the other person apologized for showing their emotions. I made sure that they know it is ok to have emotions. We are all human and our emotions are as much a part of our humanity as the work we perform at our computer. By creating an environment where emotional intelligence can thrive and grow, we give those opportunities to everyone for success. Doing this will help your team feel safe and that feeling will build trust and alleviate the fear and anxiety that can hamper their work. You also need to make sure that you follow-up with your team. If they tell you that they are going through a personal crisis, check in with them in a day or two. I guarantee that it communicates that you see them as a human and not as a machine.
Burnout is widespread across a lot of fields but very much so in security. It can feel like you are jumping from fire to fire in security and like you can’t even trust the ground you walk on. This anxiety adds up over time. When you have regular one-on-one meetings with your team, ask them periodically how they are doing? It’s easy to get lost in the mundane task and project management and forget the person behind that work. In all my one-on-one notes, I have a section for venting. Anything goes in that section, without judgement. You don’t have to have an unending meeting all about venting but provide space to vent so they can better focus on the work at hand. Sometimes that’s all they need. A quick “I gotta vent”, which gives them a chance to “feel the feels” and then move on.
Be an ally
Even if you yourself aren’t an under-represented individual in security, there is so much that you can do to help. One of the most impactful things I’ve done is leading an employee resource group (ERG). ERGs don’t just have to be for under-represented groups, they can be for any group wanting to connect with similar individuals across the company. I’ve seen ERGs for parents, for people who cycle to work, people who are care providers for loved ones, etc. All of them are important elements in helping your team feel connected to the company as a whole. I can tell you from experience, it can be very demoralizing to be the odd one in the larger company. Having these groups let’s everyone know that they have someone else they can talk to.
I would also encourage you to mentor people on your team, even beyond under-represented folks. You as a security leader have experience that others want to know about. This ties back into the whole of how to build trust and connection with your team. Ask them what their vision for their growth path is and see how you can help them achieve that. You also must be honest with them about the potential for that growth path. One of the most impactful moments in my career was when my boss told me that there wasn’t a sufficient growth potential for me at my company. With his encouragement, I went to another company to continue growing my career. It left an indelible mark in me on how I manage people.
Be an advocate also for clear paths to promotion. Biases can creep into the promotion process if guidelines are not set forth and can leave under-represented folks feeling disfavored when they do not get a promotion they were hoping for. These don’t have to be quantitative metrics but at least be transparent with them along the way so that nothing is a surprise.
In Summary, building an inclusive team is hard. But it makes all the difference, and in the end, is worth every bit of the work. You have the ability and tools to work with an amazing group of people, who will think the same about you. It’s worth the time and effort! Trust me, or better yet, ask my team!
Okta Sample Prompt
For the second time in a year, Okta has had a breach related to their customer support system. This is a great opportunity for other companies to learn about both vendor and process security. In my mind the best means to convey this to key stakeholders is through an incident response training. Here is a sample scenario you can adapt for your company.
Setup
First, talk to your customer support team to get details on their processes when working with your customers:
How do they verify the identity of who they are talking to?
What channels do they talk to the customers over? Just phone or is it also email?
What information do support agents have access to? Are there different sets of data accessible by different roles?
What is the escalation process for someone to move beyond frontline support?
Are customer interactions ever monitored or reviewed?
Are frontline agents trained to report suspicious behavior?
Based off those questions you can begin to find potential holes in their processes. Ask yourself and your team some questions like these:
If a scammer doesn’t know some identifying piece of information, could they fall back to something else? For example, not having access to an email account, would customer support fall back to the phone number?
Could a rogue frontline agent access data undetected?
Is there any info given out that could be accumulated into a more believable fake identity?
Are verification processes reliant on information that could be gathered via OSINT?
By answering those questions you can build up a more plausible prompt. I suggest layering the security holes together to create a more nuanced and complex scenario. You will also be able to figure who outside the core IRT needs to be present. I always include a few people from around the company in relevant departments. In this scenario, you could include a customer support agent or two. They are your subject matter experts who can help fill in the gaps in the narrative.
Scenario
Use this initial prompt to get the scenario going. Give it to the person who would normally receive customer complaints (I’m going to name them Sam the Agent) and make sure that they know not to broadcast it to the training participants. They should let individuals know as they would in the real world.
You’ve received a few complaints from high profile customers that their account info has changed. In particular they all see that the email addresses associated with the accounts have been changed to something they do not recognize.
Sam the Agent should be familiar with the escalation procedures for their department. If not, take this opportunity to remind them, after all that is what this training is for.
From here, your customer support team and technical staff should work together to determine the details about the account information changes. They will ask you for what they find, give them this:
You see that all of the changes were initiated by frontline customer support agents. The changes were made by multiple agents. It appears that there are records of several calls for each affected account for similar issues. There is a strong similarity for the sequence of issues for each account.
Depending on how incidents are handled at your company, it is likely that at least the core IRT would be notified. If the people in the know decide to notify the team, you can broadcast everything to the wider training audience.
At this point in the training, I will usually throw in a red herring. These serve to remind the IRT that there will be a lot of noise to sift through when responding to a real incident. For a more non-technical scenario like this one, I suggest using technical evidence. In the past, I’ve gathered screenshots from AWS GuardDuty of alerts that look scary but are really not.
Where your team takes it from here is heavily dependent on your particular company. In all of your answers to your training audience, tailor them towards continuing the discussion and investigation. The goal here is not to solve the puzzle, it is to fully explore the bounds of your incident response.
Post-Mortem
Just as with a real incident, reserve some time to discuss what was uncovered in this incident. At this time, everyone who was in observer-only mode can participate. Encourage that group to share their thoughts on how they might have responded differently.
Here are some discussion questions to help move the discourse forward:
Are there tools we could have in place to detect this before a customer notices?
Are there authenticated methods for verifying a customer’s identity at the start of the agent interactions? Do we have a mobile app that could use push notification verification?
Was everyone aware of the escalation processes and designated alternates?
Since requests across multiple customer accounts showed strong similarities, is there any knowledge sharing among customer support agents that could have spotted this sooner?
If your customer support team is outsourced, should that support vendor update their own internal policies as well? Would it be worth looking at alternative vendors?
Could this have been done by a recently terminated employee if their access was not revoked in a timely manner?
Finally, you should reassure your audience. They might be a bit shaken and worried about the state of the company. Ask them to concentrate their anxiety towards productive uses. They should take a look at their own departments to see if there are corollaries from this scenario into their work.
Tabletop Incident Training
Incident response training does not have to be a boring waste of time. Tabletop exercises at PayNearMe became an annual event that the incident response team came to look forward too. There are three key aspects to make it successful:
Give the audience a mystery to solve.
Keep the prompt relevant to the company and current events.
Involve as much of the audience as possible.
Whodunnit?
By giving your audience something to solve, you make them invested in the training from start to finish. I’ve had great fun with insider threat training by getting coworkers to play the villain. Take for example this prompt given to two employees ahead of the training:
Infrastructure Engineer - You are working with your coworker Sally to exfiltrate critical data to sell it on the black market. She will write up a script for you to run on the production systems. You covertly open up a port on the servers for an external server to fetch the data.
Software Engineer - You are working with your coworker Bob to exfiltrate critical data. You write up a script to dump the data into a file. Bob will open up a port for your external server to fetch the data.
This will give those two team members something fun to do during the training while also throwing in a wildcard for the rest of the team. Bob and Sally will have a chance to throw people off the scent and I guarantee it will be a training they never forget.
For the rest of the team the initial prompt could be as simple as “the security scanners noticed a new open port on the servers that was not approved.” That simple sentence can lead people down a deep rabbit hole. It will be up to you as the facilitator to fill in the knowledge gaps. Think of this as if you are the Dungeon Master in a game of D&D. You know everything and the players are there to ask questions and follow wherever the evidence leads them.
Keep It Relevant
If you use generic topics for your exercises, you will be doing a disservice to your team and will end up with a disengaged audience. If you are working in the online services space, why would you want to do an industrial control systems related prompt? There are plenty of generic topics that can be still relevant to any company such as insider threats or ransomware. The key to those generic scenarios is to keep them relevant. For example, if you are in a financial company, make that insider threat someone trying to illicitly move money. If you’re in a legal firm, make that ransomware prompt about them blocking access to client documents relevant to a current case.
Relevant can also mean timely. This is a great way to bring home the impact of the headlines that everyone reads about some other company getting breached. Its easy for non-security minded people to think “that could never happen to me.” You need to take every opportunity to open their eyes to the fact that it could be them. Take for example the multiple Okta breaches related to their customer support ticket system. Nearly every company has some form of customer support. Think about how that could be exploited by someone. Could they gain access to data or systems? The scenario doesn’t have to be 100% plausible, it just has to open their minds to the possibilities.
Audience Participation
Both who is and is not playing an active role in the exercise can be important. I always make sure that at least some primary IRT members are in observer-only mode each year. This forces the alternates to step up and take charge. Watch for who has the loudest presence in each training. Make sure that they rotate through observer-only mode some years so that others have a greater chance of participating.
The other half of audience participation is in crafting a prompt that involves everyone. As someone coming from a technical background, it is really easy for me to craft a prompt that heavily involves engineering but you’ll quickly find the non-technical folks checking out. An example could be the malware hitting production servers. That could quickly spiral into a technical firefight, but ask leading questions of other participants. “Hey legal, if this malware has access to customer PII, are there external parties who need to be notified?” “Hey customer support team, if this results in a disruption of service, do you have a plan ready to notify customers of the disruption?”