Category Archives: Network Security

Gaining Technical Experience with Deliberate Practice

When I moved to Georgia I started riding my mountain bike several times a week. Almost every other day I’d pop out of the office before lunch and ride three one-mile circuits on a trail near my house.  Six months after starting, I realized I’d never looked at the data collected by the trip logger on my bike. I thought it’d be really interesting to see how my speed had improved as I biked more.

I was pretty disappointed when I saw the data.

My performance hadn’t increased a bit.

After months of biking the same three miles, I had no noticeable gains in my cycling ability. I wasn’t finishing the ride any faster, and I wasn’t any less tired. What gives?


Me failing at life (dramatization).


I got angry and decided to spend some time focusing on performance. Hell hath no fury like a geek with the ability to collect data and manipulate independent variables. I looked up YouTube videos about cycling posture and breathing techniques. I also started reviewing my trip log after every ride and setting goals. I wanted the average of my ride times to improve by at least a few seconds every week.

After sticking with this regimen for just another month, the results were in. I had improved my performance by nearly 30%.

Why was I able to accomplish so much in a month after not making any progress in six months?

The answer is that I stopped riding mindlessly and began deliberately practicing.


Practice vs. Performance

We mostly think of practice vs. performance in terms of athletes, so let’s stick with that example. In a given basketball game lasting an hour, an active player might get up a dozen two-pointers, a few three-pointers, and a couple of layups. They might make about forty passes and jump for twenty rebounds. They might also run three offensive and defensive schemes twenty times each.

Now let’s compare those stats with a week of hour-long daily practice sessions as I’ve done in the table below.


1 Game 1 Week of Practice
Two pt shots 12 500
Three pt shots 3 500
Layups 2 200
Passes 40 1000
Rebound attempts 20 200
Offensive schemes 3 x 20 5 x 100
Defensive schemes 3 x 20 5 x 100


Clearly, what happens in a game performance is a much smaller subset of what is practiced. The purpose of practice is to develop individual skills in preparation for a performance. Practice is a planned, mindful exercise. An entire practice might be devoted to a single skill like shooting, or mastering a skill within a specific scenario, like rebounding in a man-to-man defense.

A performance combines every facet of your practice. Performance is full of surprise and unpredictable. While practice is actively thoughtful, performance generally involves acting out of muscle memory and getting into a zone that many psychologists called “flow”. Experts experience a much stronger state of flow because they’ve developed more muscle memory (both mentally, and physically).


The Secret of Practice

In the example I just described, you might notice that the amount of time allotted to practice is much greater than performance. Be careful though — the development of skill isn’t purely a function of time. That’s why my six months of riding trails showed no improvement in my cycling skill. It’s also why you drive a car every day but are probably ill-equipped to steer a race car around Daytona at 200mph.

The secret of building expertise through practice isn’t that experts log more hours of practice. Experts log higher quality practice.

Whether you’re an athlete or an analyst, the characteristics of high-quality practice are the same.

Requirement 1: A clearly defined long-term goal

The goal of practice is to perform well. What does peak performance look like? In sports, this usually means putting up good stats or winning a game. In intellectual pursuits, it might mean arriving at an accurate answer or completing a task quickly. High-quality practice works toward long-term goals.

Requirement 2: An understanding of the component parts of that goal

Performance is made up of multiple skills used in a variety of scenarios. High-quality practice requires that you understand your long-term goal well enough to break it down into these component parts so you can focus on them individually.

Requirement 3: 100% concentration and effort

Performance is all about muscle memory and flow, but those things are established in practice. You practice a skill several times so that when you really need to use it, you can do so quickly. Performance isn’t just about completing a task, it’s about doing it efficiently and effortlessly. To do this, you must be mindful of the task you’re performing and apply all your attention to it. This way, simpler tasks can become automatic and you can devote previous limited working memory resources to understanding other unknowns.

Requirement 4: Immediate and informative feedback

You practice so that you can get the mistakes out of your system. Of course, this requires that you’re able to spot the mistakes in the first place. You have to collect data and establish a feedback loop. Informative feedback is one reason coaching is so important. A coach’s primary role is to help spot the mistakes you’re making and equip you with the tools to overcome them.

Requirement 5: Repetition, reflection, and refinement

