On Mac Fans

I've watched security people being attacked by rabid Mac fanatics with some degree of envy. In fact, I was thinking the following semi-suicidal :-) thought: "just what can one do to become a victim of such attack?"

Yeah, an 0h-day in MacOS will do. Calling MacOS a "toy OS", as Dave Aitel once did (in jest!!), qualifies. But what else? Let me try this out ...

This writer here wonders: "I've been attending the O'Reilly Open Source Conference for years and have watched an interesting thing happen. A rising number of attendees have come with Mac OS X-based laptops. [...] Why? The Mac, after all, is a closed platform, just as Windows is. In fact, arguably, Apple is a more proprietary company than Microsoft has ever thought of being, controlling hardware and software alike."

I think I know why: it was all one Guy! He created and then "evangelized" a "brain virus" that created Mac fans (and then wrote a few fun books about it).

Given that I recently became a Logging Evangelist at LogLogic, I often wonder just how one can gain that kind of influence power ...

More on Robot Warfare

Pray tell me, in how many years? Will it happen in our lifetime? Just how soon?

Computer did beat the best chess player in 2001, when will the robot soldier (challenge to create one by UK MOD is here) beat the best human warfighters?

Never?
20 years?
10 years?
5 years?
When???

Somehow, I think that urban warfare is one of the most "human" (not humane, for sure ...) activities, requiring every single ability that puts humans above the machines by an unmeasurable margin (examples are intuition, gut feeling, self-sacrifice, many others ...) Yes, sensor networks, fast CPUs and "swarm intelligence" count for something, but I still think that it is not poetry or sculpture that will prove truly resistant to computerization: it is warfare!

Thus, assuming no humongous paradigm shifts in robotics or computing, I am hereby betting on "never." Any takers?

UPDATE: this here talks about armed robots in Iraq, but these are not the same. In reality, the above blog post is not so much about armed machines, but about AI making a decision to open fire. Thus, armed remote operator-controlled robots kinda don't count.

The Entire Security ROI Blood Trail

FYI, I am recording (for posterity?) the entire security ROI "blood trail" via del.icio.us here ...

More on SANSFire 2007

So, looks like I will be presenting in front of a huge crowd tomorrow: I was told that more than 200 (!) people signed up for my Lunch and Learn tomorrow.

Here is the announcement, again, just in case:

"Choosing Your Log Management Approach"
Tuesday, July 31st, 2007 12:30pm - 1:15pm

UPDATE: if you have to have a copy of the presentation RIGHT NOW, then just email me :-)

Why Some Vendor Webcasts Suck?

So, I was attending this vendor's webcast related to log management the other day and it sucked ... pretty bad.

OMG, why oh why some vendors think that their customers and prospects are stupid!? How many times a "C{T|M}O hybrid" can utter "changing threat landscape" and "you now have a legal obligation to protect information" (or even such gems of deep thinking as "success requires commitment of resources AND effort" :-) Gee, monkey, I really thought I need only resources, but not effort!) and still retain any semblance of credibility?

WTF? If his mouth is "presenting solutions" to the audience's problems, but his brain keeps thinking "buy our crap!!!," the webcast will likely result in audience being both bored and aggravated ...

I usually take offense when security pros in the trenches call vendor people "vendor scum" (or even here), but after this webcast I think I why now. Mike, please create your "Selling to Pragmatic CISO" ASAP and then jam it up the /.../of these folks!

Wireless Death

Funny, and sad at the same time, since it mimics the way information is often presented in reality ...

A Bit More on Log Management vs SIEM (and Semantics)

OK, I am using an unrelated article to go on a tangent here, but it IS an important tangent, which can save you both money and headache ...

So, this CW blog post has the following quote: "An example would be SIM vs. log management. If a client tells me that they want me to figure out a good SIEM for them, I will ask, "Do you need SIEM with correlation and alerting and all that, or do you just need something to gather your logs?" If he says, "I thought SIEM was log management," then we just avoided a semantical error. If I had just assumed that the client knew what SIEM was, then I could have wasted a lot of his and my time."

To start, here is a startling revelation: my first reaction was to kick the author of the above for that word "just" in "you just need to gather logs!" 'Cause if you can gather 75,000 log records a second for a few months and make all them quickly available, you can pretty much forget the "just" part: it is not trivial!

Overall, I've seen (and convinced!) my share of confused people. I have given interviews to explain it. I've written about it. I've quoted other people who wrote about it (e.g. browse here). Still, I see people who venture outside :-) trying to buy "a product" without clarifying this key distinction: WHAT on Earth are you trying to buy, a SIEM or a log management tool?

