First, here is what my early endorsement for the book said (can be found on the inside cover of the book):

“Amazingly useful (and fun to read!) book that does justice to this  somewhat esoteric subject - and this is coming from a long-time  visualization skeptic! What is most impressive that  this book is  actually 'hands-on-useful," not conceptual, with examples usable by  readers in their daily jobs. Chapter 8 on insiders is my favorite!”

What else do I think of the book, apart from the fact that it is awesome? :-)

First, I have to admit that I used to argue with Raffy about usefulness of visualization. I was burned by having to look at bad “visualization” tools and would take an ugly, meaningful table over an ugly, meaningless picture any day now. Thus, I was a visualization skeptic. Buy you know what? The book does justice to visualization really well, and it explains when to use it and when not to use it.

The book gives just the right amount of visualization theory, which is not onerous to read at all (unlike some other books), as well as other visualization basics. The fun starts at Chapter 4, where he covers  the process from data to useful pictures. This actually explains why some visualization are useful and some are not; if you just jam data into a graphing program, there is a good chance that it would not be too useful. If you follow the ideas from Ch4, it is more likely to be useful.

Ch5 and 6 cover network data analysis: logs, packets, flows. This is what most people usually try to visualize; this book goes beyond “worms and scans” into nice visuals of email traffic, wireless and even vulnerability data (I found the latter slightly confusing). Ch7 covers “compliance”, which, in this case, covers all sorts of fun things, from risk assessment to database log visualization.  As I said, Ch8 is my favorite: I agree that insider tracking MAY be the area where visualization tools and approaches beat others. In Ch9, the book covers a few visualization tools; obviously, including the author’s AfterGlow.

So, to summarize, get the book if you have any connection to security AND data analysis. In fact, it is very likely that if you are doing security, you’d have to do data analysis at some point and so will benefit from reading the book. And, yes, it does come with a CD full of visualization tools (DAVIX).

BTW, I am posting it at Amazon as well.

• The transport – processing Syslog events takes up a heck of a lot less processing power than collecting from a Windows box. Same with collecting data over an ODBC connection.

Police had no idea that one SIM card could be used simultaneously from two handsets before the detention of Nazir Ahmed for interrogation. Nazir was picked up from Morigaon after an SMS from his mobile number in the name of ISF-IM claimed responsibility for Thursday's blasts in Assam.

Nazir had a Reliance connection and an Eve handset. Each handset of this particular model has a unique International Mobile Equipment Identity (IMEI) number. Cops found that two IMEI numbers were using the same SIM. Accordingly there were two record sheets of calls and SMSes from Nazir's mobile number. The record of the SMS to the media was found in only one sheet, which forced police to believe that Nazir's SIM might have been cloned and someone else was using the duplicate card, with or without the owner's knowledge.

"We stumbled upon this technological surprise that Nazir Ahmed's SIM card was used in two handsets," Assam IG (Law and Order) Bhaskarjyoti Mahanta said.

So far, not that interesting. There are lots of vulnerabilities in technological systems, and it's generally a race between the good guys and the bad guys to see who finds them first. It's the last sentence of this article that's significant:

The experts said no one has actually done any research on SIM card cloning because the activity is illegal in the country.

If the good guys can't even participate, the bad guys will always win.

No longer are OS vendors and other large infrastructure technology providers the main source of vulnerabilities. It’s the thousands of applications, produced by thousands of software vendors, that make up this huge 3rd wave. ISS reported that in 2007 that the top five sources of vulnerabilities: Microsoft, Apple, Oracle, IBM, and Cisco, had dropped to supplying us with only 13.6% of our vulnerabilities. 86.4% came from the other thousands of software vendors that supply our computers with a seemingly unending supply of vulnerabilities for attackers to exploit.

In a recent report Microsoft has congratulated itself on doing a good job securing Windows. And by all accounts they have done a good job. But then they state this:

“Unless software development practices change throughout the industry, any improvements in the security of Windows would be meaningless.”

Whoa. Millions of dollars spent on securing the most prevalent piece of software and it could be meaningless? Yes, it’s true. Since attackers typically only need one vulnerability, if it isn’t in the network, and it isn’t in the host configuration, and it isn’t in the OS, they will happily exploit a vulnerability in an application.

At every shift of exploit target the problem has gotten more difficult to solve. Networks had choke points and could be centrally managed. It took a while but eventually host configurations became centrally managed and automated tools could scan configurations. Although OSes were huge and complex beasts with 10’s of millions of lines of code, with enough effort, their vulnerabilities have been largely tamed as Microsoft’s Windows and the Linux kernel track record shows. This was a very substantial, over five year effort, which used some of the most talented security people anywhere.
But now what to do? Instead of a few OSes we now have thousands of applications with vulnerabilities. As Microsoft found out, the attackers don’t go away, they just move on to the next incrementally less juicy vulnerability. In the world of exploits that typically means the vulnerability with the next smallest target population.

Attackers have started with the common client applications that can be found on almost every machine: Acrobat, Flash, RealPlayer, Quicktime, popular antivirus software. And they will continue down the popularity slope until they get to application populations down in the thousands which is getting to fairly small software vendors. Attackers can do this because they can bundle many vulnerabilities together, exploiting the statistical fact that you must have some vulnerable software installed. Compromised web sites have been found attacking visitors with over ten client side exploits preying on multiple versions of vulnerable client software.

The solution to this problem is all software must be written securely, not just the software from the big guys. Small vendors think they aren’t a target just like home users used to think they weren’t a target. People thought, “Why would someone want to attack my home computer?” Then they realized they did home banking, or had a fast internet connection that could be used for DDoS attacks or sending spam. All software vendors need to get the same wakeup call. Attackers don’t want to find a vulnerability in your software to make you look bad. They want any vulnerability. If the population of your software is small they will just bundle your vulnerability together with others in an exploit pack. The days of the average software vendor not having to worry about application security are officially over.

But that credit card weirdness is nothing compared to the one I’m about to describe.

Before we do that, let’s take a moment to discuss the design principle of failing securely. The general idea is that if a security mechanism fails, it should fail closed. If your firewall crashes, it should block all traffic, not allow all the packets through. If the power source to your card key system is interrupted, it shouldn’t unlock all the doors. If the connection between your application server and your LDAP directory is severed, subsequent authentication requests should be rejected, not approved. This is not rocket science.

So back to credit cards. I had a conversation last night with an old friend who related a bizarre situation they had encountered during the QA process for one of their web applications. One of their tests involved repeatedly attempting a credit card transaction using a canceled/expired American Express card. Here’s what they saw in their logs, paraphrased by me:

Attempt 1: Denied
Attempt 2: Denied
Attempt 3: Denied
 .
 .
 .
Attempt 49: Denied
Attempt 50: Denied
Attempt 51: Approved

What the…? Approved? That can’t be right. So they ran the test again. Every time, after multiple consecutive rejected attempts, the transaction would inexplicably go through. The threshold wasn’t always 50, but the general pattern was consistent — keep trying and eventually it’ll work. Clearly, this had to be a bug in the code, but a deep-dive into the guts of the application turned up nothing. The application security group got American Express on the phone to see if they had any insight on this odd behavior. The answer? They didn’t concede the failure was on their end, despite log data showing the successful authorization codes.

My gut instinct would be that the application requesting the transactions wasn’t failing securely (e.g. network connection to AmEx timed out, so just approve the transaction). But that explanation wouldn’t account for authorization codes coming back.

So what in the world is going on here? Why would the system behave this way? Is it by design? I can’t think of a single legitimate use case for failing open like this. If this is actually a design decision by the credit card companies, I have no doubt that someone in our audience knows the rest of the story.