When you combine all the elements I’ve mentioned thus far, you get the blueprint for practice. High-quality practice means repeating skills, reflecting on how well you completed the skill, and refining your approach to the skill.  These things must all be deliberate. You have to practice with the goal of getting better. Just going through the motions won’t get you anywhere.


Out of Practice

Infosec practitioners stink at deliberate practice.

It’s something that most of us don’t spend any time thinking about. I ask every analyst I meet how they practice their craft. The answer I always get without fail is this:


Attacking a VM and/or reviewing the logs generated from the attacks can be an effective practice strategy, but most never follow through with it and even more don’t approach it the right way. If there were a graveyard for VMs built for this purpose but only used once, it’d be overflowing. I don’t want those VM’s to have died in vain, so I’m going to tell you how you can practice smarter.


Developing a Practice Plan

If you want to become an expert at anything and accelerate the accumulation of experience you need to deliberately practice it. You have to be strategic about how you focus your practice. I recommend creating a practice plan, which is built from a list of skills used during performance of a job and scenarios where you might encounter them.

In our basketball example, skills include shooting, passing, and rebounding. Scenarios include different schemes like man-to-man defense, dribble-drive offense, and inbounding plays. Multiple skills will be encountered differently based on the scenario where they are needed.

The same thing applies to information security. Consider the work of a malware analyst. Three skills you’ll use during reverse engineering include:

  1. Simulating responsive services
  2. Identifying imported code libraries
  3. Understanding network communication sequences

Those skills manifest differently depending on the situations you’ll encounter. Those situations can be defined a number of ways:

  1. Platform: Windows, Mac, or Linux
  2. Malware Function: Droppers, worms, exploits, RATs
  3. Malware Techniques: Registry persistence, VM detection, heap spraying, opening network listeners, keylogging

Now you have what you need to make a practice plan. You simply combine skills with the scenarios you’ll encounter them in. So, you might wind up practicing the following things:

  1. Simulating a DNS server to resolve a domain requested by an iOS dropper
  2. Identifying the code libraries imported by Windows malware to understand its purpose
  3. Understanding the network communication of a RAT to build IDS signatures

If you practice these things, you’ll be able to do them effortlessly when you’re under the gun to analyze a real malware sample you’ve found on your network.

This example is focused on malware analysis, but it can easily be applied to red teaming, alert review, threat hunting, web application development, socket programming, or just about any technical skill you can think of. You just need to clearly identify the skills and situations associated with the job.



Now that you know about deliberate practice, I’m challenging you to take action. I want you to examine a facet of your job you want to get better at and break it down like I just did. Figure out the skills you need to be good at the job, and the scenarios where you’ll use those skills. Make a list of both and reply to the comments on this post with your practice plan.


The Cult of Passion

Would you perform your job if you weren’t paid? That’s the question people are often asked to measure their passion for a profession. But, it’s not that simple.

Go one step further and really consider that statement. It’s not asking you if you would work for nothing, it’s asking you if you would pay to work in your job. By choosing to work without compensation you are incurring a direct cost for equipment, commuting expenses, education, and more. You’re also incurring an indirect expense because the time spent working prevents you from earning a salary elsewhere.

So, would you pay to work in information security? You probably wouldn’t. Does that mean you aren’t passionate about infosec? I would wager that most practitioners are not. You would pay to garden, play soccer, barbecue, or play the guitar…but you wouldn’t take a financial loss to install patches, look at packets, and change firewall rules.

But, if that’s the case then why does our industry seem to revolve around passion? Nearly every blog post you read about hiring or job-seeking discusses the importance of passion and they often provide advice for how to demonstrate it. Some advice goes so far as to highlight passion as the most important characteristic you can exhibit. Infosec is described less of a job and more as a lifestyle. This sounds a lot less like job advice and more like recruitment for a cult.

In this post, I’m going to talk about passion, myths commonly associated with it, and how the cult of passion harms the practice of information security.

Passion as a Currency

Passion is commonly equated with extreme motivation surrounding a specific topic. In its simplest form passion manifests through hard work and time spent. These are both traits that are viewed admirably, especially in the US. Working from sunrise to sunset harkens back to memories of farmers earning an honest living while providing food for the masses, or to middle-class factory workers going the extra mile to provide for their families. These images are pervasive and are the backbone of society.