Here is a one-liner that will hopefully (nah, not really! not for all people! :-)) clear it:

SIEM is about "S" - security; log management is about "L" - logs.

Everybody needs log management: if you have logs, you need log management to collect and analyze them. And you do have logs, since everybody does. It is that simple. You also need log management, since some regulations (yes, that "C-word", compliance, again!) tell that you need to have it (examples are too numerous to list here).

On the other hand, unless you are very large, plan to build a SOC, have huge staff dedicated to near real-time security monitoring, you likely don't need a SIEM. Really! If you don't believe me, that's fine: just buy one without thinking how you plan to use it and be disappointed that you wasted $X,000,000 of perfectly good dollars and a good chunk of your life. At the same time, you might feel generous that you helped boost a failing market :-) Or, if you insist, you can buy a little toy SIEM or get one as a gift, which I've heard is pretty common :-)

So, if you are looking to collect, retain, review, analyze, and otherwise deal with all your logs for various uses, go for log management. If you are looking to build a SOC, you might need a SIEM (and, actually, log management since your SOC analysts will wants to see original logs pretty often)

Related posts:

• Top 11 Reasons to Collect and Preserve Computer Logs

• Top 11 Reasons to Look at Your Logs

• Musings on 100% Log Collection

ROI, ROSI, RROI and Harry Potter Tales

OK, let's step back a bit and review what was said in the latest installment of the Great ROI Saga ...

In response to Richard's post, I thought and said that: "So, let's see whether you can compute (and thus "have") a rate of return on buying a security product. Sorry, the economics answer will be a solid 'no.'"

Ken Belva then argued (using Dr Gordon as an information source) that: "those who argue that you can compute an ROI for information security investments are technically correct." However, he mentioned some minor "measurement problems."

Pete Lindsrom first opined that: "I really don't understand why people are so threatened by the notion of ROI in security. Why on earth should they care whether someone can leverage the concept in support of their security goals? [...] I would suggest that since you can reduce recurring costs with, say, a patch management solution, you are contributing to higher net income and therefore can get ROI." and then added a few fun pointers in his piece called "Ten Points about Security ROI and ROSI": "ROI in security typically comes by reducing your existing, known cost basis such that the net profit (in the broadest sense, of your organization) is higher. These are real costs that show up, or will show up in the case of anticipated ROI, in an organization's financial statements." He then adds his own firewood ....eh ... term to the fire: ROSI.

Iang on FC blog stated that: "The issue here is a simple one of negative numbers and the distinctions between absolute and relative calculations. [A.C. - huh?] [...] Calculating ROI is wrong, it should be NPV. If you are not using NPV then you're out of court, because so much of security investment is future-oriented. [...] Predicting the "savings" from a security investment is hard." Hopefully, somebody got that ...

Mike Murray first said that he hates ROI, mentioned a spherical horse on a vacuum :-) and then added: "How much does my business increase its net profit because I have purchased this technology/implemented this process/bought more toilet paper/hired this person/etc.? - Ask that question, and the debate about whether you call it ROI, IRR, Rate of Return, Cost Reduction, or any number of other things goes away."

Chris Hoff chimed in with a sensible: "It seems that the unofficial scoring has the majority of contributors to the debate suggesting that Security ROI does not exist...sort of. The qualification of the word "return" really seems to be the important lynchpin here as contribution (margin, profit, etc.) versus cost avoidance really is what sends people off the deep end." Also, he issues a pacifying line: "If they want ROI, then fine...define the "R" appropriately and move on." He then piles his own firewood ....eh ... term to the fire: RROI.

Richard then summarized with: "I am only concerned with the Truth as well as we humans can perceive [A.C. - italic is mine here and above] it." But nobody else seemed to :-)

In other words, the above "discussion" tells me that one can use whatever term to call whatever thing nowadays: it is indeed a free enough country (nobody will stop you, no matter how stupid you will look while doing it!)

Overall, if you want to call an apple "an orange," I am not the one to stop you. If you insist on calling security savings or other financial benefits from security "ROI", I am not the one to stop you. Still, I would prefer (and will use ;-)) the term "fake ROI" since it is certainly not what the finance and economics books (and people) call Return on Investment...

Now, some of you may be wondering, what the title of the post has to do with its content. Alas, this is left as an exercise for the readers :-)

Technorati tags: security, ROI

Why Look for iPhone Vulns?

Here is my scale of why people look for iPhone vulns:


0% ------------------------------ 50% ------------------------------- 100%

desire to create sheer
a more secure world publicity

Where do you think we are now?

Or, maybe we are off the scale above and people just do it for fun ....

