Centralized Log Management
-
@braswelljay said in Centralized Log Management:
I've seen Graylog mentioned as a possible solution.
It WAS good, until their licensing went to shit.
-
@braswelljay said in Centralized Log Management:
I was hoping to see what others might be doing to address these kind of issues.
Most people don't have those issues. Retaining logs of a year is pretty much unheard of. Even Wall St. firms don't do that. Military might of course. But very few places can utilize a server log in real time, let alone a week old one and to start pouring through year old logs.... totally pointless.
While there are times this might make sense, dollars to donuts your "cybersecurity" team has no idea what they are doing and making completely bogus requirements because they sound good to management but have no technical (ergo security) merit. No one responds to an incident a year later. That's ridiculous.
Storing logs is expensive. Really expensive. No one does it. Not like that. It makes no sense. I'd ask for a pretty serious business explanation of how the cost of building, maintaining, and storing all that data is justified from their security response position. I guarantee once you ask them to explain, they'll be forced to admit they have no idea what they are doing.
-
@braswelljay said in Centralized Log Management:
Does not collect server, application and network logs sufficiently to respond to and investigate a cybersecurity incident
This is not a bad thing. Collecting logs is good, centrally is best. But only if you have a team that can use them. If you had that, likely you'd already be doing this. So the question is... before doing this, do you have a team ready to leverage it? Or is this just a way to potentially spend more money with the "cyber security" guys because there's no better way to make money than getting paid to read logs.
-
-
@scottalanmiller said in Centralized Log Management:
@braswelljay said in Centralized Log Management:
Does not collect server, application and network logs sufficiently to respond to and investigate a cybersecurity incident
This is not a bad thing. Collecting logs is good, centrally is best. But only if you have a team that can use them. If you had that, likely you'd already be doing this. So the question is... before doing this, do you have a team ready to leverage it? Or is this just a way to potentially spend more money with the "cyber security" guys because there's no better way to make money than getting paid to read logs.
No there is no team that would be able to leverage. This is a very good point and definitely something for us to keep in mind.
From your perspective is there any value in collecting them centrally so that if we were to be breached it might help other experts that we would almost certainly have to engage? That is even if we don't really have the inhouse expertise to use them effectively on a day to day basis, is it still worth keeping and protecting those logs in the event that they are needed due to an actual compromise of some kind?
-
@scottalanmiller said in Centralized Log Management:
@braswelljay said in Centralized Log Management:
Does not collect server, application and network logs sufficiently to respond to and investigate a cybersecurity incident
This is not a bad thing. Collecting logs is good, centrally is best. But only if you have a team that can use them. If you had that, likely you'd already be doing this. So the question is... before doing this, do you have a team ready to leverage it? Or is this just a way to potentially spend more money with the "cyber security" guys because there's no better way to make money than getting paid to read logs.
Standards such as ISO 27001 have requirement that logs are protected. If an intruder gains root privileges on a server the only way to protect the logs is to have them stored somewhere else. So having central logging might be a compliance issues in some cases.
-
@scottalanmiller said in Centralized Log Management:
@braswelljay said in Centralized Log Management:
I was hoping to see what others might be doing to address these kind of issues.
Most people don't have those issues. Retaining logs of a year is pretty much unheard of. Even Wall St. firms don't do that. Military might of course. But very few places can utilize a server log in real time, let alone a week old one and to start pouring through year old logs.... totally pointless.
While there are times this might make sense, dollars to donuts your "cybersecurity" team has no idea what they are doing and making completely bogus requirements because they sound good to management but have no technical (ergo security) merit. No one responds to an incident a year later. That's ridiculous.
Storing logs is expensive. Really expensive. No one does it. Not like that. It makes no sense. I'd ask for a pretty serious business explanation of how the cost of building, maintaining, and storing all that data is justified from their security response position. I guarantee once you ask them to explain, they'll be forced to admit they have no idea what they are doing.
Now - while the year is likely ridiculous for most, you definitely "hear in the news" all the time about so and so was hacked, and the hackers got in 3+ months ago though Jody's PC when she opened an email. So logs going back three months doesn't seem unreasonable - if you want to be able to go back that far forensically.
-
@scottalanmiller said in Centralized Log Management:
@braswelljay said in Centralized Log Management:
Does not collect server, application and network logs sufficiently to respond to and investigate a cybersecurity incident
This is not a bad thing. Collecting logs is good, centrally is best. But only if you have a team that can use them. If you had that, likely you'd already be doing this. So the question is... before doing this, do you have a team ready to leverage it? Or is this just a way to potentially spend more money with the "cyber security" guys because there's no better way to make money than getting paid to read logs.
He was audited by what we assume is a third party likely strickly pointing out best practices. These pointed out items likely don't take the specific company and their current setup into mind at all.
While it's not bad for the audit to show these things - the OP and their management should be asking - OK - logs - do we need them? maybe it's something we should have been doing, and now decide we will - ok now that we will - what will it take to do what needs to be done with them?
or they could decide - the cost of personal checking the logs and remediating discovered issues isn't worth it.. so while we understand we aren't following the generic best practices - we are following what is good for us. -
Loki is another popular open source solution.
-
Scott pretty much nailed it. Although collecting and preserving logs centrally is a good idea, analysing them anything but superficially would normally require a dedicated IT security team. There are (expensive) solutions like SIEM that make this job easier but even those can hardly be managed by a typical SMB/SME IT depts on their own. If the OP's organisation needs to be ISO 27001 certified or compliant with PCI, HIPAA etc. yet small enough, looking at MDR, MSSP or managed SIEM providers might be an alternative.
-
@taurex said in Centralized Log Management:
Scott pretty much nailed it. Although collecting and preserving logs centrally is a good idea, analysing them anything but superficially would normally require a dedicated IT security team. There are (expensive) solutions like SIEM that make this job easier but even those can hardly be managed by a typical SMB/SME IT depts on their own. If the OP's organisation needs to be ISO 27001 certified or compliant with PCI, HIPAA etc. yet small enough, looking at MDR, MSSP or managed SIEM providers might be an alternative.
Opendistro/opensearch is an SIEM, same with Loki/Grafana or Graylog (even with the crappy licensing).
They don't have to be expensive and they can be relatively easy to set up reasonable alerting for events you need to know about.
-
@braswelljay said in Centralized Log Management:
@scottalanmiller said in Centralized Log Management:
@braswelljay said in Centralized Log Management:
Does not collect server, application and network logs sufficiently to respond to and investigate a cybersecurity incident
This is not a bad thing. Collecting logs is good, centrally is best. But only if you have a team that can use them. If you had that, likely you'd already be doing this. So the question is... before doing this, do you have a team ready to leverage it? Or is this just a way to potentially spend more money with the "cyber security" guys because there's no better way to make money than getting paid to read logs.
No there is no team that would be able to leverage. This is a very good point and definitely something for us to keep in mind.
From your perspective is there any value in collecting them centrally so that if we were to be breached it might help other experts that we would almost certainly have to engage? That is even if we don't really have the inhouse expertise to use them effectively on a day to day basis, is it still worth keeping and protecting those logs in the event that they are needed due to an actual compromise of some kind?
Only if that is something that you would truly do. Ask management to do a few things...
-
Write a policy and procedure as to what to do in case of a breach. Does this document include "hire an outside team to look at logs"? If yes, okay. If not, then obviously collecting has no value. Make them determine this now, you can't determine it later without having already spent or not spent a lot of the money.
-
Get a budget, both for the log collection AND for the log reading.
-
Compare the expected cost against value. How much will it cost to collect logs if nothing bad happens (and you have no one to leverage them in a healthy environment?) How much will you gain from someone paid to read them who isn't familiar with your logs already (a silly proposition from the start.) Does spending that money reflect good security policy (saves money) or reckless business mistake (losing money.)
-
-
@pete-s said in Centralized Log Management:
@scottalanmiller said in Centralized Log Management:
@braswelljay said in Centralized Log Management:
Does not collect server, application and network logs sufficiently to respond to and investigate a cybersecurity incident
This is not a bad thing. Collecting logs is good, centrally is best. But only if you have a team that can use them. If you had that, likely you'd already be doing this. So the question is... before doing this, do you have a team ready to leverage it? Or is this just a way to potentially spend more money with the "cyber security" guys because there's no better way to make money than getting paid to read logs.
Standards such as ISO 27001 have requirement that logs are protected. If an intruder gains root privileges on a server the only way to protect the logs is to have them stored somewhere else. So having central logging might be a compliance issues in some cases.
Not many companies need to follow that. And that's one of the reasons that those certifications are so often considered bad.... they make core business decisions a requirement when they rarely make sense.
-
@dashrender said in Centralized Log Management:
He was audited by what we assume is a third party likely strickly pointing out best practices. These pointed out items likely don't take the specific company and their current setup into mind at all.
Not possible. In order to be a best practice is MUST apply to all businesses. If you have to evaluate the efficacy of something, then it's a "rule of thumb" at best.
If they presented this as a best practice, they are a security risk and we know that they are being dishonest. It is a good security practice, from an isolated "security without business concern" perspective. But in business, security like IT, is a business function. All security has to be seen in respect to its business protection value. If the security costs more than it protects, it itself is the failure.
-
@dashrender said in Centralized Log Management:
While it's not bad for the audit to show these things - the OP and their management should be asking - OK - logs - do we need them?
Exactly. The audio SHOULD mention it, as it is really important. But it needs to be "We found no logging, and no log centralization, and no security around logs. These are powerful security tools and should be evaluated for efficacy in the given environment."
-
@stacksofplates said in Centralized Log Management:
@taurex said in Centralized Log Management:
Scott pretty much nailed it. Although collecting and preserving logs centrally is a good idea, analysing them anything but superficially would normally require a dedicated IT security team. There are (expensive) solutions like SIEM that make this job easier but even those can hardly be managed by a typical SMB/SME IT depts on their own. If the OP's organisation needs to be ISO 27001 certified or compliant with PCI, HIPAA etc. yet small enough, looking at MDR, MSSP or managed SIEM providers might be an alternative.
Opendistro/opensearch is an SIEM, same with Loki/Grafana or Graylog (even with the crappy licensing).
They don't have to be expensive and they can be relatively easy to set up reasonable alerting for events you need to know about.
Can be, for sure. But you need someone to install, configure, maintain those systems. They don't currently have an IT team that is ready to read the logs as it is. While we could certainly discuss the issues with having a more general IT gap (log reading is more for troubleshooting than for security, so this gap could be pretty large) we'd be forced to look at the cost in a larger context that could get pretty big.
-
@scottalanmiller said in Centralized Log Management:
should be evaluated for efficacy in the given environment."
That is how exactly zero "audits" work.
-
@jaredbusch said in Centralized Log Management:
@scottalanmiller said in Centralized Log Management:
should be evaluated for efficacy in the given environment."
That is how exactly zero "audits" work.
It's how ALL honest audits work. The problem is, like most MSPs who are secretly scam VARs, almost all audits, especially those hired outside of IT by incompetent managers, bring in scammers with no knowledge, qualifications, or honesty who just seek to defraud and are, themselves, a security risk.
We do audits, however, and we'd never present that way. Real auditors are out there. But people don't like to hire them because they can't produce checklists and shopping lists.
-
@scottalanmiller said in Centralized Log Management:
OpenSearch from Amazon. They took the ELK stack, made it 100% open source, and back it by Amazon. It is so good both in technical product and in licensing, that essentially it is the only game in town now.
Interesting take from ELK side
https://www.elastic.co/what-is/opensearchOur products remain free and open, but Amazon can no longer freely use Elasticsearch and Kibana products without collaborating with us. Rather than collaborate with us and contribute back, Amazon created its own forked projects, which are less mature, not ready for production use, and provide inferior capabilities compared to Elasticsearch and Kibana.
-
@hobbit666 said in Centralized Log Management:
@scottalanmiller said in Centralized Log Management:
OpenSearch from Amazon. They took the ELK stack, made it 100% open source, and back it by Amazon. It is so good both in technical product and in licensing, that essentially it is the only game in town now.
Interesting take from ELK side
https://www.elastic.co/what-is/opensearchOur products remain free and open, but Amazon can no longer freely use Elasticsearch and Kibana products without collaborating with us. Rather than collaborate with us and contribute back, Amazon created its own forked projects, which are less mature, not ready for production use, and provide inferior capabilities compared to Elasticsearch and Kibana.
LOL - someone sounds like they are just complaining that their toy was taken.
