Ask someone how they entered the security field and they will tell you their stories. They may talk about the skills they have and the things they know, but it’s their stories that reflect how they think and how they have been shaped by their experiences.
“It’s so helpful when they come to me and say, ‘I love hunting bad guys. That’s what I love to do do.’ That brings so many more things to the table, as far as understanding their perspective, their background, and what they’re trying to do versus talking about very dry, typical skills,” said Cory Scott, CISO of LinkedIn.
Listen to how people describe the work they do and how they do it, not the job titles or specific positions, said Scott. People may have the same kind of experiences but still relate to security differently. The person’s “narrative identity” reflects their skills, ability to execute, and approach to solving problems.
“You take someone who has experience of [being] a first responder. That is a particular mindset of how they're approaching problems: triage and containment. Compare that to someone who has a mindset of building something that will try to address security as an engineering problem,” Scott said.
Most people tend to fall in one of four broad narrative categories: defender, trickster, wizard, and actuary.
The defender is someone who’s really motivated to stop bad things from happening to the people and organization they are tasked with protecting. They add defense-in-depth. They fortify. They feel responsible for the environment and focus on their users, whether that refers to users, employees, or customers.
“They double check that the door is locked before they leave for the day, and they really like to hunt for ‘badness’ in their environment,” Scott said.
The trickster is the one who looks for flaws in software, the one interested in how things work and how they are being used. They are the ones saying, “I found this awesome way that no one had thought about to trick this piece of software into giving up some data that it shouldn’t have given.”
The trickster doesn’t think twice about buying random things off the Internet just to take them apart and hopefully put them back together. They find a barrier, such as a policy restriction or a software limitation, and their instinct is to find a way around it. They are the “walking embodiment” of all the things that could potentially go wrong with the product or environment, Scott said.
“There is an engineer on my team who, every time I walk by, I can gauge how close he is to actually giving us another vulnerability that we have to fix by how big his smile is when I walk by,” Scott said.
The defender is someone who’s really motivated to stop bad things from happening. The trickster is someone who thinks, “I found this awesome way that no one had thought about to trick this piece of software into giving up some data that it shouldn’t have given.”
The wizards are the people who treat security as an engineering problem. Instead of talking about risk or how to break stuff, they’re the ones thinking about ways to solve the problem. They approach security challenges by thinking, “If I write this code in the right way, if I design it in the appropriate manner, then I can wipe out entire classes of vulnerabilities.”
Many of the wizards tend to be strong on technical execution and look for solutions by focusing on performance, scalability, and reliability.
“Are you talking about how you came up with this awesome algorithm that reduced the number of false positives of your intrusion detection system? You might have a wizard kind of narrative,” Scott said.
The assessor is someone who recognizes that security is a business function and thinks like an actuary. This is the person who recognizes that resources are finite and everything can’t be protected all the time.
Assessors are the ones asking, “What’s most likely going to happen that would be devastating and business-ending, versus what may just be an annoyance?”
They think about user experience and whether employees understand the security goals well enough to understand the rationale behind security policies.
“You need some with that mindset of ‘Are we actually spending the right amount of resources on using this product.’ Someone has to consider whether we are getting value,” Scott said.
The wizard thinks, “If I write this code in the right way, if I design if in the appropriate manner, then I can wipe out entire classes of vulnerabilities.” The assessor asks, “What’s most likely going to happen that would be devastating and business-ending, versus what may just be an annoyance?”
Narratives are fluid, as new experiences change how people perceive security and learning new skills open up new areas of interest. Scott points to his own background, noting that he started out as a “pure defender” at the beginning of his career and became a trickster as he got more involved with the offensive side of security. After years in vulnerability research and penetration testing, he returned to the defender narrative when he joined LinkedIn, where one of his focuses is on member privacy. Scott has also seen people move back and forth between the wizard and defender narratives.
“I was responsible for maintaining a set of systems at a university very early in my career and someone broke in,” Scott said. “The person who broke in offered to show me how it happened. We started chatting and he showed me his techniques on how he broke into the system, how everything went wrong, and how I was completely messing this all up. I thought, ‘Hmm. That’s kinda fun. Maybe I want to learn how to do that.’”
Cory Scott on how he uses personal narratives to match people to the right teams.
While the makeup of teams may vary from organization to organization, the most successful teams tend to be those that have a “potpourri of folks,” Scott said.
“I love to break things and if I hired a bunch of people who all they did was break things all day long, then the engineering team here [LinkedIn] would probably kill me quite quickly because then we’re not actually figuring out how to fix stuff,” Scott said.
People with the same narratives tend to work well together because they approach problems similarly, but that means they are more likely to agree with each other on proposed solutions.
Trickster: I found this really cool vulnerability.
Other tricksters: Yes, that’s a cool vulnerability.
Some disagreement or friction would be more helpful and result in a more constructive discussion. If there is a vulnerability in the application, someone offering to replace the offending lines of code with an existing library makes the application more secure. Someone creating a rule to detect if anyone attempts to exploit the flaw before it is fixed helps defenders protect the organization and the users in the meantime.
Trickster: I found this really cool vulnerability.
Wizard: I could write some code that actually eliminates all instances of that vulnerability across the board, rather than you just going and looking for this one vulnerability in all of our different products.
Defender: I wonder how you would detect that actually being exploited.
Assessor: Is that vulnerability actually likely to be exploited in the wild? Is that something that we actually need to deal with first and foremost?
“If you have that type of active discussion, you know you’re got the right mix,” Scott said.
Teams can also outline a vision of how they plan to execute their goals. The organizational narrative describes how the team works with other groups within the organization, how they are perceived by other groups, and how the team resolves problems. While the specifics of the narrative will depend on the organization’s culture, industry, and other factors, Scott focused on four broad categories: operations, engineering, consulting, and governance.
A team with an operations narrative would emphasize being able to respond and to handle anything that comes their way. They have really good incident response plans and practice executing the playbook. When an incident gets reported, it’s appropriately tracked, addressed, and resolved. This is the team that takes on the responsibility of keeping things running smoothly and are on top of everything.
The team with a consultant narrative would prioritize working with other teams to understand what the business unit is trying to accomplish. This is the team focused on security- and privacy-by-design. This is a team that sees itself doing the kind of work that would be expected from a boutique security consultancy.
Then there are the security teams that consider themselves first and foremost engineers. They write and deploy code. A team with an engineering narrative trains its members the same way the rest of the engineers are trained, and uses the same tools and processes to get their work done. They are respected within the organization because other groups know this team understands the challenges of building and maintaining that they face. The engineering narrative puts all the engineers on the same side.
“Their code is at the exact same quality [as the rest of the site] so that they can generate the necessary respect…that they’re taken seriously,” Scott said.
And finally, the team with the governance narrative is the one thinking about how specific actions could impact the organization. They’re making lots of hard choices, and weighing their choices to figure out if they are doing the right thing for the company and for their members.
A personal narrative doesn’t lock anyone into a specific team narrative as they can be combined in various ways. A defender can thrive on a team with the consulting narrative and there is room for a wizard on a governance team. While it seems logical that a operations narrative would need defenders focused on incident response, executing the playbook, and keeping the organization up and running, having a mix creates a strong operations narrative. Adding tricksters to operations means someone will be curious enough to expand the scope of the incident beyond the known component and poke around to see if a variation of the attack would succeed in other areas. Adding wizards will introduce scalable tools and management scripts to make things work faster, automate some steps, or respond more effectively. The assessor also has a role to play, as that person tends to take a broader view of why things are being done a certain way.
Consider the situation when a technology initially deployed by the LinkedIn incident response team to detect “a certain amount of badness” stopped being effective. The defenders stuck with the tool and tried their best to get their job done with what they had, and the wizards spent time trying to fix the issues and make it work again. But until an assessor took a step back and asked why the team was still using the product if it wasn't providing useful information, no one had considered it was time to stop using it.
“We just kept burning cycles on a product that wasn’t returning any particular value,” Scott said. “We wasted six figures of cash on this particular product because it wasn’t, and no one had stepped back to ask. That's a lot of wasted resources.”
There are also team narratives, which reflect the team’s vision for how they approach problems and how they want to be perceived by other groups.
Instead of relying on technical interviews and coding exercises, which help “figure out whether or not the person thinks like us,” narratives can help identify people with the right mindset to succeed in security. The stories highlight what areas the security professional is interested in. Security leaders and managers have to ask the questions to tease out the person’s narrative so that they can identify the team that needs that type of mindset.
You want to look for people with different types of backgrounds and different types of approaches to how they work, how they think, where their life experiences have brought them to that point.
An effective manager works with individual members to prepare for “the next play,” to develop a set of skills or capabilities that would be used in their next role, Scott said. If someone is interested and saying, "I'm a coder today, but I want to be a pen tester tomorrow," good managers should figure out how to help them get to that point.
These discussions can also help recruit talented people from areas outside of security. Someone who was a first responder, or volunteers to help people in crisis situations, is likely to have a defender narrative where they are trying to stop people from being hurt. The mindset is the same whether they are trying to stop the bleeding or shore up a particular weakness. Being curious is considered a sign of a good security practitioner and is a trickster trait. Being interested in how things work is not something that can be listed on a resume but will usually come out in the personal narrative. A technical or project management background can bridge the gap in security expertise.
“We’ve hired people from sales, program management, engineering, and operations, because they had that particular background that was valuable to the security team and something clicked,” Scott said.
When managers focus on finding people with different personal narratives and align them with different organizational narratives, they inevitably wind up with a far more diverse team than they would have otherwise. People with different viewpoints make them better at handling different situations and identifying new use cases that a more homogenous team may have missed.
“You want to look for people with different types of backgrounds and different types of approaches to how they work, how they think, where their life experiences have brought them to that point,” Scott said.
Anyone can create a security narrative of their own. “When you talk about work and the interesting things that you do, what is that story?” Scott asked.