REAL Anti-anti-virus

I am wondering what brilliant minds in marketing come up with this: Norton Anti-Bot. I am NOT the person to say that "anti-virus business is a racket," but this one come reeeeeally close to it.

So, let me get this straight:

1. Buy anti-virus solution (now positioned as "anti-malware")
2. Have a bot installed on your "protected" system thru one of those IE holes
3. Complain
4. Get a response like "oh, you need anti-bot for this, not anti-malware ..."


Maybe the "av is dead" crowd does have a right to scream and rant after all...

More Anti-Anti-Virus

More anti-anti-virus stuff, this time from SANS folks: "antivirus approach of the last 20 years, which is based on the assumption that you can keep up with creating "patterns" for all bad things out there, has completely outlived its usefulness."

Still, many people seem to think that this is some kinda Gartnerian :-) quest against anti-virus vendors... I dunno.

Government Spyware vs Anti-malware Firms

I am amazed this (this too) didn't get more coverage: should (willl, legally can, etc) anti-virus companies detect government-created (police, FBI, KGB, MI5, etc) malware if:

a) not notified by the government (I am guessing "yes" here)
b) "politely asked" by the government (I am guessing "maybe" here :-))
c) court ordered by the government (I am guessing "no" here)

This even features a funky table with anti-malware firm responses ... The only supposed real case mentioned is this: "The Associated Press reported in 2001 that "McAfee Corp. contacted the FBI... to ensure its software wouldn't inadvertently detect the bureau's snooping software." McAfee subsequently said the report was inaccurate."

More on ROI

This made me think of the following re-phrase of well-known joke:

Q: Can you fit 100 angels on the tip of a needle?
A: Man, this is sooooo hard! Those pesky "measurement problems" get in the way ...

More fun ROI stuff to come soon (of course!)

My Upcoming SANS Preso: July 31st, 2007

Just as a heads-up, I will be presenting at SANSFire 2007 in DC on July 31, 2007 on a fun topic of build vs buy vs outsource your log management? Many past attendees expressed "dismay" :-) that a vendor presentation can be so enlightening and unbiased...

So, "Choosing Your Log Management Approach by Anton Chuvakin on Tuesday, July 31st, 2007 12:30pm - 1:15pm, SANFire 2007 in Washington, DC.

See you there!

Musings on 100% Log Collection

Warning: this is NOT about ROI! :-)

