By Building SIEM Use Cases, Standards, Baselining and Naming Conventions
Security operations centers (SOCs) are struggling to create automated detection and response capabilities. While custom security information and event management (SIEM) use cases can allow businesses to improve automation, creating use cases requires clear business logic. Many security organizations lack efficient, accurate methods to distinguish between authorized and unauthorized activity patterns across components of the enterprise network.
Even the most intelligent SIEM can fail to deliver value
when it’s not optimized for use cases, or if rules are created according
to incorrect parameters. Creating a framework that can accurately
detect suspicious activity requires baselines, naming conventions and
effective policies.
Defining Parameters for SIEM Use Cases Is a Barrier to SOC Success
Over the past few years, I’ve consulted with many enterprise SOCs to improve threat detection and incident response capabilities.
Regardless of SOC maturity, most organizations struggle to accurately
define the difference between authorized and suspicious patterns of
activity, including users, admins, access patterns and scripts.
Countless SOC leaders are stumped when they’re asked to define
authorized patterns of activity for mission-critical systems.
SIEM rules can be used to automate detection and response
capabilities for common threats such as distributed denial-of-service
(DDoS), authentication failures and malware. However, these rules must
be built on clear business logic for accurate detection and response
capabilities. Baseline business logic is necessary to accurately define
risky behavior in SIEM use cases.
Building a Baseline for Cyber Hygiene
Cyber hygiene
is defined as the consistent execution of activities necessary to
protect the integrity and security of enterprise networks, including
users, data assets and endpoints. A hygiene framework should offer clear
parameters for threat response and acceptable use based on policies for
user governance, network access and admin activities. Without an
understanding of what defines typical, secure operations, it’s
impossible to create an effective strategy for security maintenance.
A comprehensive framework for cybersecurity hygiene can simplify security operations and create guidelines for SIEM use cases.
However, capturing an effective baseline for systems can strengthen
security frameworks and create order in chaos. To empower better hygiene
and threat detection capabilities based on business logic, established
standards such as a naming convention can create clear parameters.
VLAN Network Categories
For the purpose of simplified illustration, imagine that
your virtual local area networks (VLANs) are categorized among five
criticality groups — named A, B, C, D and E — with the mission-critical
VLAN falling into the A category (<vlan_name>_A).
A policy may be created to dictate that A-category VLAN
systems can communicate directly with any other category without
compromising data security. However, communication with the A-category
VLAN from B, C, D or E networks is not allowed. Authentication to a jump
host can accommodate authorized exceptions to this standard, such as
when E-category users need access to an A-category server.
Creating a naming convention and policy for VLAN network
categories can help you develop simple SIEM use cases to prevent
unauthorized access to A resources and automatically detect suspicious
access attempts.
Directory Services and Shared Resources
You can also use naming convention frameworks to create a
policy for managing groups of user accounts according to access level in
directory services, such as Lightweight Directory Access Protocol
(LDAP) or Active Directory (AD). A standardized naming convention for
directory services provides a clear framework for acceptable user access
to shared folders and resources. AD users categorized within the D
category may not have access to A-category folders or
<shared_folder_name>_A.
Creating effective SIEM rules based on these use cases is a
bit more complex than VLAN business logic since it involves two
distinct technologies and potentially complex policies for resource
access. However, creating standards that connect user access to
resources establishes clear parameters for strict, contextual
monitoring. Directory users with A-category access may require stricter
change monitoring due to the potential for abuse of admin capabilities.
You can create SIEM use cases to detect other configuration mistakes,
such as a C-category user who is suddenly escalated to A-category.
Username Creation
Many businesses are already applying some logic to
standardize username creation for employees. A policy may dictate that
users create a seven-character alias that involves three last-name
characters, two first-name characters and two digits. Someone named
Janet Doe could have the username DoeJa01, for example. Even
relatively simple username conventions can support SIEM use cases for
detecting suspicious behavior. When eight or more characters are entered
into a username field, an event could be triggered to lock the account
until a new password is created.
The potential SIEM use cases increase with more complex
approaches to username creation, such as 12-character usernames that
combine last- and first-name characters with the employee’s unique
HR-issued identification. A user named Jonathan Doerty, for instance,
could receive an automatically generated username of doertjo_4682.
Complex usernames can create friction for legitimate end users, but
some minor friction can be justified if it provides greater safeguards
for privileged users and critical systems.
An external threat actor may be able to extrapolate simple
usernames from social engineering activities, but they’re unlikely to
guess an employee’s internal identification number. SIEM rules can
quickly detect suspicious access attempts based on username field
entries that lack the required username components. Requiring unique
identification numbers from HR systems can also significantly lower the
risk of admins creating fake user credentials to conceal malicious
activity.
Unauthorized Code and Script Locations
Advanced persistent threats
can evade detection by creating backdoor access to deploy a carefully
disguised malicious code. Standard naming conventions provide a
cost-effective way to create logic to detects malware risks. A simple
model for script names could leverage several data components, such as
department name, script name and script author, resulting in authorized
names like HR_WellnessLogins_DoexxJo. Creating SIEM parameters for acceptable script names can automate the detection of malware.
Creating baseline standards for script locations such as /var/opt/scripts and C:\Program Files\<org_name>\
can improve investigation capabilities when code is detected that
doesn’t comply with the naming convention or storage parameters. Even
the most sophisticated threat actors are unlikely to perform
reconnaissance on enterprise naming convention baselines before creating
a backdoor and hiding a script. SIEM rules can trigger a response from
the moment a suspiciously named script begins to run or a code file is
moved into an unauthorized storage location.
Scaling Security Response With Standards
Meaningful threats to enterprise data security often fly
under the radar of even the most sophisticated threat detection
solutions when there’s no baseline to define acceptable activity. SOC
analysts have more technological capabilities than ever, but many are
struggling to optimize detection and response with effective SIEM use
cases.
Clear, scalable systems to define policies for acceptable
activity create order in chaos. The smartest approach to creating
effective SIEM use cases relies on standards, a strong naming convention
and sound policy. It’s impossible to accurately understand risks
without a clear framework for authorized activities. Standards,
baselines and naming conventions can remove barriers to effective threat
detection and response.
Žádné komentáře:
Okomentovat
Poznámka: Komentáře mohou přidávat pouze členové tohoto blogu.