Martin MC Brown at ComputerWorld has a great post on capacity planning and cloud computing. He discusses a new book “The Art of Capacity Planning”. The problem with the current model of data center management is that often a large number of machines may sit relatively idle while waiting for the traffic spike that causes them to be used. This is a problem because it’s simply a waste of time and resources on a whole number of levels. Enter the cloud – or at least the “hope of cloud computing”.

Numbers – what do they really mean? IDC released a statement with a whole bunch of them from their “Worldwide Quarterly Server Virtualization Tracker”. The most interesting stat: x86 Virtualization License Market Standings. VMware owns 44% of the market, but Microsoft, in its first quarter of general availability for Microsoft Hyper-V (plus Virtual Server 2005), has 23% of the market of new shipments.

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?

Companies think they own their reputation, but in reality they don’t. A reputation is the aggregate of the popular opinion about you. Opinions, or thoughts, belong to an individual, true or not, and a company doesn’t own a person’s thoughts, therefore a company doesn’t own its reputation. QED.

Yes.  Absolutely.  In fact, there are already changes in the works to the FAIR model that reflect this line of thinking that will allow us to approach reputation damage in a much more rational manner that anything else I’ve seen to date.

Second, RE:  Hansei & Kaizen, Richard left the following comment.

I don’t agree with your view on Gemba even if we live in a virtual world. Look into any company’s wiring closet and you’ll immediately see a reflection in its maturity from the state of the equipment, the labeling / documentation and overall neatness. “Man with messy wiring closet, will have messy virtual servers.”

However, the true benefit in Gemba is not in the actual visual inspection. It is in in the journey from your desk to the data center / wiring closet.

I agree that the benefit is in the journey.  I can’t see the wiring closet as the main destination (I just don’t see it as a useful prior).  Maybe I wasn’t clear, or was taking for granted that you guys have been reading the blog for the past 2 years, but the journey needs to be to the LOB that owns the application.  The example most given when describing Gemba is going to the production line to look at the issue that causes a problem in the ability to create and sell a car.  The “security” journey is not to the wiring closet, but to the system itself and the logs that we have for the system and whatever network-based controls might be applicable.  And we, as an industry, are just starting to understand that this “security” is only part of the picture.  The whole picture is represented by the factors that create risk.

And for our “risk journey” that security journey is only a one of serveral useful pieces of prior information for use in analysis.  For risk we have to also journey back to the “production line”, or, in our case, to the application/LOB owner.  It may also be to corporate counsel, to marketing, to all sorts of other places in the enterprise because probable losses (a necessary measurement we need in order to understand risk) may come from many different sources in the organization.  For those with FAIR knowledge, think of the six forms of loss to get an idea of what sorts of journeys we need to make.

This is why tomorrow’s post is designed to look at what should we be reflecting about, and what is needed for reflection.

Hint:  our models for risk & risk management can give us an idea of how to create structure around Hansei for the IRM program.

“You’re hired on at a new company placed in charge of securing their online business (websites). You know next to nothing about the technical details of the infrastructure other than they have no existing web/software security program and a significant portion of the organizations revenues are generated through their websites.

What is the very first thing do on day 1?”

At about the same time, I saw a message posted to one of the mailing lists where the poster wondered: "I’ve been asked to look into finding a replacement to our current log management/auditing system.  This is a field I haven’t even come close to touching before, and really don’t know the ideal things to look for (or ignore), etc. I’ve been searching through SANS site as well as googling, and I’m not coming up with a lot of great starter information. " And then he asks "Where should I start?"

This is indeed a really good question!  Let's rephrase the above for the case of logging:

"You’re hired on at a new company placed in charge of TAKING CONTROL OVER THE LOGS. You know next to nothing about the technical details of the infrastructure other than they have no existing LOG MANAGEMENT process and tools... What is the very first thing do on day 1?”

So the "Day 1" of log management project. What's up?!

The very first thought that should cross you mind before you even do whatever first thing you wanted to do is "WHY?" (don't people hate those 'Why?" questions - focusing on "What?" or "How?" is soooooooo much easier....)

"Log management" is a solution, not a problem. What is your problem that you now have a mandate to solve?

Logs don't just drop on people :-) Well, not often.

What is it that motivated your boss (or his boss, or whoever) to decide to "address this", to "take control over logs?" Was it a new compliance mandate, PCI perhaps? Was it a recent incident where investigation hit the wall due to utter lack of logs? Was it a new corporation-wide IT efficiency improvement project? Was it a lawsuit where an e-discovery request was not satisfied and thus fine was levied? Was it a hot IT project that is impossible to complete without having a tool to analyze logs?

This "need" is very important since logging is a huge realm and not focusing on the need is akin to starting a journey into a hostile wilderness without  a map - in other words, it might be fun for a while, but it can end badly :-)

Next, what do you actually do first? Figure out what logs are needed for this effort and what systems produce them (and who "owns" them!) Analyzing SAP logs for J-SOX is a VERY different effort from analyzing Cisco ASA logs for network troubleshooting.

Only at this point you can start thinking about "tools:" parsers, logs, databases, reports, alerts, indexing and other technical thingies as well as capacity planning, scalability, etc. This is the stage where you learn the lingo and learn to cut through marketing messaging to get to the actual tool capabilities.

So, remember: given mandate to "tame the logging monster", think "WHY?" first!

Really, when I've heard about it first, I was like "ah, come on, I am sure the journalists are just mis-reporting it; nobody is that dumb in their approach to system security."

Well, they really were that dumb.

Honestly, from the "blatant disregard of common sense", this is very, very high on the list (many in security agree, some in IT disagree). This is where the words "a huge data security risk" really sound like a mild understatement. 

But you know what is the most scary about this case? The fact that there are MANY organizations who manage their networks the same way: one admin with ALL the access and NONE of the monitoring.

One person + ALL access + NO accountability = you are screwed!

Also, in light of this, do you still think that "insider attacks" is some kinda security vendor propaganda? Well, go tell Terry Childs that :-) Even though some people still think that he is a good guy (more on that on Slashdot)

What also caught my attention is that some retard called his bail ($5m) "ridiculously high." Well, if he was an outside hacker, say a Romanian script kiddie, jailed for hacking SF network, would they release him for $5m? Maybe not!  Now, do you get that this case is actually MUCH WORSE! Hacker might have gained access to many assets; this guy did have access.

So, think, think, think: CAN YOUR SYSADMINS "0WN" YOUR BUSINESS? (BTW, some people think that IT "owns" you already!)

Are you OK with it?

If not, do something - start logging and monitoring (and then controlling) their actions! If you think you cannot control them, then just monitor; if you think you can neither control nor monitor, then at least log them so they will know that there will be enough good evidence to let them rot in jail for many years ... Or, if you prefer an easier alternative, stop calling your business YOUR business.

Possibly related posts:

• "Protecting logs from admins"