One of the most exciting, complicated and at the same time very common questions from the field of log management is the "what logs to collect?" question (this, BTW, implies that logs not collected will be left to rot wherever they were generated and thus might or might not be available at the time of dire need. You are collecting logs, aren't you?). This comes up during compliance-driven log management projects (in the form of "what to collect for PCI DSS compliance?") as well as operationally-driven (in the form of "what logs from this application do I need to detect faults and errors?") or security-driven log management projects (in the form of "which logs will help me during the incident response?")

What are the answers that one sometimes hear? Otherwise awesome log management guidance NIST 800-92 "Guide to Computer Security Log Management" confuses the reader with this fascinating blurb: "generally, organizations should only require logging and analyzing the data that is of greatest importance." And how do people to know which logs are of importance? (I did have a bit of a debate with NIST folks on that...)

Other answers are situation-specific and thus limited in their usefulness ("need IDS alerts + server logs to detect intrusions via correlation", "need all logs that show access to PHI"). I spoke about the pitfalls of "prioritizing before collection" in my presentation "Six Mistakes of Log Management" and its companion paper (TBA). In some cases, such as the incident response scenario, you might be naturally leaning towards grabbing as much as possible, since you never know which bit will help you answer that dreaded "WTF happened?!" question ...

On the other hand, there is a simple answer that doesn't suffer from the above issues: collect everything. However, many folks go into a state of shock upon hearing it :-) "Everything!!!??? HOW can you collect 'everything''? What about storage, bandwidth, hardware, etc?"

But you know what? It really isn't as bad as you think! Seriously! Just think that:

1. Logs compress really well (1:10 to 1:15 compression ratios are not unheard of), so bandwidth and storage are less of an issue that initially estimated
2. Disk storage is cheap (and tape is cheaper still); holding a billion of log records might well cost under $200 (!)
3. Figuring out what you need, might need, can be "told to need", will need, etc is genuinely hard. You will never get it right!
4. Many logs don't need to get collected in real-time after generation, thus allowing you to save some bandwidth by moving them when network is less busy.
5. Technologies exist to make sense of "everything", not just "hand-picked" and parsed logs.

Convinced yet? So, if you are pondering "what logs to collect?", try to switch your mindset into thinking "what will it take for me to collect everything?" You probably won't regret this decision!

Related posts:

• Top 11 Reasons to Collect and Preserve Computer Logs

• Six Mistakes of Log Management

Makes One Wonder ...

One of the "lessons" of blogging is that if you have a topical blog, you should never blog about other matters, politics, religion, personal things, etc. But you know that? If though you think that this is a security blog, it ain't (at least, not for the next 15 minutes :-)) It is primarily my blog :-)

So, seeing stuff like this, makes one wonder: why is it better for the US that a Ph.D. in, say, nuclear physics will have to go back home to, say, Iran or Romania, after his student visa expires and he is unable to get a "green card," rather than stay here, work and eventually "pay" for education, which is, BTW, funded by American taxpayers, in most cases ... Makes one wonder indeed!

New Paper: "Log management in the age of compliance"

Yeah, I know, not too technical, but still fun - my paper "Log management in the age of compliance" on ComputerWorld: "In my previous article, I described the way in which three regulations (FISMA, HIPAA and PCI-DSS) affect incident response processes. This triumvirate also affects log management, since they [A.C. - these and other regulations] call for enabling logging as well as for log review."

A quote: "The major effect the age of compliance has had on log management is to turn it into a requirement rather than just a recommendation, and this change is certainly to the advantage of any organization subject to these regulations. It is easy to see why log collection and management is important, and the explicit inclusion of log management activities in major regulations like FISMA, HIPAA and PCI-DSS highlights how key it truly is to enterprise security as well as broader risk management needs."

In other words, if you didn't implement log management, because of the obvious value you can get out of it, now you'd do it 'cause the auditor will get you otherwise :-)

Security ROI Pile-Up!

So, another day, another security ROI fight. Let's first review what was said so far.

Richard said: "Digital security is not a line of business. No one practices security to make money. Security is not a productive endeavor; security risk is essentially a tax instantiated by the evil capabilities and intentions of threats. Because security is not a line of business, the performance incentives are not the same as a line of business. Security has no ROI; proper business initiatives do. Only security vendors make money from security." (in the past, he also said this: "There is no ROSI (return on security investment). There is simply cost avoidance. Due care is a concept I am more likely to embrace.") And also: "It's important to remember that there is no return on security investment. Security is a cost center that exists to prevent or reduce loss. It is not financially correct to believe you are "earning" a "return" by spending time and money to avoid a loss."

Ken countered: "My friend in the financial risk department read Richard’s statement that “Security does not have an ROI” and he laughed. He commented, “Just let some hackers change some numbers in a banks financial system and you’ll see that security has ROI.” That’s a finance guy talking, not an InfoSec guy."

David countered the above with: "It happens that I do agree that security can have an ROI, but the scenario given is not an example of that. It's an example of loss prevention and, to a certain extent, business enablement (to enable the bank to survive, which it really wouldn't if any Joe could log in and change account balances at will)."

Seeing all this stuff, Richard closed with: "The problem the "return on security investment" (ROSI) crowd has is they equate savings with return. The key principle to understand is that wealth preservation (saving) is not the same as wealth creation (return)."

However, before jumping in the fray, I figured I'd accost the economics talent I have available right in the comfort of my home :-) In the past, most of my stories of what some security folks think about computing ROI caused her to go into fits of unrestrained laughter...

First, unlike Wikipedia in the past, Britannica doesn't even have an entry for "return on investment" (and now, neither does Wikipedia - the links point to an entry about "rate of return". Along the same lines, "Principles of Corporate Finance" by Richard A Brealey, Stewart C Myers only mentions "book ROI" (in Chapter 12) as a very specific, narrowly-used term, which has little to do with this discussion. Rate of return, however, is mentioned as a performance measure of a business.

So, let's see whether you can compute (and thus "have") a rate of return on buying a security product. Sorry, the economics answer will be a solid "no." And, in fact, Richard's explanation fully passes the "test by an economics Ph.D." - indeed, security products save money, not earn money (obvious exception: security vendors) and thus there is no "return." The phrase "return in the form of savings," that I saw on some blog, caused my "in-house economist" to utter a completely unprintable word and then follow up with: "what an idiot! it is either return or savings!"

To take this further, when use of a security product is mandated by a law, all these "return rants" should stop: in this case, it becomes "sunk cost" (like license to do business, patents, etc which are never featured in return calculations).

Moreover, one cannot compute a "rate of return" on something that will not be making money on its own. For example, a stock or bond sitting in your safe has a "rate of return," while your "investment" in a chair that enables you to work on your computer does not, even though it enables you to work.

Thus, here goes the SiteKey example? Any "rate of return" calculations here? Sorry, still "no". The reason is that providing security tokens for site access is not making money on it own, but only when combined with bank's core business i.e. banking. Imagine this bank will stop banking services and will just try to "sell SiteKey to access its web site," can they earn a return then? If "no", then the answer to the original question is still "no." "Enablement" is still not earning, at least, not in the economics/finance.

At the same time, I think this debate will be resolved thus: there is rate of return (definition from economics) and there is "ROI/rate of return" (hijacked definition that developed its own life and started to mean simply "usefulness" or "value proposition") There is "ROI" of security and there is no ROI of security...

Related posts:

ROI on Not Getting Your Ass Whooped

A Passing Comment on ROI of Security

ROI, FUD, Selling Security and Relevance

More on Security ROI or ROSI (rosy? :-))