Of course, hard work isn’t truly a measure of passion. The farmer isn’t always passionate about farming. He’s passionate about providing a living for his family. The factory worker doesn’t love stamping car frames for 12 hours a day, but it enables the things he or she is truly passionate about.

In truth, passion isn’t reliably measurable either, because it can only be measured relative to others. In infosec hiring, an interviewer may only see someone else as passionate if they appear to exhibit passion in the same way as them and to a greater degree. Jim speaks at 12 security conferences a year, contributes to 5 open source projects, and works 16 hours a day. These are things he finds value in and how he would quantify his own passion. He is interviewing Terry, who only speaks at one or two conferences a year, contributes to one open source project, and works about 10 hours a day. Jim is likely to see Jerry as someone who isn’t very passionate. However, this is a purely relative viewpoint. It might not also consider things that Jerry does that Jim doesn’t value as a form of passion such as mentoring less experienced practitioners or doing tech-related community service.

When you attempt to evaluate people via traits that are difficult to objectively measure (like passion), you present an opportunity for undesirable results. This is something often seen with faith in religion. A false prophet commits to lead followers to the promised land if only they demonstrate appropriate faith. That faith might be prayer, tithing 10% of your income, tithing 100% of your income, or violently killing people of opposing faith. I highlight the wide range here because it shows the extremes that can arise when your currency isn’t objectively measurable.

In information security, we use passion as an unquantifiable currency to measure the potential success of someone in our field. A common piece of advice given to someone who wants to work in information security is that it isn’t simply enough for infosec to be your job. If you want to be successful in infosec, it must be the thing that gets you up in the morning. There must be more to this.

Do You Really Mean Passion?

Psychologically, passion is either harmonious or obsessive. Vallerand describes this better than I can:

Harmonious passion originates from an autonomous internalization of the activity into one’s identity while obsessive passion emanates from a controlled internalization and comes to control the person. Through the experience of positive emotions during activity engagement that takes place on a regular and repeated basis, it is posited that harmonious passion contributes to sustained psychological well-being while preventing the experience of negative affect, psychological conflict, and ill-being. Obsessive passion is not expected to produce such positive effects and may even facilitate negative affect, conflict with other life activities, and psychological ill-being.

What do people mean when they talk about passion in infosec? Rarely is it ever defined through any other mechanism but example. If you ask most to describe someone who is passionate about information security they’ll say that these people spend copious amounts of time outside of work on infosec projects, contribute to open source, go to a lot of security conferences, are actively involved in the security community, or have a blog.

Assuming you’ve found someone who does all of those things, can you guarantee that means they are passionate about infosec? How would you be able to differentiate them from someone who is passionate about being successful, or making money, or being recognized for being an expert? Finally, how do you differentiate harmonious and obsessive passion? That is a very challenging proposition.

Passion is very difficult to attribute to a source. In fact, most people aren’t good at identifying the things they are passionate about themselves. The vast majority of security practitioners are not passionate about information security itself. Instead, they’re passionate about problem-solving, being an agent of justice, being intelligent, being seen as intelligent, actually being intelligence, solving mysteries, making a lot of money, or simply providing for their families.

In most cases, I don’t think the trait people are looking for is actually passion. Instead, they’re looking for curiosity. Curiosity has a motivational component and is often described simply as “the desire to know.” It is rooted in our ability to recognize a gap between our knowledge on a topic and the amount of available knowledge out there. When we recognize that gap, we make a subconscious gamble about the risk/reward of pursuing the knowledge and eventually decide to try and close the gap or not. This is called information gap theory, and through this theory we can gain a better understanding of trait and applied curiosity that can improve our ability to teach and hire people.

Diverging from Cult Mentality

Passion has its place. I know some people who truly are passionate about the practice of security, and they are among the top practitioners in our field.  However, it is unwise to constantly compare yourselves to these people. I offer the following:

For information security practitioners…

Hard work matters, but you can work hard and not allow this industry to pull you into the cult of passion. Choose where and how you spend your time so that your work enriches your personal life, and enjoy a personal life that enriches your work. If you fall victim to the thought that information security must be your life, you will eventually burn out. You will suffer, and if there is anybody left around you, they will suffer too.

