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 :-)
Thursday, November 30, 2006
My brother-in-law just bought a used Intel 20" iMac. The seller was a nice looking blonde, who didn't wipe the disk."
[dramatic pause] :-)
Well, Andy discovered the mischief by looking at the logs, but what if the logs weren't there (happily rotated away or erased by the attacker)? Doesn't it just fill you with dread and make you run, not walk to all your systems and cranking the logging up, way up? And then, of course, buying some log management to handle the resulting volume ... :-)
Wednesday, November 29, 2006
First, bear with me since I am still trying to build a coherent picture of security ROI for myself from all the diverse sources of info, some as smart as Pete Lindstrom :-) In general, I am leaning towards "there is no ROI for security; there are only cost savings" (which, as my in-house Ph.D. economist stated, are neither the same nor equivalent)
So, let's see, what is this guy suggesting: "If security spending exceeds 10%, your business architecture is probably poorly designed to cope with attackers." Huh? What's up with the magic number? So, 9.5% certifies you as OK? Sounds like an application of "all hard problems of the Universe have easy, clear and simple INCORRECT solutions" :-)
Further, "If the cost of your security investment is 200% or more of the value of employee downtime, you may be spending too much on security." Same problem - see above, bro.
Going down, "If you are experiencing a loss of 1% or more in productivity, review how you are protecting your information." No comment, really. Wait, one, actually: bullshit.
And, on top of the above, I just hate it when people proclaim something truly obvious as if it were some kind of news, so this guy definitely commits this crime: "The goal of total security is not achievable in complex systems that have millions of hardware and software vulnerability points." Wow, that's deep, good thinking here... NOT! :-)
So, I am with Mike on this one and he said it best: "These "metrics' will do nothing but waste your time, except maybe the gauging the cost of downtime one. I can only hope your CIO didn't read this drivel, because then you'll start to see this crap on your 2007 MBO's."
As usual the log volume is called out as the primary reason for behaving stupidly ("In fact, most IT and security pros have so much log data that they typically only skim it, or ignore it altogether.") BTW, I am preparing a longer post to illustrate just how much data that can be...
At the same time, it is certainly nice that DarkReading chose to quote the experts in their piece :-) Even though their obsession with NBAD (in this context) is puzzling... They also seem genuinely confused about the relationship between SIEM/SIM, NBAD and log management.
- "Physical security
- Proper disposal of devices, storage media, and sensitive documents
- Background checks
- Getting control of the at-home user
- Taking advantage of built-in security functions
- Analyzing trends in security log files
- Outsourcing of security functions
- Integration of security with software development"
Tuesday, November 28, 2006
1. "80% of security attacks are due to insiders."
2. "80% of security loss is due to insiders."
3. "80% of statistics are made up." :-)
Should we completely scrap this 80% beasty or is there any truth in it, after all? Recently I've seen a discussion on one mailing list where some pretty darn smart folks swore that they can personally attest that one or the other version of the above is "absolutely true."
So, any defenders/attackers of the above?
Monday, November 27, 2006
Here is how it starts: "Imagine that several centuries hence, anthropologists uncover a hoard of archived tapes containing terabytes of firewall log files recording events from the last decade of the 20th century and into our present day (2006). Now imagine that they discover how to read the media and open the log files."
Read on for laughs, but not only for those. There is enough sad truth in the conclusion ...
a) fighting nefarious hackers
b) protecting information
Now, if you ask as many of our colleagues about this, do you think you'd have more of "a)"-people or "b)"-people? Any bets on the percentages?
Just a random thought of the day...
Friday, November 17, 2006
So, is humanity incurable? :-)
I love both quote and the concept : "Feel like you've lived a wee bit too long? Looking for a spectacular way out -- one that'll keep your family crying in disgust for years on end?"
Yeah??!! Try this new means of transportation: a personal helicopter.
Image borrowed from: http://www.defensetech.org/archives/002980.html
"As far as the nature of the [SANS Top20] list goes, it's important to realize that it's based on a bunch of people's opinions."
For whatever reason, some people took offense in this (e.g. here), but why? As a SANS Top20 contributor since 2003, I can tell you that the list is certainly based on opinions and I am happy that my expert opinion was counted among others.
But guess what? When you go to a doctor, what he tells you is his expert opinion, not necessarily raw facts. He used facts, hopefully, to form an opinion. In case of SANS, the list was even called "The Experts’ Consensus", which unambiguously implies expert opinions.
Now, there is another, more serious concern being raised: that the list is not as actionable now as it was a few years ago when it contained individual vulns and CVEs. Well, this one is not true: every item still has sections called "How to Determine If You Are at Risk" and "How to Protect." So, you read the first one and act; then, if exposed, read the second one and act. Done!
Those are (quoted from his blog post):
- "Failure to maintain a complete physical asset inventory
- Failure to maintain a complete logical connectivity and data flow diagram
- Failure to maintain a complete digital asset/intellectual property inventory
- Failure to maintain digital situational awareness
- Failure to prepare for incidents"
To add insult to injury, the Infonetics opus contains a few other humorous bits: 50% of companies have deployed NAC, while the other 50% haven't cause they don't know what NAC is. Seriously!
Thursday, November 16, 2006
|Here are the results of my security conference poll, as of today (11/16/2006).|
Which information security conference do you like the most?
|FIRST (46%) |
|DEFCON (12%) |
|BlackHat (10%) |
|SANS (all) (7%) |
|Other (7%) |
|CanSecWest (5%) |
|RSA (4%) |
|Gartner IT Security Summit (1%) |
|ISACA (0%) |
|Security Decisions (ISD) (0%) |
|CSI (all) (0%) |
|MISTI (all) (0%) |
|ISSA (0%) |
|TechnoSecurity (0%) |
|226 total votes|
What are the conclusions:
1. The link to a poll was posted on a FIRST web site. I will let the reader decide the causality here :-)
2. DEFCON/Blackhat still rock!
3. SANS is great as well, presenting a close adjusted (see item 1. above) second after DEFCON/Blackhat
4. Some shows where we usually notice an abundance of fake experts presenting their rants are rated low, as they should be
5. Some Gartner folks blessed the poll with their votes :-) (Hi, Rich!)
6. Looks like I totally failed to spell out some of the popular shows, since Other category is so big (please, please, dear readers, post comments and enlighten me on this)
Obviously, the results reflect the bias of my readership selection, but, at the same time, they are not entirely unexpected...