The Last Word in Sony DRM Rootkit Story?

"Sony BMG Music Entertainment is suing a company that developed antipiracy software for CDs, claiming the technology was defective and cost the record company millions of dollars to settle consumer complaints and government investigations."

"Sony BMG is seeking to recover some $12 million in damages from the Phoenix-based technology company"

Logs: Blast from the Past

At some point in this latest battle on loganalysis, Marcus Ranum thus spoke this about why syslog was invented and what happened next:

"Eric brought all the logs together in one place, and saw that
       it was good, because they could then be processed with a
       single invocation to the god 'rm'. And the system loggers
       came, and bewailed the complexity of log data - because
       it was all jumbled together. So the loggers girded up their
       loins and burned many regexps and awk scripts in
       sacrifice and were able to eventually separate the logs
       into separate application-specific data sets, thereby
       undoing the work of the Mighty Eric at great expense.
       And they thought that it was good."

Read the rest of the very fun thread here.

Fun New Paper from Honeynet Project

First, why am I blogging at this hour? Good question! Cause I feel like it :-)

So, check out this fun new paper from Honeynet Project. Called "Fast-Flux Service Networks", it is an "overview of what fast-flux service networks are, how they operate, and how the criminal community is leveraging them, including two types which we have designated as single-flux and double-flux service networks. "

Very fun detailed view of modern cyber-criminal technology ...

Is This Anti-Security?

Every security pro should read this blurb and think about it. No, really.

It starts with this fun line: "Just about everything in civilization works on the honor system."

Think about it - this is basically what many call "luck-based security" ;-)

"When we move online, though, two things happen. First, word among the black hats spreads fast. One person starts ripping you off and suddenly it's a hundred."

Indeed, offline bad stuff doesn't scale as well as online; true, but ...

"Just like the real world, though, if you spend all your time preparing for and defending against the black hats, you'll never accomplish anything."

Holy Chao! :-) Really?

It gets milder, but still pretty darn disturbing:

"There's a different path. Awareness of the potential problem helps you keep your eyes open. You can watch the trends, be aware, but still embrace the honor system. Realize that the vast majority of your customers will always want to do the right thing. Look both ways before crossing the street... but still cross."

This type of thinking cannot even be called "wrong" since it is sooooo common. We should FIT security in the world that is dominated by this thinking; only then everybody is successful.

Ten Most Important Things in Security Management by ISM Community

Here is another great doc that I wanted to highlight: "ISM Community Top Ten"

"The ISM Community Top Ten is an awareness document that describes a series of key issues that organizations should immediately understand. [...] This Top Ten list describes key concepts that should be part of any effective information security program. Organizations can quickly compare their current information security program against this Top Ten list and determine if and whether they need to improve. "

It is a bit of dry read (but less dry than, say, ISO docs), but an interesting one nonetheless.

A Lot of Fun Security Reading

"Dusty Old Stuff From the Distant Past" from Marcus Ranum. Sadly, a lot of 1994 presos are still relevant...

Flashes of Paranoia

Whenever I see stuff like this ("IT Giants Collaborate on DOD Security Project"), I CANNOT STOP a thought: how many of such "IT giants" are totally and thoroughly 0wned by foreign hackers, who either ARE working or CAN BE MADE to work for a foreign government ...

You can't really hope to have a credible "alliance to create a new common IT architecture for sharing and protecting sensitive government [...] information," if you can't protect your own, can you?

Just a thought to lighten up a coming weekend.

Fun Insights from "Missing Mike" :-)

This one: "I have no doubt that in the coming years; there will be a lot of focus on data-centric security – but not in 2007."

and this one as well (which makes me somewhat happy): "6-month grade: D - Much to my chagrin, compliance is still alive and well. [...] Compliance will remain a factor for 2-3 year planning horizon. Now I need to go get some Tums, since eating crow wreaks havoc on your digestive track." :-)

