Policies and procedures of a SOC
Following up on the topic we started last week: "6 elements to consider when implementing a SOC", today we are going to take a closer look at the second element, which refers to the policies and procedures of a SOC.
Although the SOC is a stand-alone center, it must be integrated with existing IT systems, policies, and procedures. Regardless of the functions of the employees assigned to work in the SOC, they must proceed and be governed, in their activities, according to the manual of policies and procedures established by the organization.
Defining what a security policy really and effectively is, we must point out that it refers to a high-level statement of intent that covers the safeguarding of information systems and provides the basis for assigning and delimiting responsibilities for the various technical and organizational actions required
The policies and procedures set out in the SOC are important to support and specify a security architecture that provides the functions of authentication, authorization, and logging of activities.
We can categorize SOC policies into general policies, which should define, for example, who is the owner of the incident management procedure, who should be responsible for ensuring its continuous improvement and authorizing any changes to it, among others; and specific policies, such as the ones explained below:
The event detection policy: Here it is possible to specify who is responsible for this activity, who can detect events, and through which detection channel.
This policy also includes the classification of events, which must be defined with their category once they are declared as incidents.
Event logging policy: In this part, those responsible for this activity are mentioned, for example, who monitors and evaluates the events, and in case it does not correspond to a security incident, discards it.
Information gathering policy: We must define who is responsible for this activity, who is in charge of gathering the necessary information for evaluating the possible security incident, and establish the communication channels through which it will be reported.
Event evaluation policy: Once the person responsible for the activity has been established, who determines whether the event corresponds to a confirmed security incident or a false positive, he/she must propose actions to contain and deal with the incident.
This policy should define the classification of incidents according to severity and priority once the category and type of incident have been identified. The severity of the incident is evaluated according to the impact on the affected resources, and the priority refers to the speed with which the incident must be dealt with given the potential technical effects of the incident.
In some cases, the general information security policy can be used to include a clause on incident management, and within this, create the Incident Response Plan (IRP), which will be documented with its 6 phases: preparation, identification, containment, eradication, recovery, and lessons learned.
The idea is to document processes to manage various types of incidents, whether they are related to phishing, malware infections, BYOD incidents, unauthorized website tampering, denial of service attacks, among others.
The term "procedure" is defined as the activity organized to reach the execution of a certain process. But if we refer specifically to the incident management procedure, it aims to resolve, as quickly and efficiently as possible, any incident that causes an interruption in service. It can be initiated by requests generated by users, being notified by e-mail, reported via help desk tickets, or by the SIEM event correlation platform.
In these cases, the corresponding triage is carried out, i.e., it is evaluated whether it corresponds to a false positive or a potential incident. The events must be evaluated by the SOC operator (Tier1/L1) and the incidents must be escalated to the security analyst (Tier2/L2), who with the help of the personnel involved must give continuity to the service with a minimum of negative effect for the organization in general.
In short, the SOC needs to document and communicate effective processes, and likewise, it needs to implement change control mechanisms to be able to quickly update processes when opportunities for improvement arise. Thus, for all the above, we can ensure that we are taking the SOC along the path of its maturity process.
Hi! I am Kendra Mazara
Senior Information Security Specialist | MBA | Cofounder MujeresTICs RD | Speaker | LinkedIn Learning Instructor
