On Vacation

Just a note: I won't be blogging until Jan 3rd since I am on vacation catching some snow. Response to blog comments will also be somewhat sluggish.

So, see you in 2008! Happy New Year!

Review of My 2007 Security Predictions: Too Wimpy

It is time to check how my last year's predictions (My Security Predictions for 2007 ... Go!) fared. I am shocked that many of my colleagues looooove to predict, but seem to shy away from reviewing them in the end of the year (big ego - small 'you know whats'? :-))

So, one liner summary of status of my 2007 predictions: they were too wimpy. In more detail ...

PI. Platforms: Vista will have no impact on the overall risk level of most organizations out there. Yes, some holes will certainly be plugged (and I even agree that "Vista is the most secure version ever", just like every single one of its predecessors was - in its time), but others - possibly of types we don't even know about - will crop up. Sorry, but secure platform =/= secure Internet (kinda like you wearing a Kevlar vest doesn't lower crime in the neighborhood).

Status Check 1:  This is correct, for sure. In fact, Windows Vista made no impact on security not because it has security flaws (and it does), but because nobody really adopted it. Calls to "upgrade Vista to XP" are heard loud and clear ...

PII. New technologies: no credible technology that can alone "solve" the problem of insider threat will emerge (many will try); the insider threat problem is just too broad, diverse and rich to be solved by a single technology or even a single vendor (corollary: if somebody is trying to sell you such a technology that claims to do exactly that on its own, then - well, you know what to do ...)

Status Check II: This one was kind of a no-brainer and way too safe a prediction. Of course, it didn't emerge! It is impossible to have one technology (or even: only technology) to stop a dedicated insider. However, log management helps since it allows you to know what they actually did and how they stole all your secrets :-( with painful level of details (if you have logging enabled, that is)

PIII. Security market: we will see more than a few firesales and possibly total and miserable security vendor failures (wonna bet which legacy SIEM vendor will die first? :-)) There are way too many companies who sell some random and often irrelevant "protection" which sometimes doesn't even work ... at their own demo ... when their CTO demos it ... the third time ...

Status Check III: This is kinda true (here, here, here), but not to the extent I suspected. Some of the walking dead are still, well, walking. And no less dead :-( In 2008?

PIV. Risk management: a confusion about what is "risk management" will not subside this year. Business risk? Information risk? Risk as threat x vulnerability x asset? Risk as probability of loss? Arrrghh! - It goes on and on and on. No standard accepted definition of risk management in the field of infosec will emerge.

Status Check IV: This is also a wimpy prediction, since it is so obviously true. The concept of risk is still a mystery to many in security (e.g  see this survey) and it will likely remain so for a while. Puleeease! :-)

PV. NAC: of course, no list of 2007 prediction is valid without mentioning knack :-) And you know what? NAC will shrink, NOT grow in importance this year! This is where the rubber meets the road and fish start to swim upstream :-) - this prediction started from me reading Richard's piece "NAC is Fighting the Last War" which struck me like a Strength 15 Lighting Bolt. Indeed, narrowly defined NAC largely targets worm infections (and will thus lose relevance) while broadly defined NAC starts to sound like having a well-run network (which is as relevant today as it was in 1992 and probably 2012 as well). The Planet NAC is about to experience a premature eclipse :-)

Status Check V:  Yes, bingo!!! I am proud of this one, since it was pretty contrarian: NAC didn't become much clear and adoption reportedly slowed down. Small vendors scatter, larger ones repurposed NAC tools.  NAC - in whatever shape or form - will become more common, but only after it sinks into the "trough of disillusionment", pardon my Gartnerese :-)

PVI. 0-days: 2006 was the year when this previously obscure term fell victim to malignant marketeers. 2007 will see more of the same, no doubt. But what about the real 0-day-wielding attackers, poking jokes at the above "oh-day defenders"? Security research into new types of vulnerabilities will certainly continue and more types of previously "safe" (rather, "erroneously thought of as safe") types of content will be used to attack applications. MPG with 0day? AVI with 0day? And, our old friends doc, xls, ppt and now PDF. On the other hand, a major 0-day worm still won't happen.

Status Check VI: Correct, but then again - it was a little on the soft side as well. No 0-days worms. PDF hacking - check. And, in fact, less noise about "we protect against 0-days" (because they likely don't). However, I should have added that technologies that only protect against a few known "baddies" will experience reduction of efficiency ...

PVII. IP and ID theft, data loss: at the risk of sounding hilariously obvious, I would state that such incidents of ID theft (phishing, etc), broader intellectual property (IP) theft and loss will continue largely unabated. Will we, the security community, try to stop it? Of course, but nowhere near hard enough ...

Status Check VII: This has definitely gotten worse, as predicted. TJX? VA? UK events? Many others? And yes, it was hilariously obvious to say this :-)

