So, Mike Murraybrings up this fun point: ' My favorite way of asking it: "What, if your company [...], would be a complete deal-breaker for you? What would make you completely disengage?"'

I'll bite, Mike: one of the truly disgusting things (which would make me reach for my resume in a second) would be for a [security] product company to use a competitor's product to protect its own network. Don't laugh (please cry, in fact!), this stuff actually happens...

I am sure that decent companies run their own stuff and Snorts happily protect Sourcefire's network while Proventias guard ISS (and now IBM) from evil attackers, thus telling the world that their stuff is indeed the best for them as well as their customers. However, what in the whole wide world would make you buy security gear from somebody who prefers some other brand to his very own? And what would make you work for such a company [well, maybe a fat salary will :-), but that is a separate story]?

A milder version would be to simply shy away from using its own product, because it is so "enterprise-grade" that a small company (such as its creator) will not benefit from using it internally. It is a bit less disgusting and credibility-busting, but it smells pretty darn bad as well...

Wednesday, December 27, 2006

Specifically, "Gabriel" said that server attacks have not fallen. Indeed, I would agree that a rise in web application attacks more than covered a drop in server platform software attacks so we are kinda both right (I should have said "server platform software attacks dropped" and not "server-side attacks dropped"). Thanks to "Gabriel" for noticing and clarifying it!

Also, he is just as correct in stating that wireless driver attacks have emerged from the underground. However, I would still claim that wireless attacks have not become anywhere near widespread as worms and virii :-) hits of the 1999-2003 or spyware infestations of 2003-2006.

Also, the next step in my track to highly-awaited 2007 security predictions (I am NOT posting them yet!) would be to pick on somebody else's. Maybe it is just my mood today, but I am very eager to call somebody a dumbass for predicting something truly ridiculous... :-) Stand by for that!

Friday, December 22, 2006

1. Viruses, worms, bots and spyware will remain the main concern; malware commercialization will continue and thus propel more money-making technologies such as spyware (5,5)

STATUS as of 12/22/2006: Correct (but it was a reeeally easy one)! Recent polls still show that malware tops the charts (even though various forms of regulatory compliance, IP theft [as some has us believe] are challenging that)

2. Data/IP theft and especially ID theft will continue and increase in both severity and occurrence (5,5)

STATUS as of 12/22/2006: Correct (at the very least, the buzz levels about this are skyrocketing); phishing and identity theft - as a type of IP theft - were certainly growing and so was the IP loss in the form of laptop loss.

3. At least one major 0-day compromise story will surface, maybe with Oracle software (5,4)

STATUS as of 12/22/2006: Correct (see recent MS Word 0day stories); Oracle bugs were aplenty, but nobody admitted that they were owned thru one ...

Wednesday, December 20, 2006

Don't you just hate it when you have to parse logs that look like this 'ThiseventcontainsREPAIRPROCEDURESforthe1084eventwhichhaspreviouslybeenlogged. ThismessageindicatesaspecificissuewiththeconsistencyoftheActiveDirectorydatabaseonthisreplicationdestination. Adatabaseerroroccurredwhileapplyingreplicatedchangestothefollowingobject. Thedatabasehadunexpectedcontents, preventingthechangefrombeingmade."

Tuesday, December 19, 2006

So, to throw those waiting for my 2007 predictions off the track, I will post my predictions (sort of) for 2004 :-) It is my old SANS presentation on "What is NOT Working in Security 2004;" yes, old it might be, but it is still a fun read.

OK, it looks like I just have to respond to this. The claim was made that one has to unleash his or hers (hmmm...) security predictions for 2007 immediately.But - guess what- I will be a party pooper and will hold on to mine.

At least, PCI compliance is: where else you can win a large bonus cash prize for doing something that is mandatory (and you'd be fined if you don't do it)

"Earlier this week, the company announced that it has created a new $20 million incentive program under which it will monetarily reward "acquiring" financial institutions if their members are fully compliant with PCI requirements by Aug. 31, 2007. At the same time, acquiring banks that fail to ensure compliance by Sept. 30, 2007, will be assessed fines starting at $5,000 a month for each noncompliant merchant. The fines increase to $25,000 per month for each noncompliant merchant after Dec. 31, 2007."

Friday, December 15, 2006

Isn't embarrassing when someone posts a guide on how to secure a database and doesn't even mention logging and audit logs? It sure it, but at the same time it shows something pretty pervasive and unfortunate: many folks who run database have no idea who does what with the data (and, to a lesser extent, with a database itself) since no logging is enabled, with the possible exception of logging major failures with the database software itself.

