Take a shot at some SOC Playbooks

Just going by experience which steps do y'all think should go into these SOC playbooks? The use cases are from the top 10 you would usually find in an average-sized SOC.
#1 Abnormal number of failed login attempts.
#2 Abnormal Number of user accounts created.
#3 Abnormal Number of Distinct Emails Deleted.
#4 Abnormal Number of Distinct Emails Archived.
#5 Unauthorized user account creation.
#6 Robotic Pattern Observed - Failed Authentication
#1 Abnormal number of failed login attempts.
#2 Abnormal Number of user accounts created.
#3 Abnormal Number of Distinct Emails Deleted.
#4 Abnormal Number of Distinct Emails Archived.
#5 Unauthorized user account creation.
#6 Robotic Pattern Observed - Failed Authentication
B.Sc (Info. Systems), CISSP, CCNA, CCNP, Security+
Tagged:
Comments
Based on your six examples, you will be writing response procedures to service automated threat alerting from a SIEM or alerting events generated by a security appliance. The playbook will contain information on how to interpret the alert and its possible causes, what additional information to collect that was not provided by the alert (i.e. triage), how to correlate the information with other alerts and gather additional information (from both technology and humans) to give the analyst a better situational awareness of system and network activity at the time of the possible incident.
The actual playbook procedures depend greatly on the structure and content of the organization that the SOC monitors. Using #1 as an example, what system is generating the failed login attempt events (e.g., UNIX/Linux or Active Directory)? Is the system signalling an invalid login attempt also alerting that an invalid login threshold has been reached or is a rule in a SIEM keeping track of this alerting threshold? What does your environment consider an "abnormal" number of login events? Does this threshold change for for different systems in your organization? How many different types of systems will be generating these events?
You must also consider how much work you are creating for your (few) SOC analysts. If failed login attempts are a common occurrence in your organization, and your playbook requires the SOC analyst to make contact with the human operator of a system to ask about the event, and this happens 20 times a day and with a 99.9% non-malicious finding, you will quickly burn-out your analysts unless you either tune your alerting threshold or create automation to handle the bulk of this alert for them.
Finally, I would suggest keeping response procedures for alerts produced by technology (e.g., SIEM) and humans in one set of playbooks and procedures for threat hunting in a separate set of playbooks. Many SOCs these days are trying to work both security alerts and perform threat hunting; threat response and threat hunting are more different than they are similar.
Forum Admin at www.techexams.net
--
LinkedIn: www.linkedin.com/in/jamesdmurray
Twitter: www.twitter.com/jdmurray
#1 Abnormal number of failed login attempts.
#2 Abnormal Number of user accounts created.
#3 Abnormal Number of Distinct Emails Deleted.
#4 Abnormal Number of Distinct Emails Archived.
#5 Unauthorized user account creation.
#6 Robotic Pattern Observed - Failed Authentication
You can see why being a SOC analyst is not a "sexy" job and most analysts move on to something more creative/challenging after a couple of years.
Forum Admin at www.techexams.net
--
LinkedIn: www.linkedin.com/in/jamesdmurray
Twitter: www.twitter.com/jdmurray
In your playbooks, it is important to help the analyst discern between "false positive" events and "misuse" and "Business As Usual" (BAU) activity. A false positive is the detection of a condition which causes a security alert but the condition never actually occurred, or the condition is not an actual security concern. False positives are therefore caused by an error in the logic of SIEM rules, misinterpretation of event information, incorrect threshold levels, etc. and can be "tuned-out" so as never to occur in the SIEM alerting.
Misuse is generally divided into three causes: accidental, negligent, or malicious activity. BAU is normal activity that, in some context, can be detected as misuse, such as typical system/activity activity that occurs during a change control, or activity that occurs very infrequently, such as a batch job that is run only once-a-month (i.e., too infrequently to be remembered by behavioral security as a BAU activity). Documenting Lessons Learned is invaluable for preserving this tribal knowledge of such occurrences within the org that the SOC is monitoring.
Forum Admin at www.techexams.net
--
LinkedIn: www.linkedin.com/in/jamesdmurray
Twitter: www.twitter.com/jdmurray
Security Engineer/Analyst/Geek, Red & Blue Teams
OSCP, GCFA, GWAPT, CISSP, OSWP, AWS SA-A, AWS Security, Sec+, Linux+, CCNA Cyber Ops, CCSK
2021 goals: maybe AWAE or SLAE, bunch o' courses and red team labs?