How to build a SOC

— Jakub Syta —

The topic of building a Security Operations Centre (in short: SOC) has been lately one of the most popular topics on conferences and business meetings. Practically every reputable company starts building its SOC at this point or has just announced that a team dedicated to building one was established. It reminds me of some other trendy topics you might have seen around the world some time ago. About 10 years ago, every respectable company was “deploying” IDS/IPS solutions. “Deploying” said in quotes, because usually it turned out that those companies bought solutions, put them in the infrastructure, but nobody bothered with technical details such as their configuration or making sure that there was a person appointed to monitoring what those solutions were actually able to detect.

A few years ago, there was a massive fad for SIEM solutions. They were deployed in a number of companies. Practically everyone knew that SIEM was a must have. These are actually incredibly interesting solutions that make it possible to gather information coming from many different sources and to correlate it with one another. But again, when it came down to it, it turned out that SIEMs were there, but the number of sources to which they were connected was incredibly limited. In the final analysis, there were no people actually analysing SIEM data. So, SIEMs were deployed, but they were not used.

Right now, we have another strong fad – we’re building SOCs, we’re building solutions, and more companies are starting to show off. This is a very positive trend, but in the end it quite often turns out that these SOCs actually rely on the fact that those IT specialists who have always handled IT support at our company are actually doing exactly the same thing. They are always on call and if someone calls them and says that there is a problem, they start handling it, this time in a 24-hour mode. Who calls them or where the information about a serious incident that needs to be handled comes from is a secondary detail that is not worth dealing with at this point.

I would risk a statement that all of the mechanisms I have mentioned, that is, both IDS/IPS, SIEM and SOC, are solutions which are in fact indispensable in every company that cares about information security, but what is most important is that these solutions should actually be deployed and operational. And how do you know that this is the case? You can tell by asking a most mundane question, namely: “How is our cyber security? Who is attacking us today?” Why is this important? Because as you probably know, we are all being attacked on a daily basis and these attacks are fully automated. It is not that there are no incidents, a lot of companies simply do not monitor them and the answer to that question is usually: “actually, we don’t know”.

Sensors, IDSs, IPSs, SIEM solutions, and the SOC team itself are basically control mechanisms. For such a control mechanism to work well and bring the expected results, it should be well designed and effectively operated. What does it mean? First of all, this type of solutions should be properly configured. They should be maintained at all times with up-to-date rules and signatures to be able to monitor also equipment that has been recently added to our network. Such control mechanisms should be constantly maintained and monitored, i.e. someone should be looking out for possible attacks and problems in the organisation on an ongoing basis. If these things are not secured, then in fact those control mechanisms – that is, these security tools that we so laboriously deploy – often become harmful and begin to hinder the organisation. Why is that? First, they give a false sense of security. “We have more boxes in the server room now, we are safe” – is that true? Not really. They are harmful also because they often cost much more than they bring in actual value. If the solution is just there and gives out heat but nobody is actually using it, this is a typical sign of mismanagement. Another reason why I call such mechanisms harmful is that they accumulate evidence of failures to exercise due diligence. Please note how troublesome a situation may become when we analyse an incident or a break-in and it turns out that the automated systems have actually detected everything. Reconnaissance attempts have been detected, attack attempts have been detected, the entire course may even have been tracked by systems already in place within the organisation, but simply no one has responded to it in any way.

We will know whether the controls and safeguards are effective when the organisation encounters a problem. If someone says, “I call” and attacks us, then we will find out whether all those investments that were made were meant as a real, adequate response to a previously identified risk, or whether the aim was to make more tables in Excel glow in a beautiful green, but there’s no value from that. So here we have an approach of either really responding to the risk or just focusing on making sure that the minimum level of compliance is achieved. Don’t get me wrong, I am by no means opposed to compliance – that is, to all these compliance-related topics – but I would like to draw your attention to one thing. The entire compliance process is designed to ensure its minimum level – if it is not met, the organisation will face some sort of sanctions. This minimum is not necessarily adequate for the actual risks that affect each organisation. That is, when it comes down to it, if the organisation has a problem, it may turn out that the solutions we have are by far not enough. How can we verify whether our mechanisms are actually working? Run some simple attack simulation, make an urgent configuration change, verify the security of some key security-related component. If it turns out that our organisation can’t do that, then there’s something wrong with that effectiveness.

For security services to be effective, they should be permanently connected to the company’s operations, functioning in the environments in which we work every day. Here, a few such basic elements/phases should be noted. First of all, we have the part related to prevention, i.e. preparing procedures, rules, purchasing, deploying, configuring software or other solutions, which will cause that the organisation will be able to react, or will be able to protect itself against at least the simplest attacks. But in addition to these prevention mechanisms, it is very important to ensure monitoring, proper response and recovery from various types of adverse incidents. And those three actions – monitoring, response and remediation – are really the tasks of Security Operations Centre (SOC) teams.