DBAs who don't care about data in "their" databases is a sad phenomenon indeed. But then again - somebody got to help the incident response consultants to get rich! And the media needs constant flow of hotter and hotter breaches and data thefts! Go ahead, help these folks, continue to ignore logging on your database and reap generous rewards, such as seeing yourself on CNN (right before you "see yourself" on a pink slip! :-) )

So, this ancient blog post stated that "80% of wifi networks [are] insecure" ( and points to a Slashdot interview with the author of Kismet). The date on the post is 08/20/2004; more than 2 years ago. And a funny thing happened - wireless networks actually gotten more secure! Nowadays one can't be certain that he would see an open wireless network whenever one sees a bunch of wireless networks somewhere...

As similar things happen in other areas of IT, the specter of security being done is being raised once again. But - guess what? - the answer is still NO.

This sure makes one think so, what happened to common sense and basic kindergarten physics ...

“Imagine a plane is sitting on a massive conveyor belt, as wide and as long as a runway. The conveyor belt is designed to exactly match the speed of the wheels, moving in the opposite direction. Can the plane take off?"

Now, how many of you would NOT be able to answer this within, say, 30 seconds (I am being generous here)? Such people should please read Darwin and then try to remove their genes from the humanity gene pool in whatever manner desirable and ASAP!

One piece even called this "a brain-teaser" - yeah, maybe, if you lack the very organ mentioned above :-)

Thursday, December 14, 2006

As you, my dear readers know, I sometimes like to point at really, really stupid things that I see in our domain. Here is one: "Vista will force need for network forensics."

This security VP from CA (you can start laughing now, but please wait for a punchline) claims that "Encryption by default means that without user credentials it will no longer be possible to investigate user behaviour at a disk level." thus "The result? Network forensics is rapidly becoming the next big thing in IT security."

So, who can name more reasons why this pathetic attempt to sell "CA Network Forensics" product is laughable?

Here is one reason to rule them all: network encryption is here NOW, disk encryption is coming in the FUTURE. Thus, if disk encryption will break disk forensics, than network forensics is broken already...

BTW, looking at logs for forensics will always be useful - but that is another story altogether :-)

So, this has been making rounds for a few days already after yet another (and then two more...) 0day in MS Office was discovered, but it got me thinking. The issue is that some orgs (NASA is mentioned here) chose to "block the receipt of Microsoft Word documents coming in to the space agency's core computer network as e-mail attachments" this time.

Would you do this? Or will your business units eat you for lunch and have nothing left for dinner? Now, almost everybody blocks EXE and COM as well as VBS on their gateways and it is seen as a reasonable practice. But DOCs?

I admit I am late to this agent-slamming party started by Matasano folks, but I want to play "kick an agent" as well :-)

So, I've yet to see a person who willingly says "yep, I wonna go and deploy agents on all of my 23,000 servers and desktops" even if he KNOWS that he will get a sizable benefit as a result of doing it (and, sometimes even when said benefit is not achievable without all those agents)

We all know that Apache web server has its access_log log files while IIS has its w3c logs. When people think about web log analysis, they think about the above and only about the above logs, often calling them "the web server logs." However, the other web log - error_log (in case of Apache) - contain a lot of fun and useful info as well. Today's tip is to encourage the review and analysis of this treasure trough - pardon the idiom - of insight.

So, what goes into the error_log? Well, errors, duh! Why errors matter? 'Cause errors often present the only indication that a) you are being 0wned or, worse, that b) you've been 0wned by the attackers. Additionally, apart from the obvious security usage mentioned above, errors matter since they - or rather, some of them - require actions by the user and thus knowing about them is of huge importance. What is even more striking is that many error messages present an interesting tradeoff - do only a little now to correct the reasons (or, "the root cause" as network management people would say) for the error, or do a whole lot later when the system crashes, gets hacked or "misbehaves" in some other truly spectacular way. Now, a grizzled BOFH would surely say "heh, but who would want to do that! surely, dealing with a dramatic world-ending catastrophe later is more fun that making a minor config fix now." Well, I sincerely hope not all of my readers are such people :-)

Now, back to the Apache errors; we are going to show a few examples from a live phishing site, run by the attackers on a compromised server. We will start from the obvious - server restart, which actually happened as a result of an attack, in our case.

Did YOU restart the server? No? Two choices then - someone else did (likely without permission!) or the server got restarted automatically for whatever strange reason. You certainly need to be at least somewhat concerned in both cases - thus: look for the above messages.

Here are a few more fun examples - the relevance of those for your business is left as an exercise for the readers, but all of the messages below

