Basic SIEM That Isn't $plunk

That Random Guy

Long story short, I'm in a pretty small company that likes to bite off more than they can chew. We're slated to have some corrective actions in account that we acquired compliance with ISO 27001.

We don't have any log management nor any SIEM capabilities in place right now.

The auditor told us before that manually scanning for things is a full-time job on its own and wouldn't suffice as adequate for two sysadmins (one being me) who are also handling other responsibilities on a daily basis.

Cue the need for a SIEM or at least something like it.

I've looked and the cheapest I've found is what's either open source or EventSentry.

Leadership seems really keen on having support for whatever we get because they don't want us being left in the dark.

I need to do more testing with Graylog before making a case for it but is there anything anyone knows about some cheap (preferably free) hacks that just do basic things like:

- Real-time alerting

- Reporting

- Log management

- Admin/super user auditing

- Log protection (admins cannot delete them)

AFAIK, only a SIEM can provide these things fully. Being an admin, I can alter anything I provision within Windows.

TIA

stryder144

Have you considered Security Onion?  If I remember correctly, there is a paid support side, though I haven't engaged with that so I can't comment on cost or anything else.  Since it uses the ELK stack, you can add different tools to it and, thankfully, there are a lot of resources for how to set up and use the various tools that come with SO (such as Zeek *formerly Bro).

JDMurray

You need to have a few things considered or in-place in your environment BEFORE you get a SIEM, such as:

• Asset management, including a point-of-contact list for all devices reporting events
• Application management, including a point-of-contact list for all application admins
• Security policies stating what and how all devices and software in your enterprise will report events
• An auditing process to determine if all devices and applications are reporting events as they should
• An event collection and storage system from which the SIEM will receive its input
• Functional description of the rules used to create security alerting events specific to your organization
• Programmers who will develop the custom SIEM content (dashboards, alerts) based on your rules
• Network engineer(s) to install and maintain the SIEM equipment in your enterprise
• SIEM admin to on-board new logging sources, monitor the SIEM's health, and troubleshoot issues.
• Documentation system to store all your custom SIEM admin, configuration, and process documentation
• A SOC with security analysts that will service the security alerts produced by the SIEM.
  
• A ticketing system, or incident workflow platform, used by the SOC analysts to work SIEM alerts, preferably integrated with the SIEM for automated ticket generation.
• Documented handling procedures used by the SOC analysts for working security alerts produced by the SIEM
  

I've overlooked a few things, I'm sure, but that's a good start to understanding that a SIEM is not an install-it-and-forget-it security solution like a Windows anti-virus scanner. When properly utilized, SIEM is a beast that requires lots of enterprise-specific configuration and continuous care and feeding, even for small enterprises.

UnixGuy

Everything @JDMurray said...or get a managed security services provider to do some (or all) of this for you

JDMurray

Yes, but an MSSP isn't a "magic bullet" either. You still need to know quite a bit about your environment and have your own security incident response team (i.e., SOC analysts) to handle the reports the MSSP is providing you. The start-up costs can have a full-featured MSSP service costing you more than having your own Splunk implementation, so make sure you compare SIEM and MSSP with similar capabilities.

UnixGuy

This is actually a fantastic question and one that I come across all the time when I do security assessments.

Scenario: Client doesn't have a SIEM or a security team, which makes their detection controls minimum to zero.

To @JDMurray and others What would you recommend in this case for a client that simply doesn't have the budget? What's the 20% that they can do to get 80% coverage? or what can they do that doesn't require huge budgets to improve this?

I recommended MSSP because some offer cheaper solutions that will give them 'something'..at least make them aware of what they don't have. I'm aware they need to have analysts onsite, but some companies don't have security leadership to guide analysts or budget for it...what's your pragmatic recommendation in this instance?

KyloQuadren

Use ELK

LonerVamp

I've used LogRhythm in the past with a similarly small team, but we're talking like 4+ years ago.

With your level, you also need to be honest with yourself and not bite off more than you can chew either, when it comes to a) standing up/maintaining the SIEM (including paying for storage), b) keeping it cared for and fed, c) tuning it to get what you need to see (if you don't know this yet, the SIEM won't solve it for you in anything but the absolute most basics), and responding to anything it spits out as alarms or issues or events.

