SOCs typically revolve around watching/monitoring the Security Information & Event Management (SIEM) system as a single pane of glass for all of the organizations security events. The SIEM is programmed with rules, referred to as Use Cases, that if logs meet the conditions specified in the rules/use cases the SOC will get an alert. For many SIEM systems the alert is really just a dashboard indication that a rule/use case triggered or something is a higher threat level (i.e., Threat level 8-10 on a scale of 1-10). The SOC engineer then has to do some task to take care of the alert which include verifying if it is a false positive, and mitigating/responding to the cyber security issue if it isn't.
The problem is that in reality SIEMs generate a lot of alerts. In reality most SOCs are like below. If process XYZ takes 30 minutes, it is hard to keep up. The repetitive manual response patterns also lead to SOC burnout and turnover.
There are a few things that can be done to help with SOC issue. I recommend doing all of them.
SIEM Tuning
Tune down SIEM not to alert on events that have proven to not be security issues.
Tune up SIEM to alert on high fidelity events (i.e., "This event trigger is definitely an issue!")
Security Orchestration And Response (SOAR)
Security Orchestration And Response (SOAR) Overview
SOAR involves automating the steps of the response. These automated responses are typically called playbooks. Having the SOAR automate steps it can greatly improve SOCs in a number of ways. The SOC can handle more incidents with smaller staffs, and less burnout. The diagram below displays the response process automated with SOAR (gear) which allows the SOC analyst to spend his/her time focusing on deeper analysis.
There are many SOAR platforms on the market.
Swimlane
D3
Torq
Tines
Splunk (Phantom)
Palo Alto (Demisto)
Microsoft (Sentinel)
Siemplify (Google)
The Hive/Cortex (Open Source)
Term Low Code
SOAR Underpinnings - Process Automation
At its heart, SOAR is process automation. As with any process automation initiative, it won't be successful if the underlying process steps being automated are flawed or not understood.
Lookups are often referree to as "enrichments"
APIs
APIs are a mechanism where a system exposes data to other systems asking for the data. The API becomes a representation of data on the system or interactivity with that data. The query of the API is called the "API Call" and consists of.
The endpoint
root
path
The method
The headers
The data (or body)
The diagram below displays an API call from a users perspective. The root is www.test.com/api and the full path included the query parameters.
In actuality the API is more like the diagram below where a system is making the API call, and the return value from the API call is a JavaScript (JSON) object. the calling system has to interpret, analyze, and/or perform action on the returned JSON data.
JSON represents data in key : value pairs.
{
"Property1":"value1";
"Property2":"value2";
"Property3":"value3";
}
Example - Working with VirusTotal API
https://developers.virustotal.com/
web hooks
Email (Phishing) - SOAR
The below diagram displays Email (Phishing) analysis process steps for a SOC.
Emails come into the organization through the organizations email gateway, also known as Mail Transfer Agent (MTA). Most email gateways have fairly strong capabilities to block spam and phishing emails.
If the end-user finds the email is suspicious (You want users to report suspicious emails and not open them) your organization should have a portal or an easy way for the user to report the email as suspicious and submit it to the SOC for analysis.
The email analysis could involve looking at:
Email attachments (excel, pdf, etc) if there are any
Message header and message analysis
There are a couple of SOAR use cases that can come into play here.
Pass/Fail verdict on Suspicious email - SOAR Playbook
Automatically create suspicious email SOC ticket
Automatic email attachment anaysis (excel, pdf, etc)
Attachment run in sandbox
hash of attachment sent to Threat Intelligence (e.g., virustotal, etc)
Message Header Analysis
Message headers sent to Threat Intelligence (e.g., virustotal, etc)
Message body
Message body urls sent to Threat Intelligence (e.g., virustotal, etc)
Update ticket with verdict
If verdict fails
Delete email
Quarantine endpoint with EDR if email opened/executed
Find other matching emails
Update internal CTI
Update end-user of verdict
Who is trying to phish us? SOAR Playbook
Send quarantines/bad emails through analysis process:
Attachment to sandbox analysis
Attachment hash to CTI analysis process
Message header to CTI analysis process
Message body to CTI analysis process
Are there commonalities of attackers (e.g., APT groups, etc)
Did an endpoint exploit occur due to Phishing email? SOAR Playbook
Trace endpoint exploit back to email.
Analyze suspect root cause email.
Attachment to sandbox analysis
Attachment hash to CTI analysis process
Message header to CTI analysis process
Message body to CTI analysis process
End Point Analysis - SOAR
Endpoint Detection Response (EDR) alerting overview
EDRs are point security products. EDR deployments typically have agents on endpoints (workstations and servers). These agents are often controlled by a centralized management system (shown as "console" below). Depending on the capabilities of the systems deployed (EDR and SIEM), and deployment design there can be different types of deployments.
EDR data not sent to SIEM
EDR data sent to SIEM from endpoint agents
and/or
EDR data sent to SIEM from EDR database
A question then becomes, where does the SOC focus their attention? Do they watch the EDR console or the SIEM or both? An advantage of the EDR data being sent to the SIEM is that the EDR system could be configured not to just send generic logs to the SIEM, but actual EDR alerts. So, the SIEM is getting a high-fidelity alert from the EDR system. Unfortunately, the SIEM has different capabilities than the EDR system so the analyst is forced to use the EDR system to dive deeper into the data. EDRs are a prime spot for SOAR integrations.
EDR products also vary in their ability to integrate CTI research, sandbox analysis, network firewall/NSM search and firewall blocks. SOAR EDR integrations can also help in these areas as well.
EDR Alert SOAR Playbook
Pull data from endpoint for investigation
Send suspicious hashes, urls, IP addresses to CTI.
Virustotal, etc
Send any suspicious files to sandbox for analysis:
Recorded Future
Hybrid analysis
Any run
Pull key endpoint data back to forensic analysis system: remnux, SIFT, etc
Look for strings "Floss like a Boss"
olevba (Office docs analysis)
base64 transforms (cyberchef, base64 -d)
If necessary collect forensic data using Forensic Analysis SOAR Playbook
Search other systems for similar IOCs
Search Firewall/NSM for activity related to endpoint IOCs
Block IP, URL, domain in firewall
Forensic Analysis SOAR Playbook
In some deep endpoint responses or insider threat responses forensics artifacts need to be captured and analyzed.
Collect memory dump from system
and/or
Collect disk image from system
Load memory dump into Volatility
Look for suspicious network connections
Identify processes with Volatility plugin pslist
Look at parent/child process relationships (Volatility .dot format analyzed in graphviz.org)
Carve out suspicious executable from memory using procdump
Analyze executable using CTI (Virustotal, etc)
Analyze executable using sandboxes (Hybrid analysis, etc)
Analyze executable using malware analysis tools (remnux, SIFT, etc)
Other Endpoint Analysis SOAR Playbook
Besides EDR products, endpoints often have other telemetry like from Windows event logs. Some use/cases that can alert in a SIEM can be triggered from these logs. Some of tehse use cases include:
Suspicious Windows Logon
Suspicious Linux Logon
The impossible logon
Logon from Disabled Accounts
Playbooks in this area are trying to determine:
Was the suspicious user logon successful?
Was the suspicious logon legitimate?
No: Why is that logon being used?
Where is the suspicious logon coming from (Compromised machine, etc)?
Network Analysis - SOAR
NSM systems often can alert to suspicious traffic seen on the network.
Connections to strange country codes
Keep an eye on Scandanivian IPs because high source attack countries like Belarus, Lithuania, Ukraine can get lumped with those IP ranges.
Command & Control (C&C) beaconing
AC Hunter
Malicious file network transfer - Playbook
Endpoint EDR triggers on a malicious file so you have the file hash.
Automatically search zeek files.log for that hash to see if that file was transmitted on the network and where it was transmitted to.
Did use X access this thing over the network? or What did they access over the network? Playbook
Connect user X's identity to a host
Use a combo of Kerberos.log and ntlm.log https://docs.zeek.org/en/master/logs/smb.html
Corelight soon coming out with ldap.log
Query if the host accessed the resource or what resource was accessed
Suspicious Network Traffic (beaconing, etc) - Playbook
NSM triggers SOAR
SOAR pulls CTI on network traffic (IP, urls, DNS, JA3, etc)
Ask yourself, "Is it pertinent to what is being presented by this traffic?"
Firewall blocks can look suspicious
Scanners look suspicious and need to be whitelisted
SOAR pulls data from endpoint of what process and file initiated suspicious network connection
Siem Triage
SIEMs have scoring algorithms to help provide SOCs some fidelity on what the most serious events are. Most SIEM scoring algorithms are on a 1-10 scale or a 1-100 scale, with 10 or 100 being the most critical events. These models combine values with different weights to formulate a total threat score. Common weight factors include:
Asset Severity - For example is this your Domain Controller? (This is why integrating asset models and asset information from CMDBs is so crucial to SIEM deployments)
Asset vulnerabilities - Is the alert log related to a vulnerability the asset has? or is the asset just a plain vulnerable system? (This is why integrating vulnerability data into your SIEM is so crucial to SIEM deployments)
Alert Severity & Frequency - Most alert logs from point security products (EDRs, IPS, Firewalls, etc) have a severity value within the log itself. The frequency differentiates between a single log versus multiple log alerts.
Other values - This can be performance monitoring values, and other things.
An issue with SIEM threat scoring is they can sometimes be inaccurate leading to a false sense of emergency. SOAR playbooks can be designed to take data from the SIEM alerts and do additional investigation like CTO enrichment.
New User - SOAR
User accessed new system?
Insider Threat - SOAR
Detect Exfiltration of data alert.
Search network logs - Was data transferred?
Where was data transferred to?
Pivot to EDR to check user activity.
Swimlane Integrations
https://www.pagerduty.com/docs/guides/swimlane-integration-guide/
Threat Minor
SOAR Evaluations
API integrations:
Out of box integrations with:
Firewall/Proxy - Fortinet
Endpoint - Windows Defender
A
SIEM - Elastic, Humio
Email input (i.e., phishing email box). .eml analysis
support web forms for user input
Threat Intel:
Extract IOCs from PDFs, CSVs and other formats and search for those IOCs within the orgs data. If an IOC is found trigger an alert.
Enrichment integrations:
Virus Total
Recorded Future
MISP
Domain Tols
Ability to add new product integrations
IR Response:
Map events from data sources into Mitre ATTTACK framework
Inject human response into playbooks
pause automations for human input
Trigger automations manually
Support playbok testing
Support playbook versioning
Case creation - service now
Guides IR workflows
attachments analyzed for forensic investigation
Reporting and Metrics:
Business intelligence reporting
Email templates
No licence limits on number of cases, playbooks created, triggersor actions done by the system
windows autoIT
https://docs.swimlane.com/docs/
setting field values
Plugins/Connectors - https://apphub.swimlane.com/home
SOAR and SOC stats
fff
Tuning SIEMs
Eight Factors
After working with a few security teams for a while, we’ve summarized a few factors that you need to consider when prioritizing your security alerts:
External threat intelligence validation
Does threat intelligence e.g. VirusTotal also find related threats?
Detection severity score
How severe is this security detection? （Usually provided by detection vendor)
Which stage is it in the MITRE framework?
What is the false positive rate of this type of detection?
Machine type
Is it a client-facing machine or an internal machine?
Who is on the machine?
Is it a server that stores or access sensitive data or that has some special role in the organization (e.g. domain controller)
User type
who is the affected user?
Is it an account that has privileges (e.g. domain admin, dba)? Is it a VIP?
Vulnerability on the machine
Does the machine have a vulnerability?
How severe is this vulnerability?
History Intelligence
Is it the first time to see it?
Impact
Is it widespread across a couple of machines?
Is it targeting one user? A single user that inputs their creds in a fake login page is bad but not as bad as multiple machines getting encrypted at the same time.
External Defense Intelligence
Is it being discussed on the internet?
Is it targeted at my industry?
Any others in my industry are impacted?
Did anyone report false positives?
Chris Crowly
identification = something might be bad
Investigation = determining if it is bad
Anakysis = who, what when where why
Response = Stop the bad thing
Recovery = everything back to normal
Swimlane Integrations
These are the basic steps for getting data:
1. Install the integration of interest (download from Swimlane’s AppHub)
2. Create an asset for the integration
a. The essential criteria typically required are a URL, access information, and some other minor details
3. Create the task from the integration
a. Choose the implemented task
b. Give it a name
c. Define how the task gets input data (via static field, record from Swimlane, etc.)
d. Attach the asset to the task
e. Define what fields from the output are necessar
swimlaine python ingtegrations
These are our recommended prerequisites:
1. A target application that supports a RESTful API
2. JSON (JavaScript Object Notation) experience
3. Some understanding of Python
4. PyCharm Community Edition (Developers should use an external development toolkit to debug before adding source code to Swimlane) With the first three basic requirements, you can build almost any integration. Start by defining your key-value pairs, which will house the private URL, username password, JSON Web Token, etc., and which you will need to access the API. You will then use these keypairs in conjunction with some input directives to build an API GET command to get data from your service
Comments