Hello Team...I was wondering in terms of "Best Practice" tracking for the PCI, NIST, Security logging...is there such a thing as "Best Practice"?
In other words, when I look at the different sections for Security, PCI, etc. I often see the same or similar templates for use.
Currently, the environment we are using has all of them enabled but I don't see the value in doing it that way...I believe we should use the ones that are "best practice" (if they exist) in order to make the alerts more manageable as well as to reduce the number of alerts coming in (saving resources and removing desensitization due to the amount of alerts).
I would certainly appreciate any and all feedback from the community.
Thanks so very much!
I'd also check out some of the posts here on the thwack Product Blog about different compliance initiatives - it might help to understand why certain things are in the recommendations so you can deduce some of the overlap.
Once you've checked off the MUSTs for your organization (like PCI), then my advice would be to prioritize the information you can act on next. Know that you have a problem, know that you have the right information to deal with the problem, and know what you'll do about it. It's easy to feel like logging everything is the best idea because it COULD give you the best information should something happen, but the reality for, well, almost everyone, is that you end up filtering everything out except what you want to know.
I think the previous comment is a good clue too - the rules in LEM and other SW products ARE indicators of best practices, and the categories of rules that were added help you narrow down the out of the box content that can help get you there. The product tries to get you close, but only you know your organization and what you can deal with, let alone afford (literally) to store and sift through.
The product managers for all of the products are often seen saying that all OOTB alerts for all SolarWinds products are examples or templates that you can use a reference point to get you started, but should be reworked and tailored to you particular situation. Whenever I do a LEM engagement we spend about an hour or two running through the list of alert templates that the product ships with to verify which ones make sense for this client and check if there is anything that needs to be adjusted. An easy example being the rule for unauthorized DNS servers references a list of approved DNS servers, but you have to actually add your server to the list or it just alerts on any port 53 traffic that your firewall sees. Also, this rule is completely useless if your LEM environment isn't hooked into all your firewalls. The other side is you might not necessarily need a rule in LEM if it would just duplicate a function already being taken care of by any other software you own. If you already get an email from NCM every time someone changes a device config then it wouldn't make sense to also alert on it in LEM (but you still wan to be sending those logs to LEM for archival and potential forensics later on).
A big emphasis for the way the rules are set up in LEM is to track several categories of events that an auditor might be interested, then to put them into a bunch of reports that *in theory* someone would be reviewing regularly to keep their finger on the pulse of what's normal in the environment and what is not. You will normally find you need to build out a bunch of exclusions or adjustments to those alerts in order to turn them into something actionable instead of just getting a wall of text that nobody will read. If nobody is looking at the data the you are wasting your time. I would also point out that any alert that is creating "incidents" as part of their action is kind of pointless if you don't also regularly run and review the corresponding incident reports. Can't tell you how many clients have LEM and don't realize what those alert actions actually are doing.
I've done enough LEM work to say that outside of a very short list of standard rules every engagement is different and you would want to work with your auditor to determine that you are collecting the relevant information that they are asking for. Logon events for accounts with higher privileges, changes to the group memberships and AD structure, and configuration of your devices seem to be the main ones. Beyond that is gets into a lot of looking at what the data is bringing you and trying to determine what would be "unusual" behaviors within that environment.
SIEM's should also be pretty tightly integrated with your corporate IT security policies, many of them should have corresponding rules in LEM to audit for violators, and likewise there isn't much point in building a bunch in LEM if you don't have your applicable IT policies sorted out. The SIEM should go hand in glove with monitoring and enforcing policies.
Great post mesverrum, thanks for sharing.
I would also add that a good starting point would be to make the classification based on a list like Audit Policies and Best Practices for LEM - SolarWinds Worldwide, LLC. Help and Support
We reduced it further by fine-tuning the rules, correlation, correlation time and applying internal-specific filters. We only track around 20 Windows categories and the rest are stopped at source level, they do not reach LEM.
I would advise you to also set up Scheduled Search reports, more flexible than LEM Reports.
They can be set up quickly and once you configure them properly with LEM actions, you can also delegate the reporting to appropriate personnel, so they're "in the know" about specific events of their interest.
SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community. More than 150,000 members are here to solve problems, share technology and best practices, and directly contribute to our product development process.