SOC and CERT
Table of Contents
1. Lecture 19
- Class: Security Governance
- Topic: Incident Management
We’ll focus on two main organizations: SOC (Security Operation Center) and CERT.
2. SOCs
A security operation center is a third party, typically external (even if big companies have their own SoC), it supports other entities and organization in identifying, managing and remediate to security attacks. The SOC could be an external third party, or an internal segment of the organization, and it may provide also external services to other organizations.
It’s goal is to support companies when dealing with incidents: detecting, responding to threat and attacks before they have an impact on the business.
2.1. Services Provided
There are three services that every SoC provides:
- Log management (How to, what to, and manage the logs)
- Security monitoring and alerting
- Security incident management (mainly in the first stages)
There are also additional services that could be provided, they are instrumental for some costumers or internal SoCs:
- Security Operation Management
- Vulnerability Assessment
There are also advanced SoCs that contribute to the increment of situational awareness, investing in the production and implementation of tools:
- Service Security assessment
- Security Analytics from data collected by SIEM
- Threat intelligence (overlapping to CERTs)
2.2. Building Blocks of a SoC
A SoC is composed by a Triad of Security Operations: People, Process, and Technology. The technology is both the starting and the end point, it is the base of the analysis, but also the mean to achieve it’s goal.
The selection of the technology has to be done keeping in mind the people that will use that technology, and that will support the analysis. At the end there is always the analyst that it’s own expertise will come up with a solution.
A technology that no one is able to use, is useless, on the other hand, skilled people must be trained to be capable of using a particular technology and understand it well.
Most of the tools used inside the SoC, may be customized and may be fed with different input data.
The processes are the elements that explain how the things are done, and will support and interconnect the people involved in the SoC with the technology: how a security operator is using a particular technology for doing what. The three elements can’t be considered one independent with the others.
2.3. Organization of the SoC
The picture represent the organization hierarchy of a SoC. In general in every security management process is important to identify roles and responsibility know to everybody. If people knows how to do their stuff, they will do it more carefully.
Typically the SoC is structured in levels:
- Analysts (frontlines), those that collect alarms from the system. Their task is try to identify which are the signs of possible attacks, perform the Triage, look for vulnerabilities (level of severity) and try to interact with the tier 2 personnel that is in charge of the concrete management. Is more a functional collaboration than a hierarchy.
- Hunters, provide input to the incident respond by analyzing contextual elements (TI, Vulnerability Analysis, Malware Analysis, and Network Analysis). They are very skilled people with an high specialized domain
- The SoC Manager, is the strategical figures, that defines procedures of interaction and establish the role and responsibilities.
The problem is that this structure is costly, so when is needed to have a SoC?
- In presence of critical or sensitive data or processes (regulatory and business)
- When there is a growing trend of the company and an internal information security function can no longer keep up.
- There is the need to equip themselves with “pushed” monitoring and technical response capacities to information security events.
Keeping in mind this three directions, is possible to know if it viable to invest into the creation of a SoC.
3. CERTs
A computer emergency response team is a group of experts who respond to cybersecurity incidents
It is a group of experts that support an organization, it is always an external company, and it gives advice on how to prevent, mitigate and recover from an incident to different organizations.
The first CERT was born in 1989, and it is hosted by Carnegie-Mellon University, USA. It was composed by academic people, with the goal of study all the background behind an incident: review and understand the dynamics of an incident, and acquiring the information in order to use them internally. It is still one of the reference points in the US. Today there exists different national CERTs.
The main functions provided by CERTs are:
- Providing preventive services
- Providing security bullettins
- Training
- Providing management of security services
They investigate how the incident took place, the sequence of exploits that the attacker followed, provide interesting information behind qualitative aspects of the attack, linking a specific attack with a possible source; and they also investigate for the best type of protection to implement.
CERTs also provide security bulletins in order to contribute in the identification of possible threats and threat sources. Also they provide training, that is fundamental in some domain (healthcare, transportation, telco), and in particular there exists specific CERTs for specific domains. In italy CERTs are organized in a hierarchical structure.
The management of security services is a function that is provided in overlap with a SOC, depending on the specific mandate of the CERT there is a certain degree of freedom (from managing directly the incident, to just providing directions).
The NIS directive is a european directive that regulate how critical infrastructures must interact with CERTs. Every member state must identify the essential operator services, and for those operators several constraints for incident notification, and deadline are in place. In Italy the domain are six: healthcare, energy, transportation, water, …, ….
3.1. CSIRT
It is a reformulation of the CERT acronym, currently CERT and CSIRT are used as synonyms
A capability set up for the purpose of assisting in responding to computer security-related incidents. Also called Computer Incident Response Team or COmputer Incident Response Center, Computer Incident Response Capability.
3.2. Building a successful CERT/CSIRT
Let’s investigate which are the bullet points of a good CERT.
- Mission. In this case there could be CERTs working a national, or super-national level (hierarchy); there may be domain specific CERTs, and the public of interest is specified inside the definition of its mission.
- Constituency. It represent who are the people, or the organizations, involved in the activities provided by the CERT. It is the set of clients of the CERT.
- Responsibility. What the CERT is supposed to do with respect to its client, which are the services offered.
- Mandate. The power of the CERT, and where it’s mandate stops.
- Organizational framework. There exists many different workflows that can be used to manage the organizations, and share the information.
- Available Services. The services that the CERT is going to offer to its clients.
3.2.1. Responsibility
There are some thing that we need to identify to trace the boundaries of the CERT activities.
Which type of incidents must be handled by the CERT and with what priorities? Not all the incidents notified by the CERT are handled by the CERT, some of them are mitigated by the organization, while the CERT simply observes law compliance. For other types of incidents, the CERT will take an active role on the resolution of the incident itself. The CERT will handle only incidents with a given level of severity.
Must the CERT keep track of the incident resolution, and, in that case close it? Or is it sufficient to notify constituents? Given that the CERT can’t handle everything that is happening inside it’s domain, it is important to define the role of the CERT with respect to the close of an incident. In some cases it will just wait for a notification of incident resolution, in other cases it will close the incident directly.
Is the CERT obliged to actively solve an incident, or it should notify and give advice? For some incidents there is an intermediate steps that is represented by a cooperation mechanism between the CERT and the organization: the CERT will give active suggestions to the organization, without acting directly.
Must the CERT escalate incidents when they do not get solved quickly enough and, if so, when and what must be escalated? Suppose that, after a notification of an incident, the CERT gives back advice on how to handle the incident, but the victim company does not follow the advice, the CERT may escalate, and from contacting the operational part, contacts the tactical level. Or It can just take the lead and close the incident actively. In some cases this kind of escalation can be done, or not.
Must the CERT inform specific entities about specific incidents? If the incident was caused by negligence of an employee the CERT can or not inform the company of the source of the incident.
Think through the CERTs responsibilities by examining specific incidents. Were the responsibilities clear enough? Can them be improved? The roles of responsibilities of the CERT must be improved continuously, in order to provide a better service, avoid confusing situations.
3.3. CERT Mandate
We have to clarify and better express the final mandate of the CERT.
Does the CERT only give advice to its constituents, or can it also expect them to react in some way? We have to decide if the CERT follows a more Peer to Peer approach, or a more Master Slave, approach in which the CERT gives advice that must be followed. For example a National CERT gives suggestions that must be implemented.
Can the CERT give deadlines to its constituents to solve incidents? Also in this case it depends on the type of CERT and regulations.
Can the CERT just provide co-ordination and advice regarding an incident, or can it also actively gather data in constituents’ computers, possibly do forensics? Again they are two completely different ways of supporting an organization, with different obligations. Must of the time there is and intermediary approach, in which the CERT works with the data in a forensics fashion, to perform correlation between different incidents, and learn if there is a common attack pattern, to give informed advice.
Think through the CERT’s mandate by examining specific incidents. Is the mandate well defined? Where can it be improved or clarified? The last point it’s related to the possible errors, and all the processes that can be improved. In this domain it’s improving is fundamental given the fact that security, and mitigation advice are given by the CERT.
3.4. Organizational Framework
The governance aspect is fundamental, the design, and organization of the processes must be done correctly in order to provide a good service. The mechanism of cooperation, escalation mechanism, relationship with CISO and CIO, and relationship with Crisis management inside organization must be clearly defined.
Having multiple escalation points and means of interaction is the best way to avoid to be blocked during an incident.
Identify which are the CISO and the CIO inside the organization and how they have to interact with the CERT. ALso is the CERT obliged to interact with them, or is simply an interaction pattern regulated by third parties?
Inside the organizations, typically in CI, there is a Crisis management department, also in this case it is important do define how the interaction will take place.
3.5. Services
The services of a CERT are divided in three classes: reactive, proactive and security quality management services.
The Proactive services are offered not just during an incident, but continuously in time, and are useful from a prevention perspective. They are quite useful during the risk management phase (announcements and technology watch), giving useful information during risk evaluation (revise dynamically the evaluation of the risks, reduce availability of services, stop additional services, put defensive barriers).
Considering the configuration and maintenance of security tools, applications and infrastructure the CERT will announce that some miss-configuration is present in security appliances to its constituents to let them fix it. Also it can help during the configuration of IDS and how to monitor the environment in an efficient way.
In the last class the CERT supports processes that should already be implemented in the company, and support its constituents doing difficult tasks like the risk analysis, recovery plan and training. Awareness is needed to take good decisions, so in the cybersecurity domain is difficult to create a global awareness given that there are different level at which the information are collected (form low level to high level). The CERT enables different organizations to compare their level of awareness to the average of the other constituents. There are different questionnaires provided by the NIST to compute awareness. At the end Certification, the european Cybersecurity Act, the emphasis in on the certification, people are becoming skeptical of the security of IT systems, so security certification are viewed as a way to increase the trust that people have on digitalization.
The problem is that: how to certify a software in a reliable way? In particular in modern software engineering there are multiple versions of the same software provided to the public.
3.6. CERT Roles
There are different professional figures, ranging from very technical people to managers. Some figures are mandatory, other are optional.
3.6.1. Mandatory roles.
- Duty officer. Has to take care of all in-coming requests as carry out periodic or ad hoc activities dedicated to the role. It is the first figure found when entering inside a CERT
- Triage officer. Has to deal with all the incidents notification, and their classification, also he/she needs to define if the incident must be managed by the CERT itself, or just inform that the incident is not under the CERT’s responsibility. He/She must be informed about the newest attack vectors, patterns, vulnerabilities and so on.
- Incident Handler. He/She coordinates the activities of the incident handling team, he/she is in charge of interacting with the organization during the incident handling.
- Incident Manager. He/She coordinates the team, and is the person that schedules the incidents to the team, and coordinate the Incident Handlers.
3.6.2. Optional Roles
The following roles are optional. Like the Public relations officer, legal officer, team manager, and hotline operator.
3.7. IM workflow
In this example, the IM workflow is divided in three stages, the CERT has the mandate to take direct actions, and concretely works during the problem resolution.
(Image from here) Phase 2 and 3 are related to the Incident Management process.
3.8. Relationships between SOC and CERT
SOCs and CERTs overlap in the incident management phase, but the CERT works over all the phases of the Incident Management process, on the other hand, the SOC activities are collateral to the Incident Management process, in fact they provide tools, mechanisms and action with the purpose of preventing an incident, on a different level:
- CERT generate info that can be used during prevention. (Informative side)
- SOC gives the instrument that can be used to implement prevention. (Support with technology)
That’s because SOCs and CERTs work together: they complement each other (input and tools for the analysis).