Does "index.htm" sound like a script to you? It sure should not; and this error message indicates that somebody is trying to run it as a script - a clear indication of malicious behavior. The next message is also similar in this regard:

This piece, even though it borders on being content-free at times :-), has a few fun insights on logging and audits (some painfully obvious to us logging people :-))

For example: "Does the fact that audit logging is enabled satisfy all the different regulatory compliance requirements? [...] In all but the most generic cases, the clear answer to this is no." But of course! Having logs is great, but looking at them is awesome (and sometimes required - see PCI Requirement 10)!

Or this "gem" - "The problem is no one looks at these logs unless something bad happens" which goes straight back to my famous (and old) "Five Mistakes of Log Analysis" paper (an update, called "Six Mistakes of Log Management" is to be published soon) Having a log management solution solves this one nicely.

Or this one: "Audit logging is not just for compliance reasons." Guess what, every sysadmin worth his salt have known this for, say, 20 years :-)Overall, the piece is much better at asking questions than giving answers. Seriously, is this true: "What do you log? Do you look at successes and failures? How vulnerable are your logs once they've been written? How long do you keep your logs? Only you can answer those questions." No, there are pretty good answers already given to the questions above. Such answers are given in various regulations (some mentioned in the article) as well as "best practice" and IT governance frameworks, such as COBIT, ITIL and various ISO docs.

Mike Rothman kicks it as well by saying "Kevin Beaver beats the horse a bit too much about why you should log (providing the regulatory context) and not enough perspective on how you should do it."

In any case, I liked the blurb since it helps to bring awareness of log management to those still hiding from it under their desks...

Tuesday, December 05, 2006

Here is one more of my old gems: a presentation on Linux Intrusion Discovery.... This presentation from a couple of years ago covers how to discover the common signs that your Linux system is compromised by attackers (yes, it has stuff on logs as well, of course, but not as much as I wanted - maybe I will create something separate in the future)

Monday, December 04, 2006

Here is a bizarre story, related to log management. "The highest appeal court in Germany has decided that T-Online, one of the largest German ISPs has to delete all IP logs to guarantee the privacy of their customers."

Obviously, all I know is the press story, but it sounds weird enough to mention. Moreover, here is how it works, reportedly.

"The decision (German) does not mean that T-Online is now obliged to delete all their IP-logs, the customers first need to complain. "

So, lemme understand, the logic is "surf to an illegal website -> complain to an ISP -> have the proof of that removed." Neato! The only thing that mitigates it is the fact that many ISPs would not have retained the logs anyway ...

And it ends with: "After the district court and the regional court, now the federal appeal court decided that T-Online has no right to store the IP-logs without a legal reason." [whatever such reason might be]

It also seems directly related to this piece of mine on "Access vs Access + Audit." I also wonder what happens if some regulations call for log retentions while others for log destruction and you are subject to both. Aaaah, compliance is so much fun!

Just a fun read - here is quote: "Bottom Line: By the end of 2007 stand-alone AV will be dead, d-e-a-d, dead! Organizations need to evolve their client security programs or expect to see increased costs as the number of agents continues to rise."

Here is another fun old preso of mine: "FTP Server Intrusion Investigation." Now famous FTP server intrusion investigation, including log analysis, disk forensics as well as lessons learned; all still fun and useful, but circa 2002.

About Me

He is a recognized security expert in the field of log management and PCI DSS compliance. He is an author of books "Security Warrior", "PCI Compliance", "Logging and Log Management" and a contributor to "Know Your Enemy II", "Information Security Management Handbook" and others. Anton has published dozens of papers on log management, correlation, data analysis, PCI DSS, security management, honeypots, etc . His blog securitywarrior.org was one of the most popular in the industry.

In addition, Anton teaches classes (including his own SANS class on log management) and presents at many security conferences across the world; he recently addressed audiences in United States, UK, Singapore, Spain, Russia and other countries. He worked on emerging security standards and served on the advisory boards of several security start-ups.

Before joining Gartner in 2011, Anton was running his own security consulting practice www.securitywarriorconsulting.com, focusing on logging and PCI DSS compliance for security vendors and Fortune 500 organizations. Dr. Anton Chuvakin was formerly a Director of PCI Compliance Solutions at Qualys. Previously, Anton worked at LogLogic as a Chief Logging Evangelist, tasked with educating the world about the importance of logging for security, compliance and operations. Before LogLogic, Anton was employed by a security vendor in a strategic product management role. Anton earned his Ph.D. degree from Stony Brook University.