For most, I think they got into SIEMs through PCI requirements, rather than seeing a true need and truly wanting to use it. For many, I think starting out with an MSSP is an OK route, just don't expect to be amazed by their value-add or knowledge; such places tend to be high turnover, high burnout, entry level support.

I otherwise cannot +1 JD's post above enough. Especially if you look at Splunk.

That said, you can shortcut or even not do some of those steps. Do you need to attend to the events? No, but it's negligent if you have regulations saying you need that process. Do you need to jump at every event passed on by your MSSP? No, you can just tell them to close every ticket they open, but that seems like a waste of money. Do you need a developer to build custom things? No, but it gets kinda close to needing that when you go Splunk, depending on what you do.

My other suggestion to you is being real about log retention. Don't go too far, as that can get really messy and really expensive. Yesterday, you had 0. That means tomorrow you don't suddenly magically truly need 1+ years of retention. Go for something short and sweet like 30 days and drop all the rest. Build out from there as you truly need and can increase the budget for.

LonerVamp

UnixGuy said:

This is actually a fantastic question and one that I come across all the time when I do security assessments.

Scenario: Client doesn't have a SIEM or a security team, which makes their detection controls minimum to zero.

To @JDMurray and others What would you recommend in this case for a client that simply doesn't have the budget? What's the 20% that they can do to get 80% coverage? or what can they do that doesn't require huge budgets to improve this?

1. I like the idea of an MSSP for these situations. It's a way to get started and have a partner immediately. The value and actual effectiveness may be low, but it's a start.

2. For someone who is a sysadmin today with security interests, and wants to probably leave their current position to get a security position in the nearish future, I'd say put the time into ELK or Security Onion. Yes, it's going to be extra time, but you can take that knowledge with you, and it can be somewhat daunting to otherwise learn. That said, that leans heavily on the side of "doing it yourself with no or limited true support."

3. I'd focus on cheap SIEM solutions and just strive to get good inventory management, good coverage on log collection as you need/want, and start making some very basic, common alerts that are the most obvious events you can think of. Build from there, and see if the business cares to get better. I'd keep log storage very low unless some requirement says otherwise. If you can, cloud storage is changing the SIEM game as it means large storage is stupid cheap.

4. As far as 20% to solve 80% of this situation, I'd say tackle inventory, collect logs somewhere as syslog (Graylog I have not used, but I always see it suggested for SIEM on the cheap), decide upon some use-cases you want to alarm on (which will inform which log sources you go after), and response plans to those alarms. Make sure you gather those logs. For the most part, authentications are a good one, as are alarms/events from other security tools like IPS, firewalls, AV/EDR. Lastly, start to map out the future maturity paths and how much effort and money it'll take to get to those steps. That way, business can either plan for it, or just say it's not worth it.

JDMurray

I don't have any quick advice or solution for fool-proof information network security monitoring because I don't know your environment. A SIEM or MSSP or UTM appliance is simply a tool that must be configured and maintained to be useful. To do this, you need to understand your environment (i.e., devices, information, and people) and have proper information and response services and policies built-in to your people and network(s) before you start shopping for your security monitoring tools. This is a very complex topic because monitoring is only part of one step in the complete security incident response life-cycle.

SteveLavoie

In the same line.. what would you use for asset management on the cheap side (and no excel is not an answer) for smaller network (250 IP and less). 

DiffieHellman173

Will Splunk Light suffice? it is designed for small IT business solutions.

JDMurray

Asset management requires a solution built on a database and yes, Excel is not a database. I don't have a specific recommendation, but there might be a few good OS asset management tools on Github and Sourceforge.

And the free edition of Splunk has too limited of a capacity to be used in a production environment. It's meant for experimentation in a home, educational, or non-prod testing environment only.

That Random Guy

JDMurray said:

You need to have a few things considered or in-place in your environment BEFORE you get a SIEM, such as:

