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 best security program is at the business with the happiest customers.

There's a fine line between happy customers and playing piano in a bordello.

Sees a lot
Can tell the king he has no clothes
Can tell the king he really is ugly
Does not get killed by the king
Nice to have around but…how much security improvement comes from this ?

Changes happened faster that he was able to move
Did not read the signs
Good intentions went unfulfilled
A brutal way to ending a promising career
Sad to have around but…how much security improvement comes from this ?

Obviously these models of CISOs are not solving our information security problems. Instead Dr. Garigue points us to Charlemagne as a better model

King of the Franks and Holy Roman Emperor; conqueror of the Lombards and Saxons (742-814) - reunited much of Europe after the Dark Ages.

He set up other schools, opening them to peasant boys as well as nobles. Charlemagne never stopped studying. He brought an English monk, Alcuin, and other scholars to his court - encouraging the development of a standard script.

He set up money standards to encourage commerce, tried to build a Rhine-Danube canal, and urged better farming methods. He especially worked to spread education and Christianity in every class of people.

He relied on Counts, Margraves and Missi Domini to help him.

Margraves - Guard the frontier districts of the empire. Margraves retained, within their own jurisdictions, the authority of dukes in the feudal arm of the empire.

Missi Domini - Messengers of the King.

This is the way forward! Find software security champions in the architecture and development groups,help them understand the real security issues. They will find solutions you have not thought of. Same for DBAs, same for business analysts even. Its all about beating the bushes, education, and decentralizing security services. Specifically, he points out this important mandate for IT security

Knowledge of risky things is of strategic value

How to know today tomorrow’s unknown ?
How to structure information security processes in an organization so as to identify and address the NEXT categories of risks ?

To me this is our mandate and measure of effectiveness. Empower our customers, educate, and create business value. If I am a CISO  I don't want 20 people reporting to me who do firewall ruleset changes. I want one champion in 20 different groups - development teams, architects, DBAs, business analysts.

A concrete example, infosec can continue to go along with the herd and follow the "what everyone else is doing architecture" meanwhile developers are connecting every single thing in your business to the Web. I have been doing integration and new technology projects for a long time, and let me tell you - Change does not always create happy customers in the short run. But the chart below shows that information security is maybe more concerned with not causing waves rather than adapting.

The best security program is at the business with sustainable competitive advantage.

Partial Disclosure - The Good

The responsible disclosure process tends to break down in rare occasions where the vendor doesn’t want to fix the issue. When this occurs, the researcher is put into a difficult position whereby full disclosure could put users’ systems at high risk of compromise. The other case where partial disclosure becomes an alternative is when the researcher has discovered a design flaw in a protocol or underlying multiple vendor component. Examples of this case include the DNS flaws published this past summer by Dan Kaminsky and the TCP denial of service condition discovered by Robert E. Lee and Jack Louis that is currently in the disclosure process. When the flaw affects a very large number of vendors and the actual problem is located within the underlying protocols that support the communications of the Internet as a whole, one possible solution is to follow a partial disclosure model where phasing the details to the general public can be used to encourage adoption and creation of patches throughout the enormous target audience.

Partial Disclosure - The Bad

What is driving the fear surrounding partial disclosure is the potential for abuse. When a major flaw is partially disclosed, a number of potential issues may occur. First and foremost, the further along the partial disclosure path we are, the more details will be released to the public, and the higher the probability that someone (either good or bad intentioned) will figure out the exploit and disclose the details. Second, when partially disclosing, the vendor’s hand is being forced into a situation that could speed up fixes, reduce testing, and cause ripple problems elsewhere within the infrastructure. It is difficult enough to dance the fine time line when doing responsible disclosure, but if we are escalated to the point of partial disclosure, additional fuel is added to the fire.

The Ugly

The real ugly part of partial disclosure is when we add to the equation the ability to spread fear, uncertainty, and doubt into the normal user community. It is generally well accepted that FUD can be used to drive additional revenue. If it is possible to increase the perceived magnitude of the “problem” that your product or service solves, it is possible to directly impact the demand for that product or service. That is the major fear imposed by the growing trend of partial disclosure. By releasing just enough information to trigger wide scale speculation into the flaw, it is possible to create buzz and garner media attention resulting in a lot of speculation and very little hard facts around the issue. The potential for abuse by the security industry at large is enormous.