Here are professions of people who work 8-10 hours a day and go home and don’t think about work: doctors, lawyers, engineers, scientists, researchers. Do the top 5% of practitioners in these fields think about work all the time? Probably. But you also probably aren’t one of those people. Not everyone is extraordinary and that’s okay. There is this myth that we all must be the best. As Ricky Bobby famously said, “If you ain’t first, your last!”. But, by constantly trying to be the best it breeds things like imposter syndrome, self-doubt, and depression. In an industry where so many have substance abuse problems and we’ve lost far too many friends, these are feelings we should actively avoid promoting.

For hiring managers…

It isn’t just limiting to only hire people who make infosec their life, it’s exclusionary. You’re missing out on people with diversity of interests that will enrich your security program. You’re also preventing people who have more important personal life issues from finding gainful employment.

To pursue the knowledge that exists in the curiosity information gap I discussed earlier, a person should be aware the gap exists. Otherwise, they don’t know what they don’t know. This implies that a job candidate needs to know a little about a topic to be strongly motivated to pursue knowledge in it and sustain that pursuit. The last part is important. Sure, the journey of a thousand miles begins with a single step, but that first step is also usually the easiest. It’s quite a few miles in where we normally lose people. This is one reason why the notion of trying to hire TRULY entry level people based on passion in infosec is a fool’s errand. Someone with no experience in this field does not have a proper footing to be passionate about it. If they are passionate about infosec, then that passion can’t be trusted to be sustained. You’re hiring based on a mirage.

A key to maintaining interest is a constant stream of novel information. For a novice, most things within a field can be novel because the key is to building passion is exploration. To transition to expertise, an individual must find novelty in the nuance of specific topics. Someone who enjoys nuance is best set up to be an expert. Most people will never truly be world-class experts in something, but again, that’s perfectly fine.

For job seekers…

Much to my dismay, most people will never read this article, truly understand passion, and cultivate an ability to notice genuine curiosity. That means you have to play the game that is hiring. People will keep asking about passion, but reframe the question under your own terms. Tell them you see passion as a term used to describe curiosity and motivation. Try to identify what really motivates you and how your curiosity pushes to toward goals. Relate to people at a personal, human level. A lot of candidates talk about how they eat/breathe/sleep infosec. You don’t have to do that. Instead, talk about how you critically think about important problems and optimize your time so that you don’t have to be work 16 hour days to be successful. Hard work is important, but working smart is much more important, and is actually sustainable.


Along my pursuit to understand passion I’ve learned that it’s a highly contentious topic. People hate to have their passion questioned, and I’m sure this article will stoke that fire. I wonder why that is? I would wager that many quantify their own ability and maybe even their own self-worth in their subjective self-evaluation of their own passion. Once again, passion is a good thing and measuring yourself based on some degree of it is probably fine. It’s when we choose to measure others based on our subjective views of their passion that we get into trouble and create cult-like scenarios. We can do better.

My goal with this article was to share my understanding of passion, how it’s often misinterpreted, and how that can negatively affect our industry. Once of the most liberating moments of my life was when I figured out that I wasn’t passionate about information security, it was just infosec that allowed me to achieve other things I was passionate about. If others can relate then I hope they can feel the same liberation someday through a better understand of passion. If you are truly passionate about infosec itself, then that’s great too, we need you!


Further reading:


5 Human-Centered Takeaways from the SANS SOC Survey

SANS recently released the results of their SOC survey that was put together by Chris Crowley. The report has a lot of useful data points and is worth your time to go through whether you’re in a SOC and wondering how you stack up against others, or if you’re thinking about establishing a SOC and need to see where the goal posts currently are.

In this post, I want to focus on five takeaways I garnered from the report*. These takeaways will revolve around the human analyst, just as all investigations do.

Heavily Regulated Industries (and vendors) are Leading the Way

Figure 1 illustrates the distribution of SOCs across specific industries. Taking dedicated cyber security and technology companies aside, the industries that appear to have a greater number of SOCs share a commonality of being heavily regulated. This includes government, finance, manufacturing, and healthcare. This seems consistent with the notion that many organizations develop their security operations by first embracing required compliance.

SOC Survey Industries Represented