PVIII. Compliance: but of course! Did you think I'd miss this bad boy? Mandatory regulatory initiatives that pack a bite or a punch, such as PCI, will continue to spread and thus grow in importance, while jokes like HIPAA will continue to languish, helping my # VII prediction come true with a bang ... At the same time, I am undecided on the voluntary frameworks that you can choose to comply with (ISO17799/270001, COBIT, ITIL, etc) - will they take off like a rocketship or remain steadily interesting to some? Only time will tell.

Status Check VIII: PCI DSS continued to rage (despite TJX and other faux pas :-)), even some retailer backlash was seen. On the voluntary side, some say ITIL is emerging, other swear by ISO27xx1 series, but I still don't see the rush to adopt the frameworks en masse, at least not in the US.

PIX. Security awareness: well, security awareness will ... ah, come on, just laugh: bua-ha-ha-ha-haaa :-)

Status Check IX:  No comment! Actually one: malware zipped with a password which requires the user to enter it and unzip it. Stuuuuuuuuupid! And, do remember the "WSJ saga" , which probably blew away years worth of your awareness efforts ...

PX. Finally, I would like to reiterate a few of the last year's predictions that will still ring true this year. Client-side and application-level (especially, web application) vulnerabilities will still be outrunning the server-side and platform-level ones. Major wireless attacks and malware will still not destroy the world.

Status Check X: Yes, client-sides beat server-side vulnerabilities. Yes, app vulns beat platform vulns. Come on, what else is new? :-)

Stand by for my 2008 predictions! All Hail Futurism! :-)

All past predictions from various people and groups for 2007 that I've seen are tagged here. A fun read now!

All future predictions from various people and groups predictions for 2008 that I've seen are tagged here. A fun read a year from now? :-)

Technorati tags: security, predictions, future, 2007

More on Security vs Risk

So, I was reading some survey and came across this bizarre, mind-boggling (maybe even 'mind-numbing?') picture:

How can security be THAT disconnected from risk? Can somebody explain this to me? (Please don't explain by stating "crappy survey methodology" - I can pull this one myself, thank you very much :-))

Mr Hoff, can you help here? :-)

UPDATE: I have a full PDF of the report; can email if interested!

UPDATE2: a lot of fun discussion inspired by this post is here.

UPDATE3: more discussion here where the model "(strategic = risk) vs. (tactical = security)" is used.

Wow, This IS Screwed!

Wow, this IS bad: "Why all Vista users should upgrade to Windows XP"

So, Q1: have I seen a happy Vista user until today? Not one!
Q2: Did Vista launch create a huge boost to Mac sales? Sure seems like it.
And Q3: Will we ALL (apart from Linux and Mac crowds) use Vista in 2 years? Sadly, yes.

Such is the power of a monopoly...

Spaf on Academic Security Research (... Silliness)

Spaf also laments academic security research. He says: "As I write this, I’m sitting in a review of some university research in cybersecurity. [...] What strikes me about these efforts — representative of efforts by hundreds of people over decades, and the expenditure of perhaps hundreds of millions of dollars — is that the vast majority of these efforts have been applied to problems we already know how to solve."

Hell yeah!!! More people want to invent NIDS, honeypots and secure OS than I care to see. Why? WHY? W-H-Y? There are so many worthwhile security problems that will benefit from a rigorous academic approach, but people still pick their research topics off the dirt pile ... Take security economics, for example.

Possibly related posts:

• Once More on Failure of Academic Research in Security

But What Does It ACTUALLY DO?

A great follow-up to my post On Security Marketing: Marcus Ranum rants on what stateful firewalls "actually DO." He says:

"One of the fun questions I used to ask my firewalls tutorial
attendees (back in the day) is: What is a stateful inspection firewall? I.e.: what does it DO?

The answers are usually illuminating. Nobody seems to actually know." (more here)

I think if you are buying a security product, you should always know WHAT IT ACTUALLY DOES!

And if you hear, "Oh, it does, you know, 'risk management'!" - you know what to do (hint: it includes a rotten egg, throwing and running away - in whatever order you prefer ...) :-)

UPDATE (12/22/2007): this is NOT about stateful inspection, this is about a) bad marketing and b) opaqueness of some security vendors about what they do. Come on!

Possibly related posts:

• On Security Marketing

Just a Fun Read and App and Data Security

An interesting piece from Rich Mogul called "Data And Application Security Will Drive Most Security Growth For The Next 3-5 Years"