A small comment on the latter, if I may. Indeed, a new compliance mandate won't scare a "Pragmatic CSO", but - what's the antonym? a "romantic CSO"? - will likely be scared shitless ... Thus, it is a good thing that compliance will still be a factor, since it will prod less "pragmatic" security leaders into action!

PCI in INaction :-)

Here is a fun story of a clear and blatant PCI violation: "A couple of hours later I get a pretty ugly Excel spreadsheet back. I am asked to print it out, sign it, and fax it back to them. I had a look at the form and I wondered what was going on. Well, there was all my information in this spreadsheet, including CVV number!"

Nobody Is That Dumb ... Oh, Wait! - IV

This should actually be called "Nobody Is That Dumb ... Oh, Wait! Journalists are!" or "Do you talk to your co-processor often?"

Check out the amazing quote from this "article": "Rule No. 5: Develop technical partnerships with other people who can write exploits. Become part of the security research community, whose members can be found at conferences, mailing lists or RIC (real-time interface coprocessor) channels, Aitel suggests."

See anything fuckingly :-) wrong with this?

My enlightened colleague certainly didn't recommend that you talk to youR coprocessor often :-) Somewhere IRC became RIC and the assclown writing the paper looked it up (probably like this) and "thought" 'Oh, I now know what RIC means' ...

Result? Hilarity ensues! :-)

Windows Log Analysis for Incident Response

A few tips on Windows event log analysis for forensics, including looking at AV logs, timing events, etc.

I especially liked this bit, which I didn't know before: "Event ID 35 (Source: W32Time) is an Information event that tells you that your system is sync'ing with a time server, and provides the IP address of your system. This can be very useful in a DHCP environment, as it tells you the IP address assigned to the system (actually, the interface) at a particular date and time."

Tina Bird's Logs and Law Summary

Here is the most comprehensive summary of all legal, regulatory, policy and other guidance documents that mention logging, created and maintained by none other than Tina Bird, who seem to be back in logland full time :-)

From Basel II to Common Criteria all the way to SOX.

Fun Intrusion Story

Here is an enlightening account of a major intrusion investigation of a cell phone network in Greece.

Fun excerpts:

"Major network penetrations of any kind are exceedingly uncommon."

Ha-ha. Change that to "PUBLIC KNOWING ABOUT major penetrations ...", puh-leeeease.

"It remained undetected until 24 January 2005, when one of Vodafone's telephone switches generated a sequence of error messages indicating that text messages originating from another cellphone operator had gone undelivered."

IDS? IPS? Anti-malware? MSSP? Haloooo... See a pattern here? :-)
Do you know what actually cause this and led to detection? Bugs in the actual malware!!!

"Koronias told them that rogue software used the lawful wiretapping mechanisms of Vodafone's digital switches ..."

Ha-ha, somehow I am not surprised ... Are you?

"But in early 2003, Vodafone technicians upgraded the Greek switches to release R9.1 of the AXE software suite. That upgrade included the RES software, according to a letter from Ericsson that accompanied the upgrade."

Extraneous software strikes again, even on a phone switch ...

"A call to another cellphone will be re-encrypted between the remote cellphone and its closest base station, but it is not protected while it transits the provider's core network."

Did you know that? It is kinda obvious, but I've seen many folks who think "cell phone = encrypted"

"The challenge faced by the intruders was to use the RES's capabilities to duplicate and divert the bits of a call stream without using the dialog-box interface to the IMS, which would create auditable logs of their activities. "

Log-related! Does you application log the UI actions or the backend actions? Think about it!

"It's impossible to overstate the importance of logging."

He-he, no comment!

"[ ...] we can only speculate about various approaches that the intruders may have followed to carry out their attack. That's because key material has been lost or was never collected. [...] This upgrade wiped out the access logs and, contrary to company policy, no backups were retained."

Are YOU committing other logging mistakes as well?

"Traces of the rogue software installation might have been recorded on the exchange's transaction logs. However, due to a paucity of storage space in the exchange's management systems, the logs were retained for only five days ..."

Same here :-)


Overall, go read the full story!

Nobody Is That Dumb ... Oh, Wait! - III

Another day, another installment in our aperiodic :-) series "Nobody Is That Dumb ... Oh, Wait!" featuring GAO report on data breaches [PDF]. As you recall :-), a blog post under that rubric should contain the word "assclown."

So, the report in question seem to imply that

a) there is no link between data loss/theft and subsequent identity theft, and
b) as a result, mandatory notifications (such as those prescribed by CA 1386) are a waste of resources.

