Category Archives: Network Security

Today I want to talk to you about forcing decisions and how you can use the concept to gain a strategic advantage in your infosec work.

Over the past few years, the Golden State Warriors have revolutionized the game of basketball while winning two NBA championships and putting up record-setting numbers in a variety of statistical categories. They aren’t just winning, they’re dominating and changing how people approach the game at a fundamental level. There are a lot of reasons for this, but none more apparent than their fast-paced offense that is built around passing.

I recently read an article from ESPN describing how Warriors coach Steve Kerr formulated his offense. The article’s worth reading if you care about basketball, but even if you don’t I think there’s one quote in there that’s relevant beyond basketball. The Warriors star player, Steph Curry, had this to say:

“The main goal is to just make the defense make as many decisions as you can so that they’re going to mess up at some point with all that ball movement and body movement and whatnot.”

The concept is simple but powerful. When a player makes a pass to another player, it forces the five defenders to make a decision and react. There are a lot of variables that have to be considered very quickly.

Now, let’s say that as soon as the second player receives a pass, they make another pass. What happened?

It forces the defense to consider a new set of variables, probably before they’ve had a chance to fully react to the variables encountered from the first pass. This mental reset causes confusion and slows the ability to react with the correct adjustment. Every quick pass compounds the opportunity for confusion. The Warriors rely on this to succeed, and it’s one of the reasons they track their passes per game statistic aggressively.

Watch the guys in blue. Notice how lost they look after the first few passes? They’re lost! A couple of them have basically given up on the play by the time the shot goes up.

Of course, this concept goes well beyond basketball. It relates to all decision-making.

Forcing Attacker Decisions

Any time you make a decision you are processing all available information. Good decision making is based on understanding every variable and having time to thoughtfully process the data. I believe network defenders are in a unique position to force poor attackers into poor decisions.

Home court advantage matters.

The attacker doesn’t know your network. To learn it, they have to go through a period of iterative discovery. An attacker gains access to something, pokes around, gains access to something else, pokes around more, rinse and repeat. The attacker doesn’t know your network, but they will learn it as they move closer to their objective. Each step of discovery provides an opportunity to force decisions through the strategic introduction of information. When this happens, an attacker might do something aggressive enough that it trips a signature, pivot around rapidly and leave a few extra breadcrumbs in your logs, or withdraw completely.

Let’s talk about a few ways you can accomplish this.

Honeypots. I’m not talking about traditional external malware-catching honeypots that we’ve all set up and forgotten about. Production honeypots sit inside the network and are designed to mimic systems, processes, and data. Nobody should ever access these things, so any access constitutes an alert worthy event. Beyond detection, internal honeypots can also serve to confuse attackers and waste their time. Security is an economic problem and when defenders can increase the cost of an attack, this can serve to ward off opportunistic or lesser resourced attackers.

Deception Traps. The use of deception tech (beyond honeypots) is on the rise, and I think we’re well behind on leveraging these concepts. I’m not talking hacking back or security through obscurity — I’m talking passive engagement of attackers on your home court through automated traps. These are the traps that, when interacted with, provide information to an attacker that can confuse their understanding of the network itself. For example, IP space that responds to scans, but houses no systems. Perhaps some of those systems respond differently to scans depending on the source or time of day. Another example might be web application directories that when accessed, redirect the user to random pages or create endless redirect loops. One last example might be running processes on a system that appear to be named after multiple antivirus binaries. That would certainly be confusing to see multiple AV tools on a single system. One more — what if an attacker discovered user accounts and logs that indicate they aren’t the only attacker on the system? That might cause them to make a hasty retreat or try an aggressive pivot. These ideas aren’t exclusively about detection (although they could be used in that way). They’re about providing confusing information at inopportune times.

Scheduled Shutdowns and Restricted Logon Hours. It’s insanely easy to configure systems to shut down during off-hours and to limit certain user accounts to specific login hours. Yet, I never see anyone doing it. Sure, you have to account for users who might work late and keep systems up so that they receive important updates. However, forcing these schedules will throw an attacker who is poking around on your network off. They will likely figure it out eventually, but that still gives them a time window wherein decisions could become hastened when they know the deadline is approaching. There’s no better way to force decisions than to put a time limit on them. As an added bonus, limiting login times can help workers maintain a healthier work/life balance, and shutting systems down lowers your electric bill and is good for the environment.

Conclusion

These strategies won’t completely stop the attacker, but they do have the potential to slow them down enough so that you may detect them before they reach their goal and you’re dealing with a larger breach. Furthermore, it increases the attacker’s cost and effort to reach their goal, and this might just be enough to ward off opportunistic attackers or attacks based on automated processes.

While these techniques aren’t appropriate for every security program maturity level, they provide an opportunity for innovation in the open source and commercial product space.

The Warriors succeed because they tried something different using the skillful talent they had. You can do the same, but like Steve Kerr and Steph Curry, you may need to think differently and apply a unique strategy. The fundamentals matter, but so does being different.

My challenge to you: Think of a way you can force an attacker into making a bad decision. Have some cool ideas? Post them in the comments below.

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:

Simulating responsive services

Identifying imported code libraries

Understanding network communication sequences

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

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:

Simulating a DNS server to resolve a domain requested by an iOS dropper

Identifying the code libraries imported by Windows malware to understand its purpose

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.

Challenge

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.

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.

Conclusion

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!

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.

Conclusion

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.

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.

Stay Updated!

I use my mailing list to send out exclusive content, training discounts, and it's the best way to stay up to date on new classes I conduct on topics like network security monitoring, packet analysis, technical writing, and more.

* indicates required

Email Address *

First Name

Last Name

Applied Network Security Monitoring

Applied Network Security Monitoring is the essential guide to becoming an NSM analyst from the ground up. This book takes a fundamental approach, complete with real-world examples that teach you the key concepts of NSM.

Practical Packet Analysis

It's easy to capture packets with Wireshark, the world's most popular network sniffer, whether off the wire or from the air. But how do you use those packets to understand what's happening on your network? This extensively revised second edition of the best-selling Practical Packet Analysis will teach you how to make sense of your PCAP data.

100% of the author royalties for sales of Practical Packet Analysis go to support the Rural Technology Fund

Rural Technology Fund

Established in 2008, the Rural Technology Fund (RTF) seeks to reduce the digital divide between rural communities and their more urban and suburban counterparts. This is done through targeted scholarship programs, community involvement, and the general promotion and advocacy of technology in rural areas.