Listen to this podcast on Apple Podcasts, SoundCloud or wherever you find your favorite audio content.
Summer has arrived. As the mercury rises, it’s worth considering how a streamlined, empowered security operations center (SOC) can help your organization keep cool under an oppressive heat wave of potential IT threats.
This week, the venerable duo of David Moulton and Pam Cobb are joined by Emma Bickerstaffe, senior research analyst and SOC expert at the Information Security Forum (ISF), and Jamie Cowper, security orchestration product marketing manager at IBM Resilient. Together, they tackle the evolving impact of tailor-made enterprise SOCs.
What Is a Security Operations Center?
What is a SOC? Bickerstaffe defines it as “the eyes and the ears of an organization, sounding the alarm when it detects anomalous or malicious, suspicious activities and, importantly, enabling the crucial response.” She also notes that it goes by many names: Some enterprises prefer SOC, while others use cybersecurity operations center (CSOC), cyberdefense center (CDC) or joint operations center (JOC).
No matter the label, Cowper says, the function remains the same: Companies are “trying to move away from just being this organization that’s dealing with the flood of inbound alerts, threats, offenses, and move to being able to be more proactive, actually hunting out the threats, looking for ways to identify upcoming, potential risks to the business, and reacting before being under attack.”
How to Design and Deploy an SOC
It’s one thing to recognize the value of the SOC, but it’s another to effectively design and deploy security operations at scale. What’s the first step? According to Bickerstaffe, companies “really need to have a handle on what the business driver is for the SOC.” From there, the ISF defined five core capabilities that are critical for security operations center success:
- Data Collection and Correlation — Deploying the right sensors to collect the right data and correlating it to prompt key alerts.
- Detection — Including anomaly identification, threat hunting and behavioral analysis.
- Monitoring — Here, the priority is triage: determining what alerts in your SOC are important and which are false positives.
- Security Investigation — Organizations need capabilities such as forensic and malware analysis to evaluate and classify incidents.
- Incident Response — Automated, intelligent tools can help empower SOC-level incident response for “a certain class of security events under predefined parameters.”
What’s Next? Purple-Teaming and Proactive Tools
So what’s next for the security operations center? Bickerstaffe points to emerging hybrid models that use a combination of internal and external capabilities to deliver improved protection. She also highlights the use of “purple teaming,” which combines red- and blue-team exercises to fine-tune alert criteria and improve SOC response.
Cowper also notes the emerging need for context — determining top organizational threats “and then building the automation and the flows around them” to maximize SOC impact. Moving forward, Bickerstaffe suggests a shift to a fusion center that integrates SOCs into a larger umbrella group. This facilitates collaboration and engagement with the computer security incident response team (CSIRT) and drives a “collaborative, holistic approach, which incorporates the detective and the responsive elements that are really important for a SOC to achieve.”
Learn more in the ISF Report “Building A Successful SOC: Detect Earlier, Respond Faster”
Episode Transcript
David: Pam, how would you describe a SOC?
Pam: Well, if you’re talking about a security operation center, I really think of it like the brains, sometimes, of the operation, where there’s all this hive of activity, and everything’s coming in and going out. And it’s a lot to process.
David: One of our guests this week described it in a way that I actually really liked. She called it the eyes and ears of the organization. And I think that’s really true, especially when you think about what’s going into the SOC and what’s coming out of it. It’s the key processes to help you understand what you’re seeing and what you’re hearing.
Pam: This is the Security Intelligence Podcast, where we discuss cybersecurity industry analysis tips and success stories. I’m Pam Cobb.
David: I talked with Emma Bickerstaffe, Senior Research Analyst at the Information Security Forum, and Jamie Cowper, director of marketing for IBM Resilient, about the evolution of a SOC.
Something I thought was really cool was in our conversation, Emma was able to go from very detailed conversations, very practical advice, up to the highest level to give you that context that helps you understand what’s going on in a SOC, and what the experiences are of some of the professionals that she interviewed. Here’s our conversation.
Emma: My name is Emma Bickerstaffe. I’m a senior research analyst at the Information Security Forum, so the ISF. I’ve been here for around two years. My background is defensive security and within the government. And then, since I’ve been at ISF, I’ve been focused on data leakage prevention, and more recently, our research project on building a successful security operation center.
It would probably help a little just to give a quick background on the ISF. It’s 30 years old this year. We are a not for profit organization, and we work with some of the world’s largest organizations on a whole raft of information security topics and providing them with approaches that really allow them to get a good handle on information management issues.
David: And Jamie, can you go ahead and tell our listeners a little bit about yourself, your role, your background?
Jamie: Sure. Hi, Jamie Cowper. I am the product marketing manager for the Resilient security orchestration automation platform inside IBM Security. I’ve been working for IBM since the acquisition of Resilient in 2016, and I have previously been working in the security space for just under 20 years in large and small vendors, working on encryption, on authentication, and messaging security issues.
David: So, for those of us who are inside security and understand the jargon a bit, that’s going to seem really familiar. But why don’t we start by briefly just describing what a SOC is, maybe, what it isn’t, and just level setting there.
Emma: Sure. So a SOC’s a security operation center. An intriguing thing about that is it means many different things to many different people, and I think we’ve really seen the concept of a SOC grow and evolve over the past 10 years or so.
So, we looked to define it. Actually, it was a bit more tricky than we thought, because of so many different perceptions of it. But I quite like the analogy of a SOC serving as the eyes and the ears of an organization, sounding the alarm when it detects anomalous or malicious, suspicious activities, and importantly, enabling the crucial response.
And I think, really, we’ve seen some organizations keep the term SOC, others feel that it’s a bit antiquated, out of date, perhaps doesn’t really describe what their SOC does, and are turning to different acronyms. So, we’re seeing, like, a CSOC, a cybersecurity operation center, a CDC, cyber defense center, and even a JOC, joint operations center, for bringing operations into where we’re looking more towards that fusion center concept.
David: And Jaime, do you have anything that you would add to kind of round out what Emma is talking about with these variety of things that all seem like they’re on the same core idea, but maybe have different or slightly different missions?
Jamie: Sure, yeah, no doubt. Beyond the notion that we do love an acronym in security, right, don’t we? This idea of a SOC has become something of a catch-all for the operational capacity, and how do you do in those day to day managing of threats. And people do think differently about it. And definitely, if we look at — maturity is always a tricky word, but organizations who have perhaps been doing this kind of processes a bit longer — and then they’re moving towards more of the fusion concept, where they’re looking at different domains.
People separate things like incident response out into the cybersecurity incident response team, the CSIRT, as opposed to a SOC. So, it can get really complicated. But it’s thinking about the operational capacity to detect and respond to threats is tentatively how I think of it.
David: Okay. And Emma, coming back to you, I know that there’s an ISF framework for building a SOC. Could you talk about that, and help me understand a little bit of what that’s based on?
Emma: Absolutely. So, with all our ISF reports, we put a huge emphasis on engagement with our members who come from a large range of sectors and industries, we’ve been even from Forbes 2000. So, we ran about 19 workshops around the world, including at our annual World Congress, where we sought to really ascertain from our members, the experiences with running a SOC.
And we took from that their successes, their pain points, so where they’ve done really well, how they’ve overcome some challenges. And we put together a five-phase framework with practical guidance on how to build a successful SOC sector, divided into five phases. So some of those are more your normal program management type things that you really apply for any security initiatives. So you know, how do you initiate a SOC program? And focusing on the fact that the program, not the project is very long-running, and then defining those key requirements, making sure they align with your business needs. And then going through that whole phase of designing a SOC, finishing it up, running it, and then importantly, how do you enhance that over time?
I think, if we look back 5, 10 years ago, even, when we really thought of the SOC as a monitoring and alerting capability, so we really just sought to detect security events, if there was something of interest, it would kick it over the fence to another team. It’s really evolved now to a bit more holistic approach, where it goes back to not just the detection element, but importantly, the response, and moving also into preventing security incidents and also anticipating a particular threats as more of a focus. And with that, we’ve seen members adopt new tools, new approaches, and so focusing also on how they can be more efficient.
David: And Jamie, I’m sure you’re talking to customers about this quite a bit here at IBM. I’m wondering, as you’ve seen the evolution of the SOC, anything that really sticks out or is exciting to you in the nearer term of how things have changed and where things are going?
Jamie: Yeah, and I think Emma touched on it, though, but it’s trying to move away from just being this organization that’s dealing with the flood of inbound alerts, threats, offenses and moved to being able to be more proactive, actually hunting out the threats, looking for ways to identify upcoming, you know, potential risks to the business, and reacting before being under attack.
And that always becomes the challenge: how do these teams get that capacity to move away from just responding, and to be threat hunting, to drive those initiatives? But we’re definitely seeing more and more organizations making time, freeing up people’s time in part of their schedules to actually really look at initiatives like that.
David: So across the board, are there some common pain points that customers talk about?
Emma: Absolutely. I think some of the real pain points is trying to do everything at once. So, our recommendation really is that you need to start small. Like, think, of course, of the future and what you want to achieve, but actually starting small and then growing iteratively, taking very much a phased approach to deployment.
I think some of the other pain points is the data. So if you can’t just ingest any data into your SOC, you really need to clearly define what are the threat scenarios that are important to your business, and start there, and think specifically around what your log sources are that you need, and then exactly what data you need from those log sources. Otherwise, you’re just going to be completely overwhelmed with a flood of alerts, and then we get into that alert fatigue, which is a very problematic across many different organizations and their SOCs.
Jamie: And that would be something, David, that certainly we hear all the time, that kind of signal to noise ratio. If anything, people have too many signals, and how do they know which one to listen to, or how to tune and tweak them so that you eliminate, you reduce the false positives and really prioritize overburdened people onto, you know, the real stuff.
David: Right, so it sounds like it’s that 80/20 rule, the Pareto principle. You’ve got to find most of your value from 20% of that data.
Well, that’s really interesting that, you know, maybe there’s some excitement, and companies or businesses are jumping in and then finding that they’ve got to really tune how they look at things and evolve, to who they’re going to involve in their SOC or their evolution of the SOC over the years. Would you say that most organizations have a fully operational SOC?
Emma: I think there’s definitely organizations that have an operational SOC, but really, whether that’s achieving exactly what they want to is quite ambitious. Having full visibility, for example, is an extremely ambitious objective, but one that everyone’s trying to achieve.
So, I think because it really is such a multi-faceted, complex undertaking to build a SOC, we’re really thinking at least 18 months before we’ve got the cogs rolling. And then after that, you’re starting to enhance it, add new capabilities. Now for example, in India, user entity, behavior analysts, automation are all becoming the rage, so we’re trying to adapt constantly to new technology, new tools, and an evolving threat landscape, of course.
David: And so as you’re thinking about that, it sounds like there isn’t a point where you can check the box and say, you know, our SOC is up and it’s running. Because the data changes, the threat changes, how you’re going to approach protecting your business or what your goals are. Those all evolve as the business and the landscape change, right?
Emma: Absolutely, and your SOC can never be stagnant. And it’s not even just looking about what your business requirements are, which of course can continue to change. You might have a merger and acquisition, for example. But it’s also, as experts, you are still learning about how to use your tools, you still need more people to be able to run your tools. So no, your SOC is never stagnant. It’s constantly having to adapt.
David: So that first step may not be going, getting the support, but to very clearly define the benefit to the business. And then, like you said earlier, maybe start small, and define what data you need to look for a particular outcome.
Emma: Absolutely. You really need to have a handle on what the business driver is for the SOC. And talking early on with business stakeholders about that, making sure their expectations are aligned with yours, and that you’ve clearly got that defined. We’re seeing some organizations using a SOC charter as well as a good way to actually document what their objective is and the mission and vision of your SOC is.
David: Jamie, are you seeing customers that have a charter versus not having a charter, maybe more or less successful as they’re setting things up?
Jamie: Yeah, I think definitely people have that clear idea of where it’s going to go. And I think the critical thing is that senior engagement and empowerment. If you look at it, often, unfortunately, we find that the triggering event might be some kind of security incident or breach that actually unlocks the budget, or gets the executive buy-in.
And then it’s about, well, how do we build out? What is our strategy for setting this up? Roles and responsibilities, how are we going to grow it? How are we dealing with different regulatory regimes, or different operating groups? Because a lot of customers, you may have completely different tooling in different territories, for example. So you have to really think about how you build out, so having that planned, structured approach in a charter as part of that makes a ton of sense.
Emma: Absolutely. And the charter can also ensure that you are aligned with the organization’s risk appetite, that you’ve taken into account the compliance requirements and that kind of thing.
David: So Emma, what business drivers have helped ISF members or customers secure buy-in and the resources that they need to get going?
Emma: I think as Jamie said, suffering from a security incident or a cyber attack is definitely one driver that often prompts people to not even start the SOC, but perhaps improve the one they already have.
The other one that we often see a lot of ISF teams talk about, particularly in the financial industry is compliance requirements, the compliance with legal or regulatory contractual requirements, perhaps from monitoring capability. In saying that though, we really kind of caution against, you know, having an over-focus on compliance requirements. That will really consign your SOC to more of a checkbox exercise rather than actually reaching its full potential.
Some other, some good business drivers are you might be setting your SOC up because you had a particular threat. Like, if you’ve been asked to address reducing the cost that are associated with security incidents is another one. So I mean, if you have a SOC monitoring capability, something that’s responsive and agile, proactive, you can then detect security events earlier, respond faster, and ideally prevent against those along the cyber attack chain as possible. So you can then tie into that the threat to your organization’s brand and reputation, and also the financial risk that comes with that.
Jamie: I think that’s actually a good point. And, David, if we look back in some of the Ponemon research and Cost of a Data Breach, you can see the use of some of these, whether it’s automation or incident response platforms, they can pretty dramatically reduce the cost of a breach, or the cost per loss record. So that risk, if you’ve got a good process, you should be more likely to identify these risks earlier in the life cycle, and hopefully, you know, reduce the dwell time and limit the risk exposure of the business.
Emma: That’s what I see. I think another really interesting one that I see ISF members talk about is leveraging the SOC as a sort of marketing tool, that can really help serve as a differentiator from competitor’s products. I think that’s quite an interesting business, you know, sort of driver that people have managed to get the buy-in.
David: All right, so when you talked about, like, starting small, do you have to build the SOC internally, or is that something that you can do externally? Or is there an optimal mix of those types of things? Talk to me about that a little bit.
Emma: Yeah, so there’s a mixture of different ways you can go about building a SOC. In the report, we’ve divided this into three, so an internal SOC, where you’re building it entirely within your organization with your own staff, equipment, processes. We also have an external SOC, where you’re using the services of a managed security service provider. So, you’re buying a SOC. And then, we also have a hybrid SOC, which is a mixture of the two. And so what I think we see ideally, that we used in the workshops, actually, we ran an exercise where we asked what are the benefits and the limitations of these three different types of SOCs, realizing, of course, there’s variations across the entire three. So, we ran this exercise, and everyone actually came up with some similar perspective on the three.
So we think, particularly for internal SOCs, some of the now ISF membership, about 45 percent of ISF members have gone down the route of building an internal SOC. They really see the advantage of having greater control and ownership over the SOC and its future trajectory, but most importantly, that it has the familiarity with the business and the organizational environment.
That business knowledge is really important and improves the ability to respond to potential security incidents. It means they have visibility of the IT environments. Maybe they understand what’s going on, and they can importantly, you know, step outside of the SOC and tap someone’s shoulder and engage with them, and have those important conversations, and resolve issues quickly. So the limitation straight away there is, of course, the money and the high costs involved with the SOC.
And the other thing I think I mentioned with the internal SOC is staff retention. So, recruitment and retention of SOC analysts is an ongoing issue with SOCs. I think ISF member’s said if there’s one thing they could do if money was no object, it would be to recruit more staff, more skilled staff, and really focus on how to keep them motivated.
David: All right, so it’s not a technology issue that’s the number one thing for those that have the internal team, it’s keeping those great people inside of their business. And it is a really competitive market out there right now, and we know there’s a huge skill shortage. So that external and hybrid model, are those the ways that some of the other companies are addressing that, or is that just a complete preference in how they’ve set it up?
Emma: I think it’s a preference for organizations that are particularly protective of their data, for those it’s quite sensitive to have an internal SOC. But lots of them are looking to a hybrid model, it’s definitely becoming more and more popular. And they’re looking to a hybrid model as a good way to actually augment their internal SOC.
And they can use the services of the MSSP, for example, to provide after hours as one way, or they might have that tier-one, level-one SOC analyst, those responsibilities and roles performed by tier-one being provided by the MSSP and they take on the tier-two, three. So, there’s lots of ways that the hybrid model is being used by organizations to really supplement the expertise that they have within their own SOC.
I definitely see it as being used a lot more, and people certainly point to the benefit of you can actually have that cross-training, cross-learning angle, where you take on from the MSSP, their experience and knowledge. And the other thing is I think some people really do see it as kind of being the best of both worlds. But you still have to be very clear around who has what responsibility between the MSSP and your internal SOC.
David: What are some of the core capabilities that you want to see in a SOC?
Emma: From the core capabilities of the SOC, we ran this is an exercise. We asked our ISF members what capabilities they see as most important for a successful SOC, and we sort of landed on the top ten, really, of what people think is important, and also to what extent they perform those activities. And there are so many different capabilities that can fall within the arena of the SOC. I really just think that depends how you, as an organization, slice and dice. It’s almost like a scramble, pick and mix type of thing. So, we’ve kind of tried to just expect, lay out and today, even a higher level.
We’ve taken five core capabilities. The first we see is that data collection and correlation. And that’s really looking at what data you want to collect, and then how you correlate it. And that starts from actually having it deploying your sensors to collecting the right data, and then correlating it so you’re getting the alerts that you need to address those use cases that you’ve identified.
The second core capability is really around detection. So, we’re thinking here around real-time monitoring, anomaly detection, threat hunting for those who are more advanced. And also, you will be seeing a lot more behavioral analysis. And intriguingly, I think members behavioral rated analysis as quite an important capability, but a very small amount of them are actually successfully doing it. So I think we had about 9 percent who said that they are actually doing it well, but about 48 percent of them really want to field it within their SOC.
The third one is around that kind of monitoring side. So, triage and actually determining what alerts come through your SOC are actually important, what are false positives, what actually need to have the escalation for further investigations.
And that leads me into that fourth capability, so security investigation. And here, you can see your forensic analysis, your malware analysis, to what extent has a security incident occurred? How would you classify it?
And then the final one is incident response. And it’s an interesting one because we all talk about the importance of a SOC and incident response, but of course, a SOC will hand off to other IT teams to contain, eradicate, recover. But more and more we’re seeing some of the advanced organizations actually having some sort of ability to take mediation actions. And that would be normally for a certain class of security events, but under very predefined parameters which have been agreed with stakeholders.
And some organizations will balk a bit, find it perhaps a little bit beyond be it bravery or something that perhaps might be in the OT environment, and which might, of course, be completely beyond their hands. Others see it as really useful in that they can contain something really quickly if they need be, and then they’ve got that predefined authorization to do so.
Jamie: I think you come back to the processes there really, don’t you, Emma? Because it’s about understanding what your threats are, and what the response might be would then allow them to say, well, we always expect this to happen if we were investigating a malware outbreak, or a denial of service, and then having predictable response behavior.
Emma: Absolutely. I think if we can just summarize then that we’ve got five key capabilities, and that’s data collection and correlations, detection, monitoring, security investigation, and incident response. And as SOCs really further evolve and develop, they’ll be adding various sort of services or capabilities to improve their ability to do each of those capabilities and perform them well.
David: So, Emma, as you think about that evolution, what are SOCs doing to enhance themselves over time?
Emma: Yeah, so a lot, actually. I think a lot of them are turning, obviously, to SOAR tools, so security, orchestration, automation and response tools to improve the efficiency of their SOC. It’s one way to really address the alert fatigue so that the automation can take some of those more mundane, repetitive tasks off the hands of the security analysts so they can focus their time to more complex investigations, or the lack of threat hunting to go and search for those unknown unknowns rather than the known knowns, which is what you really configured your systems to detect.
We’re seeing the SOAR tools definitely are of interest to members. I think for those that are doing SOAR well is in that sort of learning process because you need to have very define processes that you’re applying automation to. If you have a bad process and you apply automation to it, then you’re just really aggravating an already bad process. Yeah.
David: Right. So, are any of the ISF members, or customers, or your personal experience of a SOC successfully implementing changes that improve their incident response?
Emma: Absolutely. I think actually, one of the things that I’ve seen as a trend is the use of purple teaming, which is more around the detections, but it then means that you can respond. But they’re looking at purple teaming where they’re combining the blue and the red so that the red will be, you know, simulating a particular threat attach or scenario, and testing whether the alert criteria is correct so that you can pick it up, or do you need to actually fine-tune the alert criteria. Purple teaming is one way I’ve seen really good improvements made as a result of that, and that’s really ensuring that you’re fine-tuning what you’ve got so you can respond.
David: And how about any other area of the SOC where you see teams are doing something innovative or a little different to improve their capabilities?
Emma: Actually, one thing that I saw an ISF member using which I quite liked was the concept of the “golden week,” which is actually allowing the analysts to go and innovate for a week. So, they step out of what’s their day to day tasks and have that chance to do something a bit different. That might be threat hunting, that might be a completely new initiative that they have to improve the running of the SOC. I think people are using threat intelligence more and more, and how do you use that effectively for your SOC so that you can respond well, and that you can also ensure that you’re reviewing where the vulnerabilities that apply and how they affect your particular assets, and what you can do to prevent a security incident happening for your organization. What else are people doing to evolve?
Jamie: I’m seeing some interesting stuff around machine learning in some organizations, where they’re really bringing data scientists into that SOC world. I mean, one thing you know, the SOCs aren’t short of is data. So if you get the right algorithms and models, you know, really helping to predict whether something’s a real threat or the severity of it, or even down to who are the right team to follow this up. There’s some interesting models you can build once you start. But I think it’s still quite early, but there’s definitely interesting use cases, in terms of what are the real threats, how to prioritize workload.
Emma: Yeah, and I think the data scientist piece coming into play as well, of using data lakes. So we’re seeing lots of organizations build data lakes, and then seeing how they can apply their security analytics, the machine learning, the behavioral analysis, and overlay that on to the data lakes to anticipate threats better.
Jamie: And that combines pretty nicely, actually, with some of the threat intelligence you get that helps you say, well, is this something I need to worry about, and then linking it back into your own environment.
Emma: Yeah, exactly. And I think it’s really important, as well, that we don’t just think about all the different event data and the logs and the net flow, etc., that you need and to feed into your SOC. It’s also that contextual data which isn’t…it is importantly the different threat intelligence feeds you need, but also your vulnerability scans, your CMDB. I mean, that’s one of the things that we’ve seen organizations struggle with, is not having a thorough, robust CMDB and asset registry in place, and that can really be a point of issue for a SOC. So, having those vulnerability scans as well, and HR feeds, for example, there’s just so much contextual data that you need to think about, as well as that event data.
David: And are you seeing a delta between companies that are using a CMDB, maybe effectively are struggling because it’s not at the level of completeness that they need, and those that have moved to some of the cloud environments where, you know, the containers carry the contextual data that they need to understand, you know, what those workloads are and the relationships?
Emma: Yeah, absolutely. I mean, I think when we had a survey recently, one of the main challenges in running a SOC that was identified by ISF members was that their CMDB was a mess, and they wished they had a CMDB that was filled up, that was up to date, that was current. I think we can think here as well about how can a SOC actually contribute to improving the asset registry. Because they also have a lot of visibility, so it’s obviously not the responsibility, but how can they actually contribute there and improve the asset registry.
David: And I would imagine, Jamie, you’re seeing customers that are focused in this way automate quite a bit, try to find ways of orchestrating around the key elements of their business. Do you have any examples that you can share with us?
Jamie: Yeah, I think…you’re right, Emma talks about it, you know. So it’s that combination of looking at the internal crown jewels, the other one is, increasingly, what are those external threat factors?
And context is really the keyword here. So, what are organizations like mine, or in my geography, my business, what are they seeing? So, getting that relevant threat intelligence, you can build in the playbooks based on that. Keeping it manageable in terms of those numbers, what are the top threats, and then building the automation and the flows around them. You can’t fix everything at once, so you have to focus on those specific use cases.
And typically, insider threat is a very common one across customers, phishing is always there, right, just because of the sheer volume. And then it really depends on maybe some industries are aligning. In banking, we’re seeing a lot of work where you’re aligning fraud use cases with traditional cyber SOC ones. And in pharmaceutical, it tends to be more kind of espionage and IP theft driven. So there’s definitely, depending on your business unit, depending on where you are, it’s really about aligning those processes to those threats.
Emma: And I think we talk about having these use cases, and as part of the use cases, when you’re defining your correlation roles and setting up your alerts, etc., it’s just as important to think about incident response, and how are you going to respond when your SOC actually picks up the particular activity which suggests that you’re detecting that threat. So there’s no point detecting something if you don’t know what you’re going to do once you’ve detected it. It’s really important to have some guidance, at least, on what your analysts should do when they do detect that activity.
David: So, we’ve talked a lot about how the SOC has evolved up into present. I’m curious what you see in the future for the SOC. How’s it going to change? What are some of the things that you anticipate will drive the change?
Emma: I think as we look ahead, we might go increasingly more towards the cyber defense center type concept, or the fusion center, where the SOC is integrated into a broader umbrella group, so that it can have that close collaboration and engagement with the CSIRT, with the threat intelligence team. So that as you see the line between detection and response blurring, I think we’re seeing more and more tools being cross-pollinated across the various teams that previously have been diffident.
I think we will see more of a collaborative, holistic approach, which incorporates the detective and the responsive elements that are really important for a SOC to achieve. And maybe we won’t be calling it a SOC in ten years’ time. I’m not sure if the term will still be around, that’s one out for the jury.
David: I agree. I think conceptually, though, the idea that there’s a team that’s dedicated to protecting value for the business, making sure that you’re compliant, making sure that you’ve looked at ways of being ready to respond, and keeping those core things about the business safe, that won’t go away. I think that that’s going to be key.
Emma: Absolutely. And I think we’ll still see more and more tools, and machine learning is definitely starting to be more of a signal than the SOC. I don’t think that’s fully-fledged yet, so I think as we move forward, we will see it having a more of a role to play and definitely be a vital component of a raft of different tools for the SOC users. And those data scientists will probably be more on those staffing models that a SOC will be considering as well.
David: Yep, always evolving and innovating here in security. So, Emma, thank you so much for taking the time to talk to us about the research you’ve done, share a little bit of an insight into the report that you’ve talked about. Our listeners can find that in the link to the show notes.
Emma: Perfect. Thank you so much, David. It’s been a pleasure to join you today. The listeners, absolutely, they can go to www.securityforum.org to access all those ISF reports. There’s a number of executive summaries available for download there, across numerous topics that we’ve been looking at this year, and in the last thirty.
Pam: All right. I really love that Emma and Jamie offered so much practical advice in their conversation. I’m curious, were there any takeaways, David, that you hadn’t considered before?
David: So Pam, one of the things that I really thought was interesting was using the SOAR tools, the automation to free up the analyst. You know, if you can put something on autopilot and you know that you’re going to get repeatable results, you’re going to get that speed out of it, it opens up really smart people, those that work for you, to go and be creative, to be innovative, and to come up with new things that keep them excited and maybe find new automations, find new things that could be stronger in your processes and your security, or invent new tools that help you deal with the very specific problems that you face in your business. So, having that golden week, that’s an incredible idea. I think that any company that doesn’t consider trying that out is going to be missing out.
Pam: That really is living the dream, like, the promise of AI, and you know, without the fear of imminent Skynet, and Terminators, of you know, being able to make use of the tools we have to further and free up people to do what they do best, which is creative problem solving. And I really love that idea of the golden week, and taking the time to go do the one thing that you just want to dive into and explore.
And it’s like the idea of taking sabbatical in other professions, where you get to take that time off because you’ve earned the right, through your experience and your contributions to the company, to go explore and better yourself by taking on a learning in a different area.
David: A golden week to me seems like a really attractive reason to go work for a company, right? Like, how do you attract talent? We’ve got great tools and automation, and you’ve got this golden week where you can go invent the future. And how exciting is that?
Pam: Well, on the heels of the golden week, David, do you have any good news for us this week?
David: No good news. Sorry. We’re out this week. I’m kidding. I think the piece of good news that really struck me was something that I shared a little while ago on my LinkedIn, but was this idea of the language that we use, the things that we say can sometimes put us into a position that we don’t want to be in.
And particularly, when we think about a phrase like, “I’m not technical,” right, that is something that I think we should all stop saying. We may not believe ourselves to be technical, but then when you dig in and actually look at the skills that you have, you have incredible, you know, capabilities, incredible skills. And when you start out with something that’s negative like that, it puts yourself in an odd position with the people around you, the way that they see you. And so, maybe for the second half, if all of us can think about ourselves in a positive way and put a pause on something like “I’m not technical,” I think we’d see improvement in ourselves and those around us, and the way that they think about themselves by just changing our language.
Pam: Yeah, I have seen very much in the last week or so how much words matter. And I this, again, speaks back to something I said earlier, of like, you know, oh, fulfilling the promise of yourself. And when you open with a negative thing like, “I can’t do this,” “I’m not good at that,” I mean, that definitely takes things away.
And when you think about what we’ve heard in the market about cybersecurity skill shortage, and all of the different ways that unexpected backgrounds can contribute to this profession. I think, maybe you’re not technical, but I bet you can probably solve a problem in an innovative way that people that have been trained in computer science or very technical professions can’t. And I really think that it’s a lesson we all need to take to heart.
David: Yep, absolutely.
Pam: So, that’s all we have for this episode. Thanks to Emma Bickerstaffe and Jamie Cowper for joining us as guests.
David: Subscribe to the podcast on Apple Podcasts or SoundCloud, and make sure you never miss an episode. Thanks so much for listening.