The Fix

Some have suggested a group of security researchers be convened to vet the requirement of partial disclosure and to allow for independent peer review of any security research that requires the partial disclosure process. This suggestion leaves questions regarding who would stand on this group and who would be impartial enough to ensure that the right thing was always done regardless of profit potential. It also leaves open the opportunity for member researchers to utilize the information gathered during the vetting process to position themselves to profit from the data upon release. It might be wiser to rely on a higher level authority or government entity to manage this process and use the services of security researchers as required for subject matter expertise. While a group of this type wouldn’t ensure that all partial disclosure is appropriate, it would hopefully limit the potential for abuse and the ever present chance that people try to profit from the FUD that surrounds the current partial disclosure process.

I think a good litmus test of the mental and moral quality at any large institution [with significant derivatives exposure] would be to ask them, "Do you really understand your derivatives book?" Anyone who says yes is either crazy or lying.

It is crazy to allow things to get too big to fail, run with knavery. As an industry, there is a crazy culture of greed and overreaching and overconfidence trading algorithms. It is demented to allow derivative trading such that clearance risks are embedded in system. Assets are all “good until reached for” on balance sheets. We had $400m of that at general re, “good until reached for”. In drug business you must prove it is good. It is a crazy culture, and to some extent an evil culture. Accounting people really failed us. Accounting standards ought to be dealt with like engineering standards.

There are distinct parallels between phishing / retail payments, and the bigger investment mess. In both cases, banks would argue these are core business. In both cases, they have applied risk-based security models, and accepted some loss. In both cases, they have the ability to apply substantial experience to the monitoring, allocating and absorbing risks and losses.

In both cases, they watched and did nothing as the risks started from low, and migrated upwards. Are we at the point where regulation has killed the ability of banks to apply their (arguable) one core skill, to whit, risk-based analysis? Are banks that far out of banking that they no longer have it?

1. Our brilliant field engineer Dimitri McKay talks about the eternal topic of converting Windows event logs to syslog. Yes, Eric, we ALL know it is ugly, but that is the only way that actually works well across all systems ...
2. More on Windows and syslog: "Syslog ... 20 Years Later."  BTW, this is really not about syslog, but about Vista/2k8 finally getting an ability to natively centralize the event logs via event subscriptions ("It's only about twenty years behind schedule, if you're counting.")
3. Two fun pieces on correlation: 1 and 2. What often kills "a log correlation project"? "Whoever had worked on it had not had much time available to learn the way to properly configure the software" (from this)  and "correlation only really works when backed up by real data about what is the biggest problem in your environment, and how that problem manifests itself in the event logs." (from this) None of this is new, but a useful reminder nonetheless
4. Fun LogLogic podcast is here. The topic of this high-level discussion (CEO) is related to operational use for logs. I did one with them too; on logs and virtualization (will be up soon)
5. A couple of good posts on logging from Nemertes Research: "Sharpening Stones and Walking on Coals",  "Search or Destroy"
6. Reminder about a few useful Windows Vista and 2k8 events: 4802 (screensaver engaged) and 4803 (screensaver dismissed)
7. One person is wondering about the usefulness of logging after "experiencing" Linux auditd logging (kernel audit): "Logs are like a warm blanket; verbose logging means you can know what's happening on your systems if you keep up with the logs.  At the same time, logs become a burden very very easily, and they are easy to ignore." This post is a must read for us logging afficionados; producing too much log data is a sure way to make people hate you...
8. This also follows the same theme: people doubting the god-like power of logs :-) "So for an administrator to not care about logs was a shock." But would I argue that "log management is NOT a pain?" Now, would I? :-)
9. A classic about logging for application developers: "Building Secure Applications: Consistent Logging."  I am noticing a lot more discussions about logging in a developer community, e.g. see this and this (the latter, BTW, contains a lot of info on "why log" for developers). Overall, "getting logging right" is important (and will get more important in the future) and people need something NOW and cannot wait for the standards.  BTW, I am planning a mini-crusade on how to train application developers to include useful logging in their applications...
10. Finally, the "Is SIEM dead?" theme is continued in this fun post "Life after SIEM. Situational Awareness is next." Indeed, context is key for logs. BTW, if somebody mentions that I have "vendor bias", I will kick your ass! :-)