Referring to the title of my presentation – “How to build a SOC?” – I have to tell you that this is really an easy thing to do. Make sure you have a properly educated team that follows cool, efficient procedures using the best technology in the world. And that is a very short recipe for building a SOC, and I hope you agree with me. Going a bit more into detail, we should look at what processes, technologies or competencies we should focus on. First of all – what is the main role of teams like SOC? It is to detect and respond to dangerous situations. In fact, we can distinguish six most typical cases of attacks or dangerous behaviours that happen in infrastructure: first of all, it is theft of information, installation of malicious software, modification of important elements of infrastructure (or information) or using infrastructure for dishonest purposes, i.e. in a manner different from that desired by its owner. SOC teams should also be prepared to respond to DDoS attacks or to detect and counteract situations such as abuse of authorisations by users. What are the most common difficulties that an organisation should prevent? First of all, it is a question of ensuring constant monitoring or constant operation. Please remember to make sure that someone monitors your security all the time, 24 hours a day, 7 days a week, 365 days a year. If we expect that someone to be a human being and not some kind of automatic machine which reacts to known signatures and we expect this level of protection, we need to assign the right team of people who are able to work on an ongoing basis – on weekends, at night or during the holiday leave and regardless of a sick leave. The next topic of interest is the provision of further lines of support. At what point should the problem be escalated? At what point should successive lines of support be notified? At what point should a press spokesman be notified? At what point should state authorities be informed? These types of issues should be prepared in advance for the organisation to respond accordingly. The most obvious process assurance issues are to provide a scenario for responding to the types of adverse incidents I’ve presented here. If something happens, the employee should, regardless of what time it is, respond in a prescribed way, always in accordance with their authorisations. I would also like to draw attention to one very important detail here – because SOC teams or other teams that monitor security are not always focusing exclusively on monitoring. Yes, monitoring is their basic task, but in cases that are predefined, in cases that are particularly dangerous, if there is some kind of active attack on an important infrastructure, then someone should also respond. In the most extreme case such a person should disconnect the company from the Internet or disconnect a piece of infrastructure. These are not decisions that can be made without a second thought, with no preparation and no prior arrangements, just because a company that provides security services has this kind of technical capability. I would further point out that these processes should ensure that the organisation is able to properly leverage the benefits that come with each technology that is deployed there.

And when it comes to technology, what technologies should really work in a SOC or in companies that are taking its security matters seriously? We should have a range of solutions prepared. There are a lot of them: antimalware solutions, solutions protecting against DDoS attacks, Endpoint Protection solutions, Security Baselines solutions, Cyber Threat Intelligence solutions, a number of different types of solutions that actually respond to some specifically identified risk. Whether this risk is crucial for the organisation or not, it should really result from the analysis that you will conduct. In any case, the amount of technology that is possible to use is quite impressive. Here I have listed the “big blocks”, but there may be many more. What I would like to draw your particular attention to is that all these technologies should really be collected in a central place. There are SIEM (Security Information and Event Management) systems and they gather information about all the bad things happening regarding cyber security. It is within these systems that correlations take place, i.e. linking of incidents that have occurred to various elements of the infrastructure and which are then, according to the defined scenarios, handled by SOC teams.

We have discussed processes, we have discussed technologies, and now we are coming to the biggest challenge yet, which is the personnel. Well, to have a SOC team and provide this type of service, first of all you need people. We need someone who will look at what all these soulless machines are spitting out, who will decide on the basis of their own experience whether this is already a problem or not, whether to escalate it or not, whether to react in one way or another. This kind of decisions shouldn’t be made by automatic machines. They should be made by someone who supervises technology operations. So, the most common difficulty with regard to building a whole SOC is to find the people. People who have experience, who have a desire to learn and who are curious about the world, who are learning all the time, because let’s remember that security is evolving and there are more and more attacks every day. They should be passionate about new technologies, cyber security issues, and most of all – they should be able to work in a team. It’s not about having a few supermen who can actually do everything “from a to z”, who are incredibly smart, intelligent, and can solve every possible problem. It’s not about building teams out of people like that, because there are no such people. Each person has his or her own specialisation, each person is good in his or her field, and it is only when this group of experts starts working as one that you begin to see any value in the fact that this type of team exists.

What roles should we think about if we want to build a SOC? Of course, first of all we have this first line – a group of people who analyse the security on an ongoing basis and can answer the question: “How is our cyber security?”. The second line – a group of people that handle the first escalation. These are the people who generally view a breach that has already occurred. They decide how serious this breach is and who maintain a relationship with the client and can inform them that “Dear Client, you’ve had a break-in.” The third line – professionals who do the advanced analysis and are able to figure out how the malware actually works and to identify what the incident actually looked like. But beyond those most obvious three lines, which all of you have probably heard about more than once, let’s also remember that you need a staff of people who deal with typical deployments and who handle the day-to-day configuration of the tools. Administrative support should be provided, because we should remember on which operating systems all these solutions function. There should be people who coordinate, ensure continuous operation and proper paths of escalation. Very often it turns out that you need to create your own tools, that even the best technologies that are out there do not fully meet the needs of each specific team. That’s why a team of developers also comes in handy, a team of people who develop new technologies catering specifically for an organisation’s needs or matching its profile. In addition to this, we work with experts that provide advanced services.

