Friday, December 29, 2006
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 ...
4. Application-level vulnerabilities will grow, service-level ones – shrink (5,4)
STATUS as of 12/22/2006: Correct (see recent SANS Top20 for some illustration); the decrease in network-service level vulns was dramatic, but SQL injection, XSS and other stuff grew like mad.
5. Client (web, mail, chat, etc) attacks will rise and server attacks will fall somewhat (4,5)
STATUS as of 12/22/2006: Correct (see recent SANS Top20 for some illustration), but no credit really - this one was trivial to predict.
6. Major wireless and mobile threats will not come (4,3)
STATUS as of 12/22/2006: Correct (but, again, I see this as an easy one)
7. Endpoint security solutions and NAC-like technologies will experience sharper increase in adoption than other security tools (3,4)
STATUS as of 12/22/2006: Correct; again, if we measure by media buzz levels and [late] company launches, NAC and endpoint security is still heating up
8. Finally, I predict that just as one cannot predict the threats of tomorrow today, one still won’t be able to do in 2006 :-) (5,5)
STATUS as of 12/22/2006: but of course! Indeed, there are many things that I am pretty sure we would all love to predict but just as unanimously missed.
So, I officially upgrade myself to Chief Security Nostradamus :-)
Wednesday, December 20, 2006
Tuesday, December 19, 2006
But - guess what- I will be a party pooper and will hold on to mine.
Feel free to see what I collected so far: security predictions 2007 tagged at del.icio.us
So, no, I am not posting my predictions just yet. In this prediciton game, you know that whoever waits the longest (preferably to the end of 2007 :-)) wins (i.e. looks like less of an idiot :-))
"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
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! :-) )
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.
“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
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 :-)
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?
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)
Unfair? And so is life...
Following the new "tradition" of posting a security tip of the week (mentioned here, here ; SANS jumped in as well), I decided to go along and join the initiative. One of the bloggers called it "pay it forward" to the community.
So, Anton Security Tip of the Day #6: The Other Web Log
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.
[Sun Mar 12 04:02:05 2006] [notice] SIGHUP received. Attempting to restart
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
[Mon Mar 13 14:54:11 2006] [error] [client 10.10.10.10] Premature end of script headers: index.htm
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:
[Mon Mar 13 14:54:26 2006] [error] [client 10.10.10.10] attempt to invoke directory as script: /var/www/cgi-bin/tcpsupport/
and so is this one:
[Mon Mar 13 14:54:23 2006] [error] [client 10.10.10.10] (8)Exec format error: exec of '/var/www/cgi-bin/tcpsupport/main.htm' failed
Other interesting things spotted on the same server -this one looks like an overflow attack attempt (and, no, the NIDS did not make a squeak about it)
[Thu Mar 19 07:16:11 2006] [error] [client 10.10.10.10] request failed: URI too long (longer than 8190)
So, to conclude, the tips is: when doing web server log analysis, make sure you look at the error logs as well as the access logs.
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...
Thursday, December 07, 2006
Tuesday, December 05, 2006
Monday, December 04, 2006
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!
Read it; I won't spoil the conclusion for you here, but it is pretty much what you'd think :-)