By virtue of being the first and most prolific adopters of SOCs, these industries will naturally dictate best practices across the field as they mature. The common traits and mindsets predominant in these industries will influence the direction of the SOC as we know it. This will matriculate to cyber security vendors who will inevitably swap staff with practitioners in these SOCs. When combined with vendor’s focusing sales goals towards these industries ensure that vendors are also more likely to build products and produce educational materials that also promote the mindsets predominant in these fields.

A mindset is neither good or bad, and bias can be both helpful and harmful. It’s important we identify common trait distributions and mindset biases associated with these fields so that the evolution of the SOC concept benefits from a diversity of opinion.


SIEM as the Investigative Centerpiece

Figure 13 shows how SOC analysts correlate and analyze event data, IOCs, and other security and threat-related data. This chart essentially identifies the tool at the center of the investigative process. 77% cited the use of a SIEM for facilitating the investigation process.

In my experience, many SOCs tend to let the workflow inherent to their SIEM dictate their analyst investigation workflow. New analysts learn primarily via on the job training and through the lens of the workflow dictated by the SIEM. Given there are only a handful of widely popular and accepted SIEMs and investigative theory training isn’t widespread, most analysts currently practicing likely learned their craft via a few popular SIEMs like Arcsight, QRadar, or others. I would posit that a test could be developed wherein you could present an analyst with investigation scenarios and monitor how they solve them to arrive at an accurate assessment of which SIEM they cut their teeth on.

If the SOC doesn’t provide training in fundamental investigation concepts then an additional concern moving forward is that analysts are more likely to be “SIEM-locked” wherein they don’t know how to perform investigations without the use of a specific SIEM.  SOC managers must be certain that their SIEM supports their human-centered workflow rather than developing a workflow solely because it aligns with a SIEM. Currently, my assessment of the SIEM market is that most tools that exist don’t adequately consider or deliver workflow features that focus enough on the needs of the human analyst. It’s likely that many of the 23% of organizations identified as having built their own SIEM like tool share this opinion.


Investigation Metrics are Non-Existent

Collecting actionable metrics has been a pain point for most SOCs I’ve worked in or consulted with. Figure 18 describes metrics that are used, enforced, and consistently met. There are very few metrics associated with the investigation experience itself, except for the time from detection to containment and eradication. As the investigation function is the central workflow of the SOC, this continues to be an area where improvement is desired. Instead, most metrics that are considered are focused on SOC output, and not the efficiency of the SOC itself. While this is helpful for justifying the existence of the SOC (why an org spends money on the function), it isn’t as helpful for improving the SOC (reducing the cost of the function).

SOC Metrics Collected

Investigation-centric metrics might include tracking the usage of specific data sources during investigations (assists), the number of times a data source would have been helpful but was unavailable (turnovers), the most commonly aggregated fields, and average time spent viewing specific data sources. An investigation-centric metric is one that seeks to better understand how the human analyst spends their time while attempting to connect the dots in pursuit of greater speed and accuracy.


Internationalization of SOCs

A significant number of SOC practitioners exist outside the United States, as shown in Figure 2. However, a much smaller percentage of organizations who responded to the survey are headquartered outside the US. The disproportionate number of international analysts is likely attributed to organizations attempting to cut costs by hiring in lower income regions, and organizations that seek to staff 24×7 operations by staffing in different time zones (thereby avoiding having to hire a night shift in the US, which is notoriously difficult).

Locale of Security Operations

There are significant differences in how people think based on the culture they hail from. By nature, most Americans tend to be less sensitive to these variances and project their way of thinking onto others. As the number of international practitioners grows, it’s critical to consider the biases inherent to how Americans think so that we can identify where they may not hold up for international practitioners. As an example, people from Asian cultures tend to require more certainty about a conclusion than their American counterparts before feeling confident in it. Put more simply, someone from Kansas may view the investigation process completely differently than someone from Kazakhstan. By understanding how differing cultural mindsets impact how people approach investigations, we can draw useful data and conclusions towards a more universal investigation process.

It’s worth noting that SANS is a US-based company with a larger market penetration in the US (I don’t know this for a fact, it is an assumption). Therefore, the respondents for this survey question probably under-represent the number of international practitioners and the survey may not represent an adequate global sample. Without access to the source data, I’m unable to assert confidence regarding sample distribution. None the less, this only seeks to strengthen the points mentioned here.


