..(yes, that's it!)
If you are a developer who produced it, please die. Be done :-)
More on ugly logs in the future!
"What rankles your readers is how blithely you imply this problem has a simple or effective solution. It doesn't, all the processes or tools you advocate can do is speed up the time it takes to detect the lock-out, but not actually prevent it - i.e. they are ineffective at tackling the primary problem."That is correct; the rogue admin problem has NO simple solution. You might prevent some (few, really) things, you might log some of them and then figure what happened, but there is no simple solution (it goes without saying that "just trust them" is NOT a solution...)
"We all know companies run without sane risk management all the time and are rarely held accountable in America. What makes you think anyone is "screwed"?"Well, this is a good point; maybe I let my idealistic side take over. But, come on, just the fact that bad IT governance is somewhat common, doesn't make it right!
"Now ask yourself who is "screwed" by one person at a small company having all access and no accountability on a network. That's how I run my home network. Big deal."Nobody is. I addressed it here. The risk is acceptable for smaller environments, usually. I don't have an overseeing body set up to control my home passwords :-)
"You seem to forget that sometimes the management just has to trust somebody. "Addressed above.
"Chuvakin, you're a tool. Given the recent idiocy of the releasing of the VPN names and codes, it obviously shows that any sort of detest that Childs had against his superiors at the city were justified."The fact that his bosses are idiots (which seems fairly well established!) does not make him right!
"This is not a private organization. His superiors don't own the company and are NOT entitled to the data. We are, the taxpayers. And as a California taxpayer I fully support someone with the paranoia and technical skill of Terry Childs over a group of bureaucrats who release secure information to the public."Properly evaluating this statement requires a law degree. Thus, no comment. Bureaucrats suck, but rogue admins are not a solution to that. Really!
"The guy was doing his job and doing it incredibly well, and keeping it out of the hands of those who, given their most recent choices, would bring potential disaster to the city."He was NOT, unless crime is part of his job :-) Also, see comments on "IT heroes" above. If your boss is an idiot AND you don't like it, quit.
"Anton Chuvakin seems to think that all admins should be kept underneath management's boot at all times. [...] Managers can't and don't understand what we do, and thus eventually come to the conclusion that we can't be trusted with our own knowledge. [...] Perhaps it's human nature to fear what you don't know or understand -- and that's why management can develop a fear of their own employees."You say 'fear of employees', I say "insider risk management." You say "trust employees", I say "trust but [be able to] verify (=log)"
"his blog leads the casual reader to infer that their businesses are in danger of being hijacked by disgruntled Sys Admins and that isn’t the case." (from here)Eh, not all businesses, but some businesses - definitely (hmm, see Terry Childs story or other published insider attack cases, all the way back to Omega Engineering case and maybe all the way back to ancient history)
"I despise people like Terry Childs, but despise Chicken Little’s like Anton Chuvakin even more." (from here)You say I am 'chicken little', I say "if your boss ignores insider risk management, he is stupid and deserves his business to fail." I also add "if you think admins are 'above the law', you have a good chance of 'turning rogue' yourself AND then ending in jail."
“You’re hired on at a new company placed in charge of securing their online business (websites). You know next to nothing about the technical details of the infrastructure other than they have no existing web/software security program and a significant portion of the organizations revenues are generated through their websites.
What is the very first thing do on day 1?”
At about the same time, I saw a message posted to one of the mailing lists where the poster wondered: "I’ve been asked to look into finding a replacement to our current log management/auditing system. This is a field I haven’t even come close to touching before, and really don’t know the ideal things to look for (or ignore), etc. I’ve been searching through SANS site as well as googling, and I’m not coming up with a lot of great starter information. " And then he asks "Where should I start?"
This is indeed a really good question! Let's rephrase the above for the case of logging:
"You’re hired on at a new company placed in charge of TAKING CONTROL OVER THE LOGS. You know next to nothing about the technical details of the infrastructure other than they have no existing LOG MANAGEMENT process and tools... What is the very first thing do on day 1?”
So the "Day 1" of log management project. What's up?!
The very first thought that should cross you mind before you even do whatever first thing you wanted to do is "WHY?" (don't people hate those 'Why?" questions - focusing on "What?" or "How?" is soooooooo much easier....)
"Log management" is a solution, not a problem. What is your problem that you now have a mandate to solve?
Logs don't just drop on people :-) Well, not often.
What is it that motivated your boss (or his boss, or whoever) to decide to "address this", to "take control over logs?" Was it a new compliance mandate, PCI perhaps? Was it a recent incident where investigation hit the wall due to utter lack of logs? Was it a new corporation-wide IT efficiency improvement project? Was it a lawsuit where an e-discovery request was not satisfied and thus fine was levied? Was it a hot IT project that is impossible to complete without having a tool to analyze logs?
This "need" is very important since logging is a huge realm and not focusing on the need is akin to starting a journey into a hostile wilderness without a map - in other words, it might be fun for a while, but it can end badly :-)
Next, what do you actually do first? Figure out what logs are needed for this effort and what systems produce them (and who "owns" them!) Analyzing SAP logs for J-SOX is a VERY different effort from analyzing Cisco ASA logs for network troubleshooting.
Only at this point you can start thinking about "tools:" parsers, logs, databases, reports, alerts, indexing and other technical thingies as well as capacity planning, scalability, etc. This is the stage where you learn the lingo and learn to cut through marketing messaging to get to the actual tool capabilities.
So, remember: given mandate to "tame the logging monster", think "WHY?" first!
Somebody asked me what blogs do I read? I figured I'd post my answer here:
In any case, hope it was useful!
I just landed at Washington, DC to speak at SANSFIRE tomorrow (my Lunch and Learn on "Log Management 'Worst Practices'" is on Wednesday, July 23rd - come over, it will be fun!)
LogLogic Lunch and Learn Presentation
- "Worst Practices" of Log Management
- Speaker: Dr. Anton Chuvakin, GCIA, GCIH, GCFA
- Wednesday, July 23rd, 2008 * 12:30pm - 1:15 pm
Want to learn all the embarrassing mistakes and pitfalls that await you on the path to log management nirvana? Attend "'Worst Practices' of Log Management" presentation by LogLogic's Logging Evangelist Dr Anton Chuvakin that covers all the things that can go wrong while planning, evaluating, deploying and running a log management solution. Insufficient planning, unrealistic expectations, choosing tools on price alone, lack of logging configuration guidance are among such "worst practices." Each common "worst practice" will be accompanied by suggestions to avoid the errors and do things correctly! Everybody touts "best practices", but this is the place to learn how to avoid the opposite - and have fun in the process.
if you want to meet, drop me an email/call or just show up for "lunch and learn." Unfortunately, I am going back right after my presentation tomorrow...
Instead of my usual "blogging frenzy" machine gun blast of short posts, I will just combine them into my new blog series "Fun Reading on Security." Here is an issue #5, dated June 11, 2008.
See you next time!
All sort of fun stuff was unearthed, discussed and - sometimes - made-up upon reading the Verizon Security Breach Investigations report. Here are some things from the pile which I found fun:
And of course, here is my favorite part: "In 82 percent of cases, our investigators noted that the victim possessed the ability to discover the breach had they had they been more diligent in monitoring and analyzing event-related information [AC - i.e. logs] available to them at the time of the incident." and this "Furthermore, a crime scene devoid of any network and system logs, a key resource for computer forensics, is a disturbingly common occurrence."
What can I say? Back to battle stations for me - to fight the war of making logs more popular! :-)
I saw this idea of a monthly blog round-up and I liked it. In general, blogs are a bit "stateless" and a lot of good content gets lost since many people, sadly, only pay attention to what they see today. This is what is driving an idiotic campaign of such "news" as "hackers increase hacking", "compliance is hard/easy/matters/doesn't" or "awareness of virtualization/SaaS/hacking/compliance grows."
So, here is my next monthly "Security Warrior" blog round-up of top 5 popular posts and topics.
See you in July!
Possibly related posts / past monthly popular blog round-ups: