Security threat detection — what is it? (1/2)
For many outside the tech bubble asked what the word “cybersecurity” means to them, the first thoughts to arise are bound to be very different than typical security professionals.
Their minds will likely conjure an image of Elliot Alderson from Mr. Robot-the quintessential mainstream hacker. Or perhaps the most recent nation state they’ve read about in The Wall Street Journal, ordering cyberattacks from a command room by the dozen and publishing the data on the deep web.
In reality for security professionals, day-to-day work tends not to be as exciting, especially for those in blue team roles. Exciting typically is not what drives security value, and frequently spawned similar security incidents indicates a systematic lack of security initiative.
Fortunately, blue teams provide a critical role in being the first line of defense in an organization against cyber threats. They are, analogously, the people on the “other side of the screen” from the mainstream understanding of hacking above.
While other lines of defense are important, one could argue that proper implementation of the first is a dependency for all others. Without this, the tower has a much weaker foundation to rest upon.
When a company adopts a process of proactively monitoring their infrastructure and applications for potential cyber attacks, this is called threat detection. Because of all of the ways this can be implemented in organizations, this has become somewhat of a buzzword in the industry.
However, the basic principles are simple: you or a program see an alert, you take action on it —investigate it as a potential threat, close it as a false positive, or escalate it to another person or team. Thus, combined this becomes threat detection and response.
Breaking down detection and response
Detection and response is actually very broad as a security topic, including some of the following:
- Extended Detection and Response (XDR)
- Zero Trust Security
- Endpoint Detection and Response (EDR)
- Threat Detection and Response (TDR)
For this article, we’ll avoid trying to boil the ocean by focusing primarily on Threat Detection and Response (TDR).
Relevant stakeholders
TDR has a large array of stakeholders in an organization who all work together to ensure an effective operational security program. Bottom up, these are:
SOC Analysts
Known as the first line of defense, these are the individuals that receive alerts and triage them. In many organizations, this is a dedicated role. In very large orgs, they work as a team as part of a security operations center (SOC), which sometimes even has a dedicated site on premise in a secure building.
This is the most entry level-friendly role starting with Tier 1 Analysts, who may expected to have anything from zero experience to other limited previous IT help desk or data analyst roles.
Unlike other roles, SOC Analysts’ main function is to investigate suspicious alerts and escalate them when needed — when something looks off or needs a more thorough investigation.
Security Engineers
This title varies significantly across organizations, but in an operations team this typically refers to those who support projects part of a greater security program. This includes:
- security investigations
- identity/IAM configuration
- software application security reviews
In smaller teams, security teams take double responsibility — responding to alerts as a SOC analyst may and choosing when to escalate into an investigation.
In larger teams, they are notified only when a dedicated SOC analyst has confirmed suspicious activity via logs or contact, in which case they will likely choose to start an investigation into malicious activity.
Staff Engineers
Staff engineers, also known as senior engineers in some organizations, help influence the threat detection/SOC discipline. They advocate for process improvements or areas of concern to leadership where the team can use more resourcing. This may be in the form of more budget, staffing, or buying a tool or vendor to assist (like CrowdStrike or Mandiant).
CISO/Leadership
A Chief Information Security Officer is the top of a security organization’s hierarchy. Their job includes managing the budget, communicating security posture to the board and customers, and planning the roadmap of a security program. They should not be involved with SOC alert investigations but may ocassionally provide guidance during security investigations that indicate malicious activity.
Ok, but why?
It’s crucial to understand what security programs aim to accomplish. Plainly put, security is assessing and managing organizational risk. That’s it.
Security can never be 100% guaranteed, which is something anyone early in their career should understand. It’s constantly juggling the following:
- compliance requirements
- real-world risk posture
- end-user requirements and expectations.
Sway too far in one direction and your security program won’t be effective. A harmonious balance works for everyone — your customers, regulators, developers, and team.
Assessing ROI
Return-on-Investment (ROI) is a difficult measure to directly relate to threat detection initiatives. One of the reasons for this is that the “False Positive” rate of alerting is extremely high. False positives generally mean alerts that fire that can be explained by non-malicious system activity. False positives can be frustrating and hurt the team’s discipline if not remediated.
If we try to track metrics by # of alerts investigated, # of investigations resulting from alerts investigated, we’re only seeing half the picture. Contrary to popular belief, a high number of security investigations (with retrospective feedback collected & actioned) can mean your security program is performing pretty well.
Additionally, security incidents — security events resulting in customer impact-are almost always a reflection of multiple failures of a security program. However, we can say that without a threat detection discipline, the odds of catching these later is much more likely.
The consensus is also mixed on estimating financial impact resulting from security breaches. These are highly dependent, hard to quantify, and puzzle even the most experienced risk analysts. We’ll skip trying to answer for that here.
In short, ROI should be assessed against an entire security program, not solely the capabilities of its SOC.
Alerts as an indicator of malicious activity
Look through some recent high-profile public security incidents, and you’ll see that bad actors are typically uncovered as a result of an alert investigation.
From Cloudflare’s Thanksgiving 2023 incident:
On Thanksgiving Day, November 23, 2023, Cloudflare detected a threat actor on our self-hosted Atlassian server. Our security team immediately began an investigation, cut off the threat actor’s access, and on Sunday, November 26, we brought in CrowdStrike’s Forensic team to perform their own independent analysis.
In contrast, look at this Okta October 2023 incident (which impacted the CloudFlare incident above), and we’ll see different language:
Having finalized our investigation, we can confirm that from September 28, 2023 to October 17, 2023, a threat actor gained unauthorized access to files inside Okta’s customer support system associated with 134 Okta customers..
While we can’t speculate on the response to the incident, we know BeyondTrust notified Okta on October 2nd of malicious activity — showing that there may have been missed opportunities in detecting this specific malicious activity initially on Okta’s side.
This is confirmed in Okta’s investigation closure, in which Okta notes they have stepped up IP-based alerting to “Detect and Block Requests from Anonymizers to Okta Endpoints”.
Additionally, they have embraced just-in-time provisioning, a new responsibility of some SOC teams, to “Ensure admin roles are requested, approved, and assigned to authorized users only for the duration that access is needed.”
These types of high-profile incidents raise awareness about the importance of active detection for malicious activity and informed retrospectives are the first step to repairing customer trust after such events.
Wrapping it up
Threat detection/SOC is critical component of any successful security program, but only when implemented right. Here, we went over the “what” what is threat detection, who are the stakeholders, and “why”- why is this discipline adopted?
In the next post, we’ll dig into the “how”- including how to avoid common obstacles that can stifle threat detection initiatives.
Leave a thumbs up or comment if you have some perspectives to share!
