CS Security Operations
A SOC (“Security Operations Center”) is frequently where security operations are housed. Words are used interchangeably.
Generally speaking, the SOC’s job is to identify environmental concerns and prevent them from becoming costly issues.
SIEM ("Security Information Event Management")
The majority of systems generate logs, many of which provide crucial security data.
An event is just any observation that we can identify from network logs and data, such as:
- Users logging in
- Attacks observed in the network
- Transactions within applications
An event is something unfavorable that we think will affect our company. It could be a real threat or the possibility that one will materialize. The SOC should make every effort to ascertain which occurrences can be linked to real issues that require attention.
The SIEM analyzes alarms based on logs from various network sensors and monitors, each of which may generate warnings that require the SOC’s attention. In order to identify an alert, the SIEM may additionally attempt to correlate several events.
Events from the following domains can usually be examined by SIEMs:
- Network
- Host
- Applications
The most common events come from the network, but they are also the least valuable because they don’t provide the full context of what transpired. The network usually provides information about who is interacting when, where, and over which protocols, but it does not provide the specifics of what transpired, with whom, or why.
More details about what truly occurred and to whom are provided by host events. Problems like encryption are no longer muddled, and more insight is acquired into what’s happening. A considerable deal of information regarding what occurs on the hosts themselves, as opposed to just the network, is added to many SIEMs.
It is usually from application events that the SOC can gain the most insight into what is happening. Details regarding the application’s performance and user behavior are provided by these events, which also include information about the Triple A, or AAA (“Authentication, Authorization, and Account”).
Since support is frequently not provided “out-of-the-box,” it usually takes work from the SOC Team to enable a SIEM to comprehend events from applications. Numerous applications are exclusive to a company, and the SIEM is unaware of the data that these applications transmit.
SOC Staffing
The staffing of a SOC varies widely depending on the needs and organizational structure. We briefly examine the typical roles that are involved in running a SOC in this section. A summary of possible positions:
The department head is assigned a role, just like in most other structured teams. The strategy and techniques used to counter threats to the organization are decided by the SOC Chief.
The SOC Architect bears the responsibility of guaranteeing that the systems, platforms, and overall architecture are able to provide the necessary resources for team members to carry out their tasks. A SOC architect guarantees that incoming data complies with platform specifications and aids in the development of correlation rules across several data points.
The development and upkeep of procedures, or playbooks, is the responsibility of the analyst lead in order to guarantee that analysts can locate the data required to conclude on alerts and possible issues.
Level 1 Analysts serve as the first responders to alerts. Their duty is, within their capabilities, to conclude alerts and forward any troubles to a higher level analyst.
Level 2 Analysts are distinguished by having more experience and technical knowledge. They should also ensure any troubles in resolving alerts are forwarded to the Analyst Lead to aid the continuous improvement of the SOC. The Level 2, together with the Analyst Lead, escalates incidents to the Incident Response Team.
The IRT (“Incident Response Team”) is a natural extension to the SOC Team. The IRT team is deployed to remediate and solve the issues impacting the organization.
Ideally, penetration testers assist the defense as well. Penetration testers can assist with root cause analysis and comprehending how break-ins transpire because of their in-depth grasp of attacker tactics. Combining attack and defensive teams is known as “purple teaming” and is regarded as a best-practice procedure.
Escalation Chains
Certain alarms necessitate quick action. It is crucial that the SOC has a defined procedure for who to call in case of certain situations. Different business units may experience incidents, thus the SOC needs to be aware of who to call, when to contact them, and which communication channels to use.
An illustration of an escalation chain for a problem affecting a single division within a company is:
- Create an Incident in the appointed Incident Tracking System, assigning it to correct department or person(s)
- If no direct action happens from department/person(s): send SMS and Email to primary contact
- If still no direct action: phone call primary contact
- If still no direct action: call secondary contact
Classification of Incidents
Events ought to be categorized based on their:
- Category
- Criticality
- Sensitivity
The SOC may take different actions to address the problem at hand depending on the incident’s classification and attribution.
The type of incident will dictate the appropriate course of action. There are numerous types of incidents, and it’s critical that the SOC comprehends the implications of each sort of incident for the company. The following is a list of sample incidents:
- Inside Hacking
- Malware on Client workstation
- Worm spreading across the network
- Distributed Denial of Service Attack
- Leaked Credentials
The number of affected systems, the possible consequences of not halting the incident, the systems involved, and many other factors are taken into consideration when determining how critical an incident is. To ensure that the event is closed appropriately, the SOC must be able to accurately assess the criticality. The criticality of an occurrence dictates how quickly it should be handled.
Can the team wait until tomorrow to respond to the issue, or should they do so right away?
The person who should be informed about the situation depends on sensitivity. There are certain instances that call for utmost caution.
SOAR ("Security Orchestration, Automation and Response")
Automation is essential for a contemporary SOC to be able to react quickly enough to stop the advances of threat actors. The SOC should have the capability to automatically coordinate responses to threats in the environment in order to expedite the response time to incidents.
By using actionable data, the SOC can help mitigate and halt risks that are emerging more quickly than in the past thanks to the SOAR strategy. In conventional settings, an attacker must wait very little time after compromise to expand to nearby systems. In contrast, organizations usually take a very long time to identify risks that have made their way into their environment. SOAR aims to assist in resolving this.
To aid with danger remediation and reconstruction, SOAR incorporates ideas like “Infrastructure as Code,” or IAC. SDN (“Software Defined Networking”) to facilitate easier and more fluid access control, among other benefits.
What to monitor?
Events can be recorded on a wide variety of devices, but how do we choose which ones to record and keep an eye on? The best quality logs are what we are looking for. To promptly stop the threat actors in our networks, we need high fidelity logs that are both relevant and identifiable. Additionally, we want to make it difficult for attackers to disable the notifications that we set up.
It becomes clear where we should concentrate if we examine various strategies for apprehending assailants. This is a list of potential signs that we may use to identify potential attackers, along with an estimate of how difficult it would be for them to change.
| Indicator | Difficulty to change |
|---|---|
| File checksums and hashes | Very Easy |
| IP Addresses | Easy |
| Domain Names | Simple |
| Network and Host Artifacts | Annoying |
| Tools | Challenging |
| Tactics, Techniques and Procedures | Hard |
File hashes and checksums can be used to recognize known malware or attacker tools. Because the code in these signatures can be encoded and modified in a variety of ways, causing the hashes and checksums to fluctuate, attackers believe that changing them is simple.
It is also simple to modify IP addresses. Attackers can use compromised hosts’ IP addresses or just use addresses from the myriad cloud and VPS (“Virtual Private Server”) providers.
Attackers can also change domain names with relative ease. A hacked system can be set up by an attacker to utilize a DGA (“Domain Generation Algorithm”), which changes the DNS name on a regular basis. The hacked system utilizes a single name for a week, but the name automatically changes the following week.
Changing the network and host artifacts annoys attackers more because it requires more adjustments. The SOC will be able to identify signatures from its utilities, such as the presence or absence of a user agent.
Attackers find it difficult and harder to modify the tools. Not the tool hashes, but the how the tools act and function throughout an assault. Tools will load libraries, leave traces in logs, and do other things that we can keep an eye on to spot these irregularities.
Attackers will have an even tougher time achieving their goals if the defense can recognize the tactics, techniques, and procedures used by threat actors. Defenders can benefit from this, for instance, if we are aware that the threat actor frequently uses spear-phishing and subsequently pivots to other victim systems to spread peer-to-peer. Defenders can begin putting up obstacles to prevent peer-to-peer networking and concentrate training on employees who are susceptible to spear-phishing.
