It is no secret that interesting research results often arise at the intersection of areas of knowledge. That’s why you have probably heard about SOC, soc 2 certification cost, and Security Operations. In this case, one of these areas will definitely be security, and the result is a managed activity of the SOC. We will consider SOC as a classic bundle of people, processes, and technologies, that is, in the terminology of the domestic GOST, SOC is an automated system. It is possible to achieve our goals with the help of this system only if we manage it.
As managers, the last thing we want to do is influence each component of the system individually. It is much more interesting to get a system configured from the inside, performing its tasks with minimal participation. You can achieve this result from SOC by building processes.
Few people write about it. Processes are often confused with services. In addition to Cobit for Information Security from ISACA, the author has not come across any serious non-proprietary methodologies that can be used to build processes in the SOC. But Cobit will not be easy, and sometimes almost impossible, to “land” on the activities of a particular company.
The part of the process model in the SOC
Why do we need a process model at all? The key word is model. It is the easiest to work with, as it is visual, easy to change, and provides the ability to use a large number of tools. Mankind throughout its history has been working exclusively with models that reflect reality in some approximation.
UnderDefense explains that usually, we create a model of its work under the given conditions. No one has yet received a single bit, has not seen a single dashboard, and we will already be able to debug the work of a whole division within the company.
The most interesting thing is that even if no one developed the process model, the processes have not gone away. We just don’t know much about them. Simply put, a process is an activity. After all, analysts go to work, look at monitors, receive a salary, and regularly report on incidents with all sorts of statistics graphs. And why are they doing it? Do they do it well or badly? And if it’s bad, how can you make it better? Is the current SOC sufficient or perhaps excessive? Maybe it’s not needed at all, and it’s easier to give everything to MSSP or MDR. As a result, we can’t confidently answer almost any question, and business regularly allocates a budget for security, which sometimes needs to be justified.
SOC systemic weaknesses and ways to overcome them
The traditional SOC has certain systemic weaknesses, which can only be avoided by qualitatively changing the structure and components of the incident management process:
- Proportionately growing noise in events (Noisy Alerts), an increasing need for SOC capacity, and improving the quality of analytics and related investments.
- Distributed landscape and the resulting poor transparency of hybrid networks.
- Low level of automation, an acute need for an expert resource, leading to a potential shortage of staff.
Formulation of goals, objectives, and key parameters of the SOC
I would like to note that often when building a SOC, the first thing to do is to buy a SIEM system. This class of information security products is strongly associated with SOC, and often an equal sign is put between SIEM and SOC. And only after this acquisition, did the creators of the SOC in the organization begin to work out the specific goals and objectives of the system. Despite the vague results of this approach, it is in fact the most common in practice.
We would recommend slightly postponing the joyful moment of unpacking the box with the brand-new SIEM and starting with the study of the key parameters of the system being created: its functions, architecture, and tasks. This should be stated in writing, which will help the SOC architect better understand the issue and convey the “mission” and key parameters of the system to colleagues, management, and contractors. It would be good if this policy document was signed by the top management of the company.
IS, detection, and analysis of IS violations in real-time, response to incidents, as well as supplying all stakeholders in the company with information about the current level of IS.
The remaining tasks of the SOC can be considered auxiliary. Key SOC parameters include:
- organizational model of SOC;
- functions to be performed arising from tasks;
- level of authority: the authority of the SOC can vary from simple “advisers” (notification, provision of recommendations) to “special forces” (as part of the response to an incident, it is possible to configure equipment, change business processes, stop systems, etc.).
Separately, it is worth considering such SOCs that serve external organizations. For example, industry, within a group of companies, providing outsourcing services, etc. Contrary to expectations, the main approaches to building such SOCs are the same.
Defining key SOC processes and procedures
We identify over 40 core functions that a SOC can perform, from incident data collection to law enforcement engagement, from malware analysis to employee awareness. In fairness, it should be noted that in our practice we have not seen a SOC that successfully performs all these functions simultaneously. Probably, such systems do not exist at all.
As noted above, at the beginning of SOC construction, the “less but better” rule applies. It is worth concentrating on the key tasks facing the system being created and describing the processes that ensure their implementation. At a minimum, we need to collect, store, and process data from information security and IT systems, enable users to report suspicious activity, and investigate and respond to incidents.
The SOC team needs to have up-to-date information about the infrastructure it protects and effectively interact with colleagues from other departments: IT and information security services, HR, lawyers, system owners, etc. Without this, it is difficult to imagine the work of the SOC, therefore it is worth starting. Processes and procedures are best recorded on paper.
Summing it up
Some reactive protection tools can be automated, but the organization must know and understand its risks in terms of information security and have high-quality expertise. It is possible to provide external expertise by replacing the functional roles of SecOps with employees of UnderDefense. They also have experience in responding to suspected information security incidents submitted by a third-party SOC.
