1. Reported this matter to the U.S. Secret Service and state law enforcement;
2. Cooperated with law enforcement, which is actively investigating the incident;
3. Conducted a thorough investigation of the incident, including an assessment of whether or not the theft created any prospective data security risk;
4. Identified the sensitive personal information about individuals stored on the affected server; and
5. Made arrangements to notify affected individuals about the incident in accordance with state laws, offer premium credit monitoring, ID theft insurance, and ID theft resolution services, and provide additional information about prevention and detection of ID theft including information about credit alerts and credit freezes.
   

It brings up an interesting point:  Agencies do not typically have a CSO-level manager.  According to FISMA, each agency has to have a CISO whose primary responsibility is information security.

But typically these CISOs do not have any authority over physical security or personnel security:  in reality, they work for the CIO and only have scope over what the CIO manages:  data centers, networks, servers, desktops, applications, and databases.

Except for one thing:  we’re giving today’s Government CISO a catalog of controls that contain physical and personnel security.  The “party line” that I’ve gotten from NIST is that the CISOs need to work through the CIO to effect change with the areas that are out of their control.  I personally think it’s a bunch of bull and that we’ve given CISOs all of the responsibility and none of the authority that they need to get the job done.  In my world, I call that a “scapegoat”.

To be honest, I think we’re doing a disservice to our CISOs, but the only way to fix it is to either move our existing CISOs out of the CIOs staff and make them true CxOs or write a law creating an agency CSO position just like Clinger-Cohen created the CIO and FISMA created the CISO.

Bookmark to:

Research Director Patricia Adams and VP and Distinguished Analyst Ronnie Colville presented this thought provoking session. It seemed to echo what ScienceLogic has been talking about regarding our thinking around the practical ways to efficiently accomplish key tactical gains against your Configuration Management Data Base (CMDB) initiatives.

They started out with, what are the prerequisites to a successful CMDB implementation?

Garbage in = Garbage out

There is no miracle occurring in all of these new fancy framework tools; these complex databases are only as good as the trusted source of information inserted. You have to put a bunch of elbow grease into figuring out what to actually put in the CMDB.

So how do you define the metrics?

First you need to know where you are starting from – you will need to baseline the environment. Then baseline what your state is 3, 6, and 12 months after installing CMDB.

Next: break metrics down to 2 strategic areas:

1. Strategic
   1. Operational Costs
   2. Application performance
   3. Compliance - internal auditors doing analysis – keep track of their findings and incorporate into your elements for data gathering
2. Operational Metrics
   1. Changes unplanned (typically 80% unplanned or emergency)
   2. Changes withdrawn (how many changes were withdrawn / roll back)
   3. Application downtime (what did it cost from app being down)
   4. Server downtime (before and after)
   5. Tickets generated (before and after)

Having the data to show how you are performing makes it much easier to show why you need more budget to improve performance in specific areas. Having metrics allows IT managers to do marketing back to the business units about the value you are delivering.

Gartner said that from their Enterprise customers they often hear “I haven’t quantified the value yet”…That is not the right answer.

During the session, Gartner did a real-time wireless poll of the audience with some interesting questions:

What are the tools to build and populate your CMDB with IT services?

Focus of CMDB?

• Inventory 20%
• IT service relationships 68%
• Other 6%
• Don’t know 6%

Interesting to note, a very consistent set of information from year to year polling which equals a mature understanding of the CMDB’s role for analysis and decision process.

Have you heard of ITIL V.2 & V.3 and considered how it impacts this discussion?

ITIL is a process framework, it is not a technology automation framework. Just because something is pink ITIL certified does not mean that it will help at all with the automation of the process framework.

Gartner quantified the market as being about 2 years old this month. So the point here is we are in early days of this technology. The way they see it, the Large Enterprise/Framework vendors selling you is like a lock-in, but the interesting thing about CMDB is that the tools that you need to integrate and federate were only recently acquired, so the entire framework vendor integration and alignment story is mostly incomplete.

Gartner’s Evolution of the CMDB deployment

On average it takes 12 – 18 months to get up and running.

Through 2011 enterprise should recognize that any of the CMDB tools bought today may require significant upgrades to offer near real time service views to support decision support analytics.

Several items from this presentation jump out at me:

1. IT Organizations need to deploy tools that will help to automate the continuous collection of IT asset inventory, configuration and business impact analysis. That is a big gap that exists in the marketplace today… the speed at which information is collected and updated into the CMDB.
2. Investing too much into this immature market before the official standards are set and then adopted by the industry (estimated 18 months after final adoption) is quite risky.

The conclusion that I made from this presentation is that you are better off with our 80 – 20 rule around CMDB’s. Use a tool that will collect 80% of what you need to operate the business in 20% of the time it takes to deploy these heavy, less than automated framework tools!

ShareThis