Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Perimeter

5/29/2019
02:30 PM
Robin Hicks
Robin Hicks
Commentary
Connect Directly
LinkedIn
RSS
E-Mail vvv
50%
50%

Don't Just Tune Your SIEM, Retune It

Your SIEM isn't a set-it-and-forget-it proposition. It's time for a spring cleaning.

Any system information and event management (SIEM) system will require a good deal of customization out of the box before the organization deploying it will see useful data. Once set up, though, the SIEM quickly becomes an invaluable tool in the engineer's toolbox for identifying risks, trends, malicious activity, and even simple misconfigurations. But how many organizations are treating the SIEM as a static solution and simply "setting and forgetting"?

The reality is that our environments are constantly evolving: data types, endpoints, subnets, compliance requirements, technology and business risk, and other variables we draw upon when we set up the SIEM initially are all dynamic. Of course, in larger organizations there are likely to be teams dedicated to maintaining the SIEM that remain aware of these changes and adjust as necessary. But in smaller organizations, we tend to get bogged down in day-to-day activities that prevent us from capturing all these changes. After all, the shortage of cybersecurity staff is well known and shows no sign of easing. Over time, alerts become stale and incomplete if these changes are neglected, eventually leading to the infamous alert fatigue.

If you find yourself in the latter category, consider treating your SIEM updates like a spring cleaning exercise this year — one or two long days dedicated to reviewing all your alerts, rules, variables, and other criteria in the SIEM to see what is still relevant and what's not, what's changed, and consider some of the following items:

  • Have any application updates for the SIEM been released but not applied? Hopefully not, but take this opportunity to confirm and patch your system to the most current, stable release.
  • Has the network team stood up any new subnets or equipment, such as DMZ environments, to or from which traffic should be monitored?
  • Has the systems team deployed new servers whose logs should be monitored?
  • Have your developers released any new applications that should be incorporated?
  • Have your endpoints started using any new software (operating systems or productivity applications) that should be monitored?
  • Have any applications or services moved to new servers and/or subnets?
  • Have any new special access privileges been introduced (vendors and contractors, for example)?
  • Have any new users been granted elevated privileges?
  • If your organization uses file integrity monitoring or user and entity behavior analytics, is this configured across all nodes where necessary and is it monitoring all the right metrics?

Before moving on, consider one more often-overlooked value: Has the business's risk appetite toward any of the above items changed? What was considered low risk a year ago may be a high risk today or vice versa. Having a good grasp on what is important to the business will pay dividends toward knowing what is critical and what is not — and keep in mind that what is critical to us as security professionals may not always seem critical to the business.

In the interest of being thorough, approach the review as an out-of-the-box setup. Don't assume a rule or alert's configuration is still valid because you remember setting it up and don't think anything needs to be changed. That's the equivalent of not vacuuming under the couch because nothing should be under there, but moving the couch usually disproves this theory.

Just as you would approach spring cleaning your home, overturn the dusty items and look in all the dark corners for anything that could be working better. Engage your SIEM vendor if you can — most will offer a periodic review with your account manager to look over your shoulder and offer guidance on what you may be doing right or wrong, what you could be doing better, and any useful tips or tricks they've seen.

This should not be an evaluation of what else to add to your plate but an opportunity to ensure the information you are receiving is timely, accurate, and relevant. In the end, you should be left with a squeaky-clean environment and a SIEM that behaves as well as it did on Day 1.

Related Content:

Robin Hicks has spent the last 10 years in various TechOps roles, with the last four dedicated to information security. He specializes in network security and secure network design, audit, and GRC. He holds an undergraduate degree in Information Technology with a Security ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
AaronS926
50%
50%
AaronS926,
User Rank: Author
9/24/2019 | 12:34:28 PM
Consider Raising the Bar
This is solid guidance for those who have not yet integrated these activities into their ongoing SIEM management lifecycle. While an annual effort is certainly better than nothing, I would encourage readers to turn these activities into scheduled quarterly tasks.  Create a ticket, drop a recurring appointment in your calender - use whatever method works best for you, but challenge yourself to make SIEM maintenance part of "normal" operations.
COVID-19: Latest Security News & Commentary
Dark Reading Staff 10/23/2020
7 Tips for Choosing Security Metrics That Matter
Ericka Chickowski, Contributing Writer,  10/19/2020
Russian Military Officers Unmasked, Indicted for High-Profile Cyberattack Campaigns
Kelly Jackson Higgins, Executive Editor at Dark Reading,  10/19/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-24847
PUBLISHED: 2020-10-23
A Cross-Site Request Forgery (CSRF) vulnerability is identified in FruityWifi through 2.4. Due to a lack of CSRF protection in page_config_adv.php, an unauthenticated attacker can lure the victim to visit his website by social engineering or another attack vector. Due to this issue, an unauthenticat...
CVE-2020-24848
PUBLISHED: 2020-10-23
FruityWifi through 2.4 has an unsafe Sudo configuration [(ALL : ALL) NOPASSWD: ALL]. This allows an attacker to perform a system-level (root) local privilege escalation, allowing an attacker to gain complete persistent access to the local system.
CVE-2020-5990
PUBLISHED: 2020-10-23
NVIDIA GeForce Experience, all versions prior to 3.20.5.70, contains a vulnerability in the ShadowPlay component which may lead to local privilege escalation, code execution, denial of service or information disclosure.
CVE-2020-25483
PUBLISHED: 2020-10-23
An arbitrary command execution vulnerability exists in the fopen() function of file writes of UCMS v1.4.8, where an attacker can gain access to the server.
CVE-2020-5977
PUBLISHED: 2020-10-23
NVIDIA GeForce Experience, all versions prior to 3.20.5.70, contains a vulnerability in NVIDIA Web Helper NodeJS Web Server in which an uncontrolled search path is used to load a node module, which may lead to code execution, denial of service, escalation of privileges, and information disclosure.