In the last post, we took a look at the logistical and human issues surrounding the setup of a new security operations center (SOC).
And while having a mission, the right people, and a physically secure location are all vital to the success of a new SOC, there are many more things to consider before you can jump in and get started.
In this post, we’re going to take a closer look at the technical requirements of building a SOC, including software, hardware, communications, project tracking, and more.
So let’s get right to it…
Phishing is the single most significant threat to almost every industry. Find out how the phishing landscape changed in the past year, and how that could impact your organization.
Start with the Mundane
In an ideal world, selecting the right technology for your SOC would be simple. Perhaps there would be three or four ‘SOC technology’ vendors, and you’d simply choose the one that was right for you.
Unfortunately, the real world is far messier.
For a start, there is no such thing as ‘standard’ SOC hardware or software. In fact, SOCs located within two organizations of the same size in the same industry could have drastically different needs.
Why? Because your SOC’s technology needs are entirely mission dependent.
But before we get to all that, there are some technical considerations that apply to most (if not all) SOCs. And of those, perhaps the first to consider is network architecture.
As we explained last time, your SOC will be routinely handling the most sensitive data your organizations possesses, and you’ll be taking great pains to ensure no unauthorized personnel are able to gain physical access. With that in mind, it only makes sense to allocate the necessary resources to ensure no unauthorized digital access is allowed either.
For the most part, SOCs opt to utilize network segmentation techniques to completely separate their digital domains from the rest of the organization. In practice, that means no other users will be able to (accidentally or otherwise) access the SOC’s data. It also means that if a user account is compromised by a threat actor, it can’t be used to access the organization’s most sensitive data.
Another prominent factor is the issue of user access controls. For most users, it makes sense to limit access to the Internet, as well as to areas of the organization’s internal network that aren’t needed for that role.
For a SOC analyst, though, unfettered access to the Internet is likely to be essential, particularly if they are investigating threat vectors. Once again, this is a clear argument in favor of network segmentation, as even the most expert users may occasionally make mistakes.
Once these concerns have been addressed, you’ll need to identify and implement a strong ticketing and case management system. In the past most SOCs opted to build their own, but these days the market for this type of solution is extremely mature, so for the most part it is quicker, easier, and cheaper to buy in an off-the-shelf solution than to develop one in-house. Naturally, make sure you invest the time and thought necessary to select the best solution for your particular needs, as your SOC will hopefully be working with it for years to come.
Finally, you’ll need to consider communications. As with any close-knit team, proper communication is paramount to the success of your SOC, as they will need to agree priorities, plan workloads, and discuss complex or ongoing issues/projects.
For the most part, technical teams have moved away from email, as lack of certainty around who to include in complex discussions can quickly result in highly confusing CC chains and other related issues. More popular options include messaging applications such as Slack, Pidgeon, and Skype for Business, which enable multiple analysts to discuss an issue simultaneously in such a way that the rest for the team can understand without having to trawl through complex email chains.
Now clearly, these types of considerations are far from ‘sexy’. They could, in fact, be considered extremely boring.
But in reality, getting these basics right is essential to the long term health and operation of both your SOC and your organization as a whole.
Software: One Size Doesn’t Fit All
Once the basics are out of the way, it’s time to consider the systems and applications your SOC analysts will be using on a daily basis.
But this is where standardization goes out the window. Depending on what your SOC’s mission is, your specific technological requirements could vary dramatically from those of close competitors within your industry.
For this reason, in many cases SOCs opt to develop their own home-grown technologies, which perform the precise functions they require. Not only does this result in a solution which precisely matches the organization’s needs, it also removes the need to allow an external vendor any form of access to your SOC’s physical location and sensitive data.
Of course, on the flip side, developing this type of software takes time, skilled personnel, and (consequently) money.
But, to our mind, there’s just no way around this. Some out of the box technologies such as threat intelligence platforms can perform a valuable function within a SOC, but for the most part your SOC’s mission is likely to be such that at least some level of development is essential.
Hardware: Not Just for Show
If you’ve ever visited a functional SOC, it’s hard not to be impressed by the physical kit on display. With multiple monitors at every work station, huge screens on every wall displaying complex analytics, and analysts diligently going about their duties, it resembles nothing so much as a secret government military bunker.
And while it’s important not to be carried away (this isn’t a vanity project, after all) there really is a need for most of this hardware.
For instance, depending on their precise role, most SOC analysts really do need dual- or triple-head monitors in order to work efficiently. They also most likely need a machine that is specifically theirs, rather than being shared between members of the SOC, as they may periodically be working with highly sensitive datasets, analyzing threats, and working with specific software configurations.
But for all that, don’t assume you’ll need a separate physical workstation for each analyst. If, for example, you have 15 analysts, but only a maximum of six will be on site at any given time, a common approach would be to install six physical workstations, but issue each analyst with their own laptop. With this approach, on arriving at the SOC, an analyst can simply walk up to a free workstation and connect their laptop to a docking station which provides access to the SOC network, visual displays, audio, and so on.
Of course, your approach does need to be carefully considered. Allowing analysts to take sensitive data offsite is likely not an option, so instead you’ll want to make use of other technologies such as virtualized environments to ensure all data is stored centrally.
Once you have your workstations in place, you’ll need to consider how you’ll communicate vital information to the team as a whole. In most cases, this is done by placing large monitors or projector screens on one or more of the SOC’s walls. And while you could be forgiven for assuming the massive screens implemented by most SOCs are mostly there to look good, they actually perform several vital functions.
First, they display vital data, such as potential threats, open incidents, and real-time load statistics (volume, age, severity, and so on). This helps SOC analysts to identify the most pressing concerns at any given point of time, and give attention to the top priority. In addition, this constantly updating feed helps the team stay on top of the current situation, and monitor their workload.
More importantly, though, these ‘situational awareness displays’ (also known as heads-up displays or HUDs) should tell analysts “Here’s what to do next.”
At certain times, particularly when things are quiet, analysts will have the opportunity to perform proactive work to further the security of your organization. At other times, though, the team will need to rally together to cover incoming requests, investigate and resolve existing tickets, or respond to a specific incident.
Now, if you really want to impress people, it’s fine to install huge fancy-looking monitors. But whatever you decide to use, it must also further the team’s mission. Above all else, your HUDs (in combination with the team’s internal communication channels) should facilitate the processes described above.
Nobody Said it would be Easy
If you’ve made it this far through the series, you should be starting to realize that building a functional SOC is far from easy (or cheap). But if your organization takes security seriously, it may well be that the time and resource investment really is worthwhile.
In the third and final installment of this article series, we’re going to take an in-depth look at the financial implications of building and operating a SOC, as well as how to monitor and maintain your SOC over the long term.
But for now, if you’d like to learn more about how a high quality threat intelligence source of threat intelligence can aid in the setup and operation of your security operations, get in touch today.
*** This is a Security Bloggers Network syndicated blog from The PhishLabs Blog authored by Johnny Calhoun, VP Client Operations. Read the original post at: https://info.phishlabs.com/blog/how-to-build-a-powerful-security-operations-center-part-2-technical-requirements