Enjoy!

• "Schneier on Security ROI": "It's a good idea in theory, but it's mostly bunk in practice." and "The term just doesn't make sense in this context."
• Richards adds to it: "Schneier Agrees: Security ROI is "Mostly Bunk""
• "Security ROI - The debate continues": "ROI  ... reared its ugly head."
• "FOI, Failure of Investment":  "Not that you asked, but IMHO: ROI and TCO are SWAG at best. And, they are rarely at their best." The secret weapon of ROI war - FOI -  is thus unleashed!
• This is also very relevant :-)

Overall, I love it when educated peoples' debate just falls waaaay down to the level of "I won't care what YOU call it as long as you don't care what I call it...." Yuck! :-)

All security ROI coverage is tagged here: http://delicious.com/anton18/ROI. The previous, "First ROI War", is summarized here.

• ValidationSummary controls look at the ErrorMessage field to figure out what to display, so always use ErrorMessage in a verbose enough way that it will be helpful from a ValidationSummary control.
• If you need a shorter message to display inline (i.e., where the validation control is on the form, as opposed to the ValidationSummary) use the body of the control to define it.

In the past, I've used RequiredFieldValidator controls on my web forms to remind users that certain fields are required. I would set the ErrorMessage to something vanilla like, "This field is required", or even something simpler like "*" (an asterisk) if I didn't have much room on the form to display more prose for an error.

A friend was recently testing a new feature that I'd built for our sales team and she had a hard time seeing the little red asterisks that were showing up next to required fields. It felt to her as though she was pushing the submit button on the form but nothing was happening. It was clear that a ValidationSummary control would be helpful, especially if placed close to the submit button for the form.

I've been a bit lazy in the past about using ValidationSummary controls, partially because most of my forms are simple enough that they feel a bit redundant. But on a more complicated form, they can be very helpful to guide users back to the places on the form where there's problems.

So I threw one of those puppies on the form and immediately saw that there was a problem - my error message was set to "*", which meant that my validation summary was pretty useless - it just displayed a bunch of red asterisks! And in places where I'd used the prose, "This field is required", well that was pretty useless as an error message in the summary.

After a bit of research and experimentation, I discovered that the ValidationSummary control looks at the ErrorMessage property on each validation control in order to figure out what to display in the summary. So it's important to use ErrorMessage with a summary in mind! Don't use text like "*" or "This field is required". Be more specific so the user can find her way up to the problem field, as in, "PostalCode is required".

But if you make ErrorMessage verbose so that it's helpful in a summary, it may make your form really ugly when displayed inline next to the control being validated. The trick is to use the body of the validation control element to specify the inline error message. Then you end up with two messages: a verbose one that's used in your summary, and a more localized, brief message that shows up right next to the control being validated. Note the asterisk that's in the body of the RequiredFieldValidator below:

<asp:RequiredFieldValidator
      ErrorMessage="Zip/postal code is required"
      ControlToValidate='txtPostalCode'
      ValidationGroup='BasicInfo'
      Display="Dynamic"
      runat='server'>*</asp:RequiredFieldValidator>

I've learned a lesson from all of this. In the future when I use validation controls I'll always provide a summary-friendly message in the ErrorMessage field, and if I need something different (typically shorter) to display inline, I'll put it in the body of the validation control element.

Hope this helps!

ASP.NET's health monitoring system does list the inner exceptions (apparently up to a maximum depth of two, from spelunking the code with reflector), but it does not emit the stack traces for these exceptions, which would be really helpful. I've spent some time this morning trying to figure out how I'd customize things to emit this, and it looks like what I'd have to do is catch the exception and generate a custom WebEvent that overrides ToString(bool, bool) and does everything that WebRequestErrorEvent does, but also generate the inner stack trace.

That seems a bit ugly. A search for "ASP.NET web event inner exception stack trace" yielded no interesting results, so if you've dealt with this and have a cleaner solution, let me know. I'll post my solution once I get it worked out.