SECURITY OPERATION CENTRE

What is SOC?

                   Security operations centers monitor and analyze activity on networks, servers, endpoints, databases, applications, websites, and other systems, looking for anomalous activity that could be indicative of a security incident or compromise. The SOC is responsible for ensuring that potential security incidents are correctly identified, analyzed, defended, investigated, and reported. SOC works with collaboration with People, Process and Technology. 

SOC Architecture

PEOPLE:

                 The best way to think of a SOC is as a centralized team of people who provide threat monitoring, investigation, and response. Larger SOCs employ a three-level analyst structure for handling security alerts generated by a security system or SIEM. 

Level 1 analysts are responsible for real-time monitoring of security alerts, doing triage on them, and deciding whether an alert is serious enough to be escalated to a Level 2 analyst. Level 1 analysts set rules for filtering out noise and determining which alerts get bubbled up to Level 2 analysts.

Level 2 are responsible for drilling down into the alerts they receive from Level 1 and correlating them with other information to see if a security incident might have occurred and determine the appropriate responses. As part of this exercise, they try to understand the potential impact of the security incident on enterprise assets and help guide incident response.

Level 3 analysts are seasoned security experts whose primary responsibilities are to proactively look for threats on the network and snuff them out rather than waiting on alerts before initiating action, and to work with the Level 1 and 2 teams when the likelihood of a threat has emerged. 

Multiple roles with different background, skills, pay levels, personalities

PROCESS:

              Before standing up a SOC capability, an organization needs to have a clear idea of existing capabilities, the right size for the effort, and whether the capability can be delivered internally or requires a service provider. 

               Quality SOC centers and processes are all about flow. Processes require extreme standardization of actions to make sure nothing is omitted. In my experience, creating repeatable incident management workflows and processes ensure that team members will function effectively as a cohesive unit when escalating an alert from Tier 1 to Tier 3. Based on the standardization of these workflows, resources can then be allocated very effectively.

TECHNOLOGY:

                 Core technologies such as SIEM having multiple solutions like data (raw log/packets) collection, aggregation, normalization, detection, and analytics is a secret of the effectiveness of SOC. For perfect Monitoring, SIEM (Security Information and Event Management) is all about one technology used in SOC. SIEM collects raw logs from multiple log sources like desktop, laptop, mobiles, servers, network as well as from Security devices convert it into logical security events and populate on SIEM console for further process of raising Security incidents. Based on defined correlation rule SIEM triggers the events. SOC consists of SIEM tools like Qradar, ArcSight, LogRhythm, Splunk and many more. every SIEM tool Detects threats and generate Security Alert in order to mitigate them. 

SIEM: Qradar and Logrhythm

Incident Response Process:

Incident Response Process

The Incident Response Process consist of Six Phases as mentioned below :

1. Detection
2. Analysis
3. Containment
4. Eradication
5. Recovery
6. Post-Incident Activities

Detection Phase:

                    In Detection Phase it identifies a Security Event that is the result of a potential exploitation of a Security Vulnerability or a Security Weakness. Even if Personnel are not sure whether a Security Event is an actual Security Incident they are still required to report it as provided herein, as it is better to be cautious than to be compromised. The Following situations should be considered for Security Event reporting:

• Ineffective security controls;
• Breach of information integrity, confidentiality or availability expectations;
• Human errors;
• Non–compliance with policies or standards;
• Breaches of physical security arrangements;
• Uncontrolled systems changes;
• Malfunctions of software or hardware;
• Access violations.

Analysis Phase:

                  In this phase the SOC team determines whether or not a Security Event is an actual Security Incident? The type of Security Incident is based on the nature of the event. If Malware is Detected, then via two approaches it can be Analysed like Static malware Analysis and Behavioral Malware Analysis. few things to be noted for analysis like source IP, destination IP, source port, destination port, severity, event count, log source and signature.  

                       Analyse Phase used to determine the root cause of the Security Event and determine under which group it should be Categorized. After Analyzing malware it can be categorized under common Event names, Example types are listed as follows:

• Data exposure.
• Unauthorized access.
• Distributed Denial of Service/ Denial of Service (DDoS/DoS).
• Malicious code.
• Improper usage.
• Scans/Probes/Attempted access.

Very important concept of Analysis Phase that it Defines Severity Level and Potential Impact.

Containment Phase: 

                        In this phase it mitigates the root cause of the Security Incident to prevent further damage or exposure. This phase attempts to limit the impact of a Security Incident prior to an eradication and recovery event. following steps to be taken in containment phase: 

• Secure the physical and network perimeter.
• Shutting down a system 
• disconnecting it from the network, and/or disabling certain functions or services.
• Connect through a trusted connection and retrieve any volatile data from the affected system.
• Appropriateness of backing the system up and determine the relative integrity of Data
• Change the password(s) to the affected system(s). Personnel, as appropriate, are to be notified of the password change.
• Determine whether it is safe to continue operations with the affected system(s).
• Limit the Impact of Incident

Eradication Phase: 

                    The Eradication Phase is the phase where vulnerabilities causing the Security Incident, and any associated compromises, are removed from the environment.  following steps should be taken to remove threat from environment: 

• Determine the symptoms and cause related to the affected systems.
• Rebuilding Operating System.
• Strengthen the controls surrounding the affected systems.
• If additional issues or symptoms are identified, take appropriate preventative measures to eliminate or minimize potential future compromises.
• Run Antivirus Software.
• Update the Incident Record with the information learned from the vulnerability assessment, including the cause, symptoms, and method used to fix the problem with the affected systems.
• Uninstalling Infected Software.
• If necessary, escalate to higher levels of support to enhance capabilities, resources, or time-to-eradication.
• Remove threat from Environment.
• Clean Up the System.
• Replace Hard disk if required.
• Reconstruct the Network.
• Eliminate components of the Security Incident. This may include deleting malware, disabling breached user accounts, etc.

Recovery Phase: 

                   In this phase restore the affected systems to operation after the resulting security Threats in our network. Although the specific actions taken during the Recovery Phase can vary depending on the identified Security Incident, the standard process to accomplish this is as follows:

• Installing patches.
• Rebuilding systems.
• Changing passwords
• Service restoration as per policies plans
• system validation
• Testing system/Networks
• certifying that systems are operational
• Restoring systems from clean backups.
• Replacing affected files with clean versions.

Post Incident Review: 

                     In this phase, Reviews the complete incident response Cycle and overview the process/procedures used in all phases. After verification of a successful containment and eradication the following post-incident activities should be conducted:

• Was Personal Information compromised?
• Was subscriber data compromised?
• Were legal and/or contractual obligations invoked by the Security Incident?
• What is the organization’s strategy moving forward?
• Types of Security Incidents?
• Volumes of Security Incidents and malfunctions?
• Costs incurred during the Security Incidents?
• Overall reduction in time spent responding to Security Incidents?
• Reduction of impact of certain Security Incidents?
• Overall reduction of the occurrence of Security Incidents?
• Was there sufficient Preparation?
• Did Detection Occur in timely manner?
• Were communication conducted Clearly?
• What was the Cost of the incident?
• Did you have a Business Continuity Plan?
• How can we prevent it from happening again?
• Was the Approach right??

Stay Tuned....