Not super-new, for sure, but nicely said!

Correlated Compliance Tables

Fun correlated mega-compliance table is here.

SANS Top20 in 2007: What's The Verdict?

SANS Top20 for 2007 was out for a while and it already gathered a lot of interesting responses. See some comments here, here ("sans top 20 has lost its flavor"?)

So, did we do a good job this year? Can we? Has the job become impossible? How can we make it better next year? Should we continue doing it? Or is "everything" really the answer? (as in SANS Top1 Risk "Everything!")

Poll: Who looks at logs in your organization?

Here is my next poll about logs: Who looks at logs at your organization?

Vote here!

Also, my past polls and analysis are here.

How to Do Database Logging/Monitoring "Right"?

So, people sometimes ask me about how to do database logging/auditing/monitoring and log analysis right. The key choice many seem to struggle with for database auditing and monitoring is reviewing database logs vs sniffing SQL traffic off the wire. Before proceeding, please look for more background on database log management, auditing and monitoring in my database log management papers (longer, more detailed - shorter) The table below summarizes the situation with database monitoring and auditing - now you can make your choice more intelligently (items in bold are the ones I consider key):

	Pro	Con
Sniff SQL traffic from the wire	No database performance impact Awareness of returned content (for SELECTs) Guaranteed role separation Better for DBA monitoring No agents No database configuration changes	Extra device needs to be purchased, deployed and managed Doesn't work with encryption No local access monitoring
Collect and analyze database logs	No extra $$$ - use your existing logging tool Can user review activity across log sources, from databases to servers Satisfies compliance demand for "database log review" Can monitor ALL access to data in the database, even over APIs and local	Performance impact possible (*) Database config changes needed Usually not truly "real-time" (polling)

Choose logs if you care for the relevant Pros (esp key ones) associated with them; choose sniffing if you care for the Pros and are NOT undermined by their Cons (e.g. lack of support for encrypted traffic)

Comments? Additions? Concerns?

(*) Nobody really knows what it will be in each particular situation: 0-40% were observed under various conditions by various people ...

Technorati tags: log management, logging, database, security

UPDATE: Rich adds his option #3, but I am skeptical since it is not very sexy. Dedicated agents on each databases just aren't that exciting...

OMG, This Is So 20th Century :-)

SANS folks debunk the old idiocy “There is nothing on my computer that a hacker would be interested in”

Holy chao! :-) I was hoping that people - by now!!! - would already know that their CPUs, disks, connections are pretty useful to criminals .... And, yes, so is their data!

Forward the SANS piece to all you non-computer / non-IT friends ... (sadly, some IT folks too ;-))

Wow - AI Bot Phishing! Cool!

Picked from SANS Newsletter: "--Russian Chat Bots Gather Information
(December 10, 2007)

An artificial intelligence program circulating in Russian chat forums
flirts with human users in an attempt to get them to divulge personally
identifiable information. People have fallen prey to CyberLover because
it is difficult for them to tell that they are not talking with a real
person. The program can create up to 10 relationships in 30 minutes,
and assembles dossiers for each relationship that include names, contact
information and photographs. So far, CyberLover has just been spotted
in Russian chat rooms, but others are urged to use caution while
chatting." (original source here)

Wow, this is cool! Does it just match your perceptions about what the life in the 21st century would be like? :-) Robots stealing from people - how crass :-)

And, pleeeeease, don't just respond this "people are stupid" :-)

Weird (Is It, Really?) Piece About PCI

This reports that "the best-in-class retailers are lagging behind in PCI compliance." Some interesting analysis is also provided (as well as links to research!)

CEE Finally Official

After all the discussions, the official website is up: cee.mitre.org.

Logging Poll #3 "What Do You Do With Logs?" Analysis

So, the results of my 3rd poll are ready: live results are here, picture is also in this post. This sure was fun!

First, this poll way more popular than my previous "why" poll. Yes, it seems like people do hate to wonder "why" :-)

Second, what are  the two choices, that are by far the most popular? They are:

• Store raw logs on a server (23%)
• Search raw logs (grep) when needed (24%)

Yes, this is the "state of the art" of logging:   collection of raw logs and "as needed" grep aka "slow and painful" search. In fact, the above answers might not even be given by the same people: some might be grepping logs on the individual servers, while others collect them on syslog servers and never touch them. That is why being in log management business is such a great thing: you have nearly the whole world to evangelize about the value of logs and log management tools.

Third, what's the next most popular idea of analyzing logs? It is "Run my own log analysis tool" at 10% of the respondents. Indeed, the movement started by the "enlightened" Leopold von Sacher-Masoch  still lives and thrives: people choose the Build->Suffer approach to log management often enough ...