Speaking of people – there is another important issue that I have already touched on a bit: experience. Unfortunately, quite often it turns out that these SOC teams actually consist of two or three students who, in between classes or waiting for the next exam in the session, check the phone and hope that someone will call them. Are they really able to respond appropriately to difficult, advanced cases of attacks? I’m not talking about those attacks Adam mentioned during the previous presentation, but about a case of a normal, solid attack on the organisation. This hypothetical student is there just for the purpose of being there. In order for him to respond effectively, he should function according to processes and in a large team.

What I am showing you here on this slide are selected certificates from the team that I lead. Our people are experienced, certified, those people know a lot about their business. Here I would like to point out the details that you may not have noticed, but 14 of us decided to share our experience at this conference. 14 people showed no reluctance to talk about the topics they specialise in.

I mentioned professional services. Apart from these everyday issues related to managed services, i.e. continuous monitoring and in case something happens, there is a predefined reaction. In addition to this, the organisation should be able to ensure that security is in place. How can we expect an organisation to implement or provide security services if the organisation itself can’t do simple penetration testing or if it can’t analyse some malware that has actually attacked our clients at this point?

There is an increasing trend to say that SOC is a solution to all problems – “deploy SOC and you will be safe”. Well, it’s not quite like that. Of course, SOC comes in handy, but what’s really key to making our infrastructure secure is ensuring IT is doing its day-to-day job the way it should, that the solutions are properly configured, secured, and, of course, properly monitored. In such case a SOC team can monitor and keep a constant eye on whether security is ensured. Sooner or later, you will find that someone will attack the organisation and then again, this SOC team will be able to perform, they will be able to target such malware or hacker and get rid of the incident. And again, what is important here is that after such incidents, some conclusions should be made and it should be ensured that the organisation learns something, learns from this incident, hardens the infrastructure again and again this cycle will run its course.

SOC is another control mechanism, and I would like you to look at teams like SOC as another safeguard. We have firewalls, antivirus software, patching, SIEM solutions and we have SOC teams. This is another control mechanism that is really a response to a risk that goes more or less like this: “my organisation will not detect and/or be able to respond appropriately to a cyber attack”. In fact, at this point we have approached the most fundamental question – why build these teams at all and why monitor the security of our infrastructure at all times? There are two reasons. First, we are increasingly dependent on new technology – I assume none of you would be here today if your company could work and do business without computers. The second issue is that these attacks occur. Attacks happen on a daily basis, there are a lot of them, and in most cases they are automated. This kid of attack is relatively easy to detect, but if someone is unlucky enough to become a target, then they have to deal with it. They just have to, regardless of what time it is, because let’s remember that our IT specialists usually work between 8 a.m. and 4 p.m., or between 9 a.m. and 5 p.m., and hackers do not care about working hours at all. The hacker doesn’t care whether the organisation can protect itself. They don’t care what hours the IT team works. They don’t care whether you have money for security and whether this type of investment is on your budget. They don’t even care whether there is something to steal. They will attack you because you exist on the Internet – this may already be reason enough. And I would like to point out here that your inability to respond is not an excuse for not acting effectively, nor does it absolve you of responsibility.

One more thing – in the GDPR the word “effective” is repeated almost 60 times. If someone breaks into your infrastructure, does that prove your security is ineffective? Yes. Will this be grounds for consequences? I believe so. It really is time to start approaching security in a structured and responsible way.

The last question we should answer above all is whether teams like SOC should be deployed in-house, built organically, or is it worth buying it as a service? And here, too, the answer is not clear. First of all, we should consider the capabilities of our team. If we have a really large team of IT specialists who have impressive skills and who can independently counter attacks, develop software, monitor the infrastructure 24/7, then it might actually be worth building something like this ourselves. In other cases, it is better to deploy it as a service. If our organisation is under constant attack, meaning this exposure is extremely high, then maybe it’s about time to start addressing this issue in an effective manner. A very important issue – in fact the key issue when it comes to taking security-related decisions – is the question of our appetite for risk. Some organisations will be interested in compliance or the key issue for them will be the trend. For other organisations, the decision to create a SOC will be made in response to a specific identified risk and in those cases they should rather care whether such deployment is done well and effectively.

And to close my presentation: yesterday, when I was preparing for today’s lecture, my six-year-old son came up to me and asked what I was going to talk about. I told him and he looked at me puzzled and said: “Daddy, but that’s easy. You go to a store and you buy brand new socks there”. Ladies and gentlemen, what I have shown you on the previous few slides proves that creating a SOC is, indeed, easy: you have to have good processes, good technology and a good team. I have listed all the key elements of this procedure on the slides. Now, go and build your SOC.