But you know what? Data theft (as well as, mind you, a negligent data loss!) is a crime even if whoever took off with the data didn't use it for nefarious purposes. To me it sounds akin to "the bank robber who didn't spend the money on more crimes" or (more remote ...) "a carjacker who didn't cause a traffic incident." Mandatory notifications are a means to reduce data loss/theft, and are thus needed with no regards to how the stolen data is used!

BTW, SANS called it deeply flawed (their analysis of it is here), but it is also stupid in light of the above.

My New and Fun Fun Fun Role!

I have a sneaking suspicion that not everybody checks my site regularly. And that's OK - you need to check my blog, not the site :-)

However, if you do check the site, you might have noticed that my position title has changed! My new position is ... drum-roll ... Chief Logging Evangelist.

Yes, I joined the ranks of "evangelists" which take its origin from Guy Kawasaki.

Am I excited? That would be the understatement of the year!

On "Syslog Servers"

Warning: rant mode on.

I hate it when people call what we sell (i.e. log management) a "syslog server." I really do. Why will someone pay $X0,000 for just a box to "collect syslog?" No, really, why? I won't! It does indeed sound dumb.

By now, many people understand that log management is not about collecting syslog in one big trash can. You can do that much easier and cheaper if that is indeed your goal. Why would someone collect syslog in a trash can is a separate story :-), even though collecting logs is pretty useful at times. But using the log data is much more useful!

Now, let's try this for size - just how offensive it will sound: 'sourcefire - seller of packet grep'? 'symantec - seller of anti-virus'? 'cisco - router-pushers?' Sorry, vendors, I was just using you as an example; no offense intended.

So, please get it! Log management is about scalable (meaning you can deal with a lot of data) collection (yes, collection too) + retention (meaning storage and then destruction) + analysis (real-time and historical methods of making sense of data) of all types of log data (not just syslog!!!), and about making such data available for all organizational needs (security, compliance, operations, etc)

Top 11 Reasons to Look at Your Logs

As promised, I am following my Top 11 Reasons to Collect and Preserve Computer Logs with just as humorous and hopefully no less insightful "Top 11 Reasons to Look at Your Logs." 

1. The first reason is again disarmingly simple (is it :-)). Read PCI DSS lately? Glanced at HIPAA? Suffer under FISMA? Yup, all of the above say that you must not only have, but also review logs periodically.
2. Are you 0wned? How do you know if all your logs are stashed on a tape in a closet? Look at them! Now!!
3. An incident happens. Really, who needs extra motivation to look at logs in this case? Duh! Logs for incident response is a "no-brainer" use case for log review.
4. Users - from CEO to a janitor. You might have to know what they do on your IT systems! How? Read the logs! Everybody leaves tracks.
5. Logged system errors. Sometimes they are stupid, sometimes - benign. However, often they mean that "stuff" is about to hit the fan. Periodic review of logs reveals them and saves the day.
6. Network slowed to a crawl?  Applications are slooow? Server is not ... well, serving? :-) Where is the answer? In the logs, but you need to read them and understand them.
7. That policy you wrote a few months ago. Anybody following that? Anybody remembers that? Halloooo! Check the logs and you'd know.
8. You know your auditor might check your logs. But did you know they might also check whether you looked at them? Did'ya? Review the logs and leave the record of this activity!
9. Change can be good. But then again, it may be the sign that your controls are lacking. Who changes what and when? From what and to what? Just review the logs.
10. Now, you hate looking at logs. You have too many! In this case, look at a specific subset of logs that you never saw before- NBS. Or just deploy log management that can do it for you.
11. Logs can help you predict the future (if you review, know and love them :-)). Don't believe it? If you read them for long enough, you develop an ability to - gasp!- predict the future, albeit mostly future problems :-)

See also: Top 11 Reasons to Collect and Preserve Computer Logs. 

Coming soon: "Top 11 Reasons to Secure and Protect Your Logs"!

Technorati tags: log management, logging, chuvakin, tips

Update on CEE

A quick update on CEE (official website which will be along the lines of cee.mitre.org is still not up - government, you know :-)). A working group (cee AT mitre.org) is set up and, well, working. The discussion now is about which existing log-related standards CEE should learn (and borrow from); we are tracking a large number of mostly dead standards and standard attempts/efforts.

Reminder: My PGP / GPG Key Is Here

Just a reminder: my current PGP / gpg public key is here.

Last Blog Post for Today: Ranum on Trends

OK, OK, I will shut up :-) Just this last thing: a fun interview with Marcus Ranum here.