Fourth, next come my somewhat self-inflicted surprise: apart from commercial log management (at 4%) and rolling one's own (discussed above at 10%), I added the option of "Use other log analysis tools"   which captured 7% of the vote. But what does that mean? I have no idea!

Fifth, I am NOT surprised by the lack of popularity of the rule-based correlation tools, such as SIEM (at 2%). When I made my decision to join LogLogic, I had to ponder this one really, really hard. Sorry to use this post to rant, but my conclusion at the time (which is also valid now) was that "SIEM is for some, log management is for everybody." This poll confirms this further.

Finally, all my logging polls and analysis are here. Next one is coming up!

Technorati tags: logging, polls, log management

Again, On Criticality of Logs

I just wanted to highlight two pieces that, again, speak (No, scream! In fact, S-C-R-EA-M!) about the important of logs. Yes, my readers don't need additional motivation to take logs seriously, but these are just too cool to pass.

First is the interview with some convicted attacker, who said: 'Moore said it would have been easy for IT and security managers to detect him in their companies' systems ... if they'd been looking. The problem was that, generally, no one was paying attention.

"If they were just monitoring their boxes and keeping logs, they could easily have seen us logged in there," he said, adding that IT could have run its own scans, checking to see logged-in users. "If they had an intrusion detection system set up, they could have easily seen that these weren't their calls."'

Amen to that, many of the successful and then-undetected attacks are due to stupidity, incompetence which pretty much equate to bad "risk management" decisions (for whatever meaning of "risk"). Why? 'Cause lacking logs and ignoring logs is indeed stupid!

Second, is my comment on the TJX case, which kinda follows the same idea: 'Dr. Anton Chuvakin, a security expert with LogLogic, said TJX didn't have decent logs. "What took TJX months was looking at all their systems and determining who took what data, from where, where it was sent, etc. The investigation took them months. They likely didn't have any logs, because they had to do system forensics rather than log analysis to arrive at their conclusions about who stole the data and how. If they had collected and analyzed log data centrally, the investigation would have been a piece of cake," he said in an e-mailed comment to InternetNews.com.'

Indeed, doing disk forensics to know who did what is waaaaaaaaaaaay more painful than checking reliable logs. Save yourself by logging, then saving and reviewing the logs!

So, one more time (not the last, mind you!):

• Make sure you have and collect logs (here are 11 reasons for that)
• Make sure you look at logs (here are the 11 reasons)

Technorati tags: log management, logging, security

Morbid is Cool?

I just loved the quote from this which covers a request to provide a high-powered laser weapon to target insurgents from a distance: "A precision engagement of a PID insurgent by a DEW [A.C. - stands for Directed Energy Weapon] will be a highly surgical and impressively violent event. Target effects will include instantaneous burst-combustion of insurgent clothing, a rapid death through violent trauma, and more probably a morbid combination of both."

Also read the comments below - many are fun.

Dedicated to all people with a sick sense of humor :-)

DMCA vs MPAA: Alien vs Predator :-)

OMG, this is just awesome - quoted from Rich Mogul's blog: "The MPAA illegally used GPL licensed code in their University Toolkit (the license required release of the source code for any derivatives). They refused to respond to requests to comply with the license, and a developer issued a DMCA takedown notice to the MPAA’s internet service provider, who shut down the site."

Who Benefits from Log Standards? Part II - Application Developers

As I promised, I will post another blurb on log standards following the first: Who Benefits from Log Standards? Part I - Log Management Vendors

Just as the previous one, this comes from the still-upcoming CEE whitepaper (yes, official website is still upcoming as well). Here is the quote that covers the benefits of log standards (in this case, CEE):

"Event Producers (vendors & products)  [A.C. - i.e. platform and application software vendors as well as network gear developers whose products generate logs] will be able to decrease cost associated with logging and reuse log libraries. Vendors could move away from encouraging developers from picking log messages on a closest-fit basis from a limited, product-specific message index. Furthermore, the generation of these log messages could be bases on a single API call. Also product interoperability will increase with the others who speak with the same event expressions, resulting in satisfied customers. "

So, in other words, it is not only the  log management people who will benefit: software vendors will have an easier life with logging; this applies even more to smaller vendor and even in-house IT teams who often (always?) struggle with how to do logging right in their applications ...

Technorati tags: logging standards, log management

Celebrating My "Blog Birthday"

Today is my "blog birthday" - two years blogging. Here is my first post (nothing special, but the missing of my blog has certainly changed from that day in 2005! :-))

UPDATE: BTW, my real birthday is also coming up ... fast!