• Asset management, including a point-of-contact list for all devices reporting events
• Application management, including a point-of-contact list for all application admins
• Security policies stating what and how all devices and software in your enterprise will report events
• An auditing process to determine if all devices and applications are reporting events as they should
• An event collection and storage system from which the SIEM will receive its input
• Functional description of the rules used to create security alerting events specific to your organization
• Programmers who will develop the custom SIEM content (dashboards, alerts) based on your rules
• Network engineer(s) to install and maintain the SIEM equipment in your enterprise
• SIEM admin to on-board new logging sources, monitor the SIEM's health, and troubleshoot issues.
• Documentation system to store all your custom SIEM admin, configuration, and process documentation
• A SOC with security analysts that will service the security alerts produced by the SIEM.
  
• A ticketing system, or incident workflow platform, used by the SOC analysts to work SIEM alerts, preferably integrated with the SIEM for automated ticket generation.
• Documented handling procedures used by the SOC analysts for working security alerts produced by the SIEM
  

I've overlooked a few things, I'm sure, but that's a good start to understanding that a SIEM is not an install-it-and-forget-it security solution like a Windows anti-virus scanner. When properly utilized, SIEM is a beast that requires lots of enterprise-specific configuration and continuous care and feeding, even for small enterprises.

I wholeheartedly agree with you. This is why security analyst is a full-time job. It is for all those reasons and more for why I think what they're asking for is ridiculous and more importantly what they're expecting us to do is near-line impossible with our budget all things considered at this time with this crisis.

Albeit we have some of these things covered currently, for me there's no point in having something if we're not going to use it correctly.

That Random Guy

DiffieHellman173 said:

Will Splunk Light suffice? it is designed for small IT business solutions.

I was going to recommend that in one of our meetings but I discovered it doesn't have alerting, which we would need.

UnixGuy

That Random Guy said:

... It is for all those reasons and more for why I think what they're asking for is ridiculous and more importantly what they're expecting us to do is near-line impossible with our budget all things considered at this time with this crisis.

....

This is a common situation unfortunately. I doubt it'll change any time soon. But hey on the positive side, it's a good opportunity for you to learn, whatever you decide to set up.

LonerVamp

SteveLavoie said:

In the same line.. what would you use for asset management on the cheap side (and no excel is not an answer) for smaller network (250 IP and less). 

Personally, for a network that small, I'd consider Excel to be just fine. Bonus if you have scripting to discover assets and plunk them into the spreadsheet and/or email you of changes. Like all CMDB, it'll only be as good as your admins who populate it.

Asset management *should* be driven by other IT needs:

• endpoint support & accounting - If you have 100 workers with 1 workstation each, you want to know that for lifecycle and procurement purposes. Also, for tracking, so desktop teams likely track certain things like MAC and asset tags.
  
• network admins - No one lacks tracking once they've doubled up on IP address with network devices once. Same with sysadmins who don't know what IPs are open/used on a network. In other words, IPAM.
• patching - Software, namely OS patching processes pretty much lend themselves to having and needing some sort of asset tracking so that all assets are accounted for. Tap into these. The same somewhat holds true for AV deployments; likely they get on "all" systems and report in to some management console. Same with whatever manages systems, like AD/GP.

That said, security still requires some absolute source of truth, and usually also active discovery to find the rogues that appear on no one's lists!

If you're homogenous, you could use tools that the admins manage, and then trust them to be accurate. For Windows, AD, and make policy that all systems are domain-joined. For Linux, settle on Puppet/Ansible or whatever works best that manages those systems. Still, there's always one-offs like network devices and vendor-managed appliances. And even Windows environments have Linux VM hosts. So, I'd always also mix in discovery tools. Worst case? Nmap your network daily, maybe **** ARP tables on network devices...

In the past, Spiceworks has been pretty easy for small shops to incorporate. These days from an infosec perspective, I'd always try looking at Axonius early on, if you have even some budget. An IPAM (IP Address Mgmt) solution can also be what you're looking for, so don't limit yourself to CMDB.

Definitely decide what your true needs are. Some people think they need to be fancy with change management so that changing asset A means it impacts Assets B, C, and D, and information systems X, Y, Z, which run on these other assets....  That **** almost never gets done properly, so it's frustrated when managers want that. If it's just a source of truth on your network, figure out what's on your network (including how rogues may get stood up), so you can tailor the solution.