As usually (mmm.. make that 'AS ALWAYS'), Marcus Ranum is heavily pessimistic: "And, as a consequence, security is going to be permanently in the "expense" column [A.C. - and what, pray tell me, is wrong with that? Door locks are an expense too...] and it'll be a legal mitigation/triage game played by executives and lawyers, with the security guy's job consisting mostly of hovering over the system admin's shoulder to make sure that they actually clicked the "on" button where it says "security."

So - I think security's about to suffer a mental and financial heat-death. Frankly, we deserve it. If you look at what security has accomplished in the minds of most IT execs, during the last 10 years, it has been an endless stream of annoying bug-fixes. All the positive [A.C. - positive stuff? In security which is inherently 'anti-X' or, more softly, about 'not having X happen'? What do you mean? :-)] stuff is completely overwhelmed by the flood of mal-this and mal-that and the constant yammering for attention from the vulnerability pimps."

Enjoy the rest!

List of Utilized Windows Logging Tools

List of popular Windows logging tools on Catalyst Community. OSSEC and many low-end commercial tools are mentioned.

More On 'Do Real "Hackers" Get Logged?'

While I like to state that every activity leaves trace somewhere (and the challenge is to find where) in the logs, many like to propagate the misconception that one can do something and leave no trace whatsoever. E.g. this CSO Online piece on anti-forensics tools says: "Diskless A-F is the state of the art; it avoids logging of activity all together" while in reality it should say "avoids logging of activity ON THAT SYSTEM, while leaving plenty of traces in other places: firewalls, routers, possibly other systems, etc" (at least on a well-managed network)

Paper On Log Management

Unusually good trade rag paper on log management.

Is Mike Right Here?

Mike Rothman said: "Neither HP (nor IBM for that matter) has a security strategy."

Is he right? What do you think?

Paid by Retailers?

"PCI has lost its way, growing overly complex and costly."

Paid by these retailers ("Retailers fume over PCI security rules")? Or did I read too much stuff on "black PR jobs?"

I won't say that PCI is the best thing since sliced bread, but it is pretty darn close ... Or is it my vendor hat talking? :-)

On Banks Checking Your PC Before Transactions?

Is this good? Is this scary? Do you want your bank "doing a NAC thing" on your PC before allowing you access? "Banks are seeking access to customer PCs used for online banking transactions to verify whether they have enough security protection."

After I thought about it for a while, I decided that it IS a good thing, UNLESS their policy will now say that "customer is liable for all web transactions" [including those done by malware not detected by the bank security check...].

If that will indeed be the case (the article doesn't say it though), it will be be time to change banks "because of security." :-)

Mid-year Security Predictions 2007 Review

"Just how good was the McAfee Avert Labs team at reading the tea leaves six months ago?"

A Popular Future Attack?

This caught my attention, for sure. Is this the future to come? A scary thought: is it the present?

BTW, I am still catching up with blogging - I have plenty of stuff in my "2blog" folder, which I am now going to empty at you guys :-)

Why There Is No Syslog in Windows

Ever wondered why after all this years Windows still doesn't support syslog? This is why; read a very comprehensive answer by Eric Fitzgerald, who "owns" Windows logging. There is also a very lively discussion that ensued, which includes things like "my blood boils and a halo of pink steam forms around my head, throbbing the the gnashing of my teeth and the kodo drum-like thudding of my overworked heart. " :-) /guess who said this/

Overall, it pains me to say this, but Eric's answer actually makes sense. Still, having a little tiny-teeny option to send a filtered subset of Windows events tout via UDP 514 in an "official" manner would be nice...

Fun LogLogic Review

Here is a fun review of LogLogic technology by the smart folks of the NWC magazine.

While the review is otherwise insightful, seeing stuff like this blurb below makes me want to be in marketing (ooops, I am now :-)), since marketing rules the world (does the word "iPhone" rings the bell?): "Index searching, brought to the masses courtesy of the Splunk log analyzer, enables IT to search raw syslog data without having to write custom parsers."

Small bits of reality (such as that LogLogic had index-based searching for years) never bother marketing people. Sometimes, I want to be like that too. :-) But, fortunately, not often :-)

On Automated "Intrusion Response"

Stuff like this carries a unique cool factor. Is it healthy? I dunno :-)

"Developed by state-owned Rafael, See-Shoot consists of a series of remotely controlled weapon stations which receive fire-control information from ground sensors and manned and unmanned aircraft. Once a target is verified and authorized for destruction, operators sitting safely behind command center computers push a button to fire the weapon."

BTW, why still a human in the loop? Can't they go "full cyber"? :-)