Distributed Environments Require Unique Communication Skills

The increased number of international SOC practitioners in remote SOCs (Figure 2) and the significant number of distributed SOCS (Figure 3) stress the importance of communication in which analysts are not in the same room.

SOC Architectural Approaches

Communication is a critical function of the SOC, and it must be facilitated with appropriate tools. This stresses the importance of investigation tools that provide built-in collaboration features such as the assignment of cases, shared notes, and context tagging. It also stresses the importance of data access and information sharing via tools like wikis or knowledgebases.

Not lost here is the ability to identify and hire staff who excel at non-present communication. As someone who has managed remote teams, I quickly learned that some people simply aren’t effective communicators via text-based mechanisms like chatrooms. Managers should strive to develop strategies for identifying analysts who can excel specifically in these environments. Furthermore, if we can identify these traits and qualities, we should strive to enhance our ability to teach improvement in this communication skillset.


I enjoyed parsing through the SOC survey and want to thank SANS and Chris Crowley for putting it together. In the future, I’d love to see more questions relating to how human analysts perform their jobs and what pain points they have beyond just the tools they use. I’d also love to see this survey repeated on a periodic basis so that trends could be highlighted.

Finally, I’d love to see the methodology used for data collection described here and why they chose the questions they did. I appreciate SANS identifying that the research is sponsored, but citing the methodological approach would shed light on how much influence the vendors had on the questions and the interpretation of their output. A positive step would be making the raw source data publicly available for additional analysis.

I’d love to hear your thoughts on my analysis of the report, including both things you agree and disagree with. You can reach me via Twitter @chrissanders88 or you can e-mail me.


*Note: I was not asked to do this by SANS. This post only reflects my analysis and opinions. 

Introducing the Source Code Podcast

A few weeks ago on Twitter, I teased that I was working on a new podcast called “Source Code”. Creating a podcast is something I’ve always wanted to do, but I’ve never really had the opportunity to pursue it until now. There are a lot of great podcasts in the information security space already, and I’ve been fortunate enough to be guests on a couple of them. So, what makes mine different (aside from being able to make fun of my accent)?

Source Code is an information security podcast that’s all about education. Rather than simply providing technical segments or news, Source Code is focused on the people that push information security forward and battle in the trenches every day.

We interview practitioners from every facet of information security about their origin story. This includes how they go their start, how they got into the field, and the career decisions that made them successful (or slowed them down) along their path. It’s the story of their source code — what makes them tick. We also talk about current opinions on the state of security education to include what we’re doing right and what we’re doing wrong.

You’ll hear from plenty of household names you’ve heard of, as well as some people you should know about with interesting back stories and unique contributions to the field. Source Code celebrates the diversity of backgrounds that makes information security a unique place to exist.

The #1 question I get asked is “How do I get into infosec?” My hope is that through this podcast, I create a library of stories that can help answer that question by showing people that there are a ton of different ways to get started, and each one can lead to great success.

The podcast will live here:

You can also subscribe to it using your favorite podcasting platform:

If you like what you hear, I’d sincerely appreciate you subscribing, “liking”, or giving a positive review of the podcast on whatever platform you use. 

The show is seasonal, and the first season will have eight episodes that will be released every other Friday (you get this one early). I have some GREAT guests lined up, so stay tuned.

I hope you enjoy it!

Increase Security Reporting with Contact Cards

After a really nice weekend, Zeke walked into his office and logged into his workstation. He made a habit of getting to the office around 7 AM on Mondays so that he could go through the pile of unanswered e-mails from the previous week and clear out all junk that accumulated over the weekend. As he was going through e-mails, he spotted one with the subject line “401k performance highlights” that was sent towards the end of the day on Friday. He had seen it then, but was in a rush to get out the door. He opened the e-mail and read that his 401k had performed better than expected over the previous quarter. A link was provided to review the details so he clicked it. That was when he realized he had made a mistake.

The link didn’t go to his 401k provider as expected, but instead went to a suspicious looking fake site that was made to look like it. Zeke had gone through information security awareness training, so he knew how to spot forgeries like this. It was very obvious that the site was hosted on a domain made to look like a legitimate bank, but was in fact not associated with it at all. He immediately closed his browser window and waited. His system seemed to be fine. No weird pop ups, no prompts to download any software, no weird slowness. He had dodged a bullet. He remembered that he was supposed to report occurrences like this, but wasn’t entirely sure where. Was it the IT helpdesk? No, it was a special e-mail address….or was it a phone number? He quickly looked up the contact number for someone he knew who worked in information security. Hmm, no answer. It’s still pretty early so that person might not be in. He shrugged it off and went about the business of responding to unanswered mail. By the time his day got going, he forgot all about the incident and it never got reported.

Stories like the one here are common in large organizations. Many companies do their part and invest heavily in security awareness programs that teach employees how to spot phishing attempts and security anomalies so that they can be reported. However, many organizations struggle with the final step in this process — effectively enabling their users to report anomalous activity.

So, why do users fail to report security issues when they recognize them? You might expect me to provide a long-winded underlying psychology perspective. However, the answer is much simple than that. People rarely have the opportunity to report security incidents, so they forget how to do it. Just like Zeke, they forget the e-mail address or the phone number. Further, they are often hesitant about whether anyone actually cares about what they’ve observed, and they’re worried that incompetence will be exposed. Of course, there isn’t incompetence here, but all that matters is that the individual perceives the possibility of it. Nobody likes feeling dumb, so someone certainly aren’t going to go out of their way to report an incident if it means potentially going through multiple layers of people. That increases the chance that perceived incompetence gets exposed. In summation, people are less likely to report security incidents unless it’s incredibly easy, and that is a defense mechanism that is difficult to overcome.

How do you eliminate that defense mechanism? Well, that’s a difficult question with multiple facets and is far beyond the scope of what I have to offer in this humble blog post. I think the better and more practical approach is to make security incident reporting as simple as conceivably possible. For that, I offer a non-technical solution.

The best strategy for reporting security incidents that I’ve seen is simple. Provide every employee with a security reporting contact card (SRCC), like the one seen in the image below.

As you can see, this card is incredibly simple. Ideally, this is printed to the same size as a business card on heavy stock. This provides a form factor sizable enough to display all the necessary information, but small enough to be easily tucked into a wallet or purse. The idea is simple: every employee receives one of these cards and is requested to keep it close at all times. While most employees can’t be expected to remember an obscure e-mail address or phone number, they will remember that they were given this card and can reference it without hassle.

So, what is necessary to include on the SRCC? This can vary, but I recommend making sure that the card can answer these questions:

  • Who can I e-mail/call for any network security related issue?
  • Who can I e-mail/call for any physical security related issue?
  • Where can I forward phishing or scam e-mails?

The purpose of this card is not to educate people on what’s reportable. That should be a goal of your information security awareness training and certainly won’t fit on a card. However, the three questions mentioned above cover a lot of the things that will generally be reportable. By providing e-mail addresses and phone numbers, you provide an implied escalation path if something is deemed to important or time sensitive for e-mail.

A few other tips:

  • Use a bright, easily noticeable color on your card. This will help people spot it and remember where it is in their wallet/purse.
  • Make the design somewhat different from your normal company business card template.
  • Setup a special e-mail address to receive forwarded phishes separate from your normal intake queue. This will help with prioritization and tasking.
  • Build this into your security awareness training. Occasionally challenge people to produce these cards so everyone gets used to keeping them handy. Make sure you are clearly identifying what is reportable and what isn’t based on your organization’s threat model and ability to evaluate reported incidents.

If you want to get started right away, here’s a Microsoft Word template you can download and use now. Just replace the logo and information with your own, print it out, and hand them out to your employees.

So what ever happened with Zeke? Well, it turns out that once he clicked on the link in the phishing e-mail, his browser downloaded a flash exploit which led to a malware infection. An attacker was able to leverage access to this system to retrieve sensitive information about Zeke’s company. It took the attackers a few weeks to complete their attack. But, since the detection tools in the organization didn’t pick it up, and Zeke never reported it, the attack wasn’t discovered until much later. The organization did a lot of things right, but a failure to make incident reporting easy subverted much of their effort. Security contact cards a simple, affordable, effective way to make sure you don’t fall victim to a similar scenario. The minimal cost of printing and distributing these cards is nothing in comparison to what you might pay if something goes unreported.