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

Is there security needed between virtual machines?  Some say no, some say yes.  I've been out talking to a number of virtualization users and non users on this topic and I'm finding that some say no and some say yes.  The users of virtualization technology tend to say yes while others looking at virtualization from the outside tend to say no.  Why is this?

Well, I thought I'd blog on my thoughts on this!

You see, in the physical datacenter there is no firewalling between servers plugged into the same switch and because of this some people think, well if its not done in the physical world why should it be done in the virtual world.  I believe that its not done in the physical world today because there are no solutions today that embed security into datacenter switches.  Should it be done in the physical world?  I think so!  It never hurts to get security as close as possible to the things you are trying to protect and what better place than the switch port in which the critical asset are connected to.  This is why people have HOST BASED FW/IPS ON SERVERS!  To get security as close as possible!  Is that needed? 

So my first response to those that say, security between virtual machines is not needed because its not done in the physical world is:  Well, just because people have done things one way for many years doesn't mean there isn't a better way.

Would environments be more secure if there was security between servers?  I tend to think so.  You see, many of the attacks that are taking place these days are not attacks for fame but attacks for fortune and gone are the days where people just hacked to spread nasty viruses.  Its all about the data these days (ie. credit cards, social security numbers, etc).  We've all heard about the TJ Max security breach where customer data was compromised and many others like banks that have had credit cards compromised. 

How and the heck do you think most of these things happened?  Attackers are targeting the datacenter these days.  Physical or Virtual.  Their gateway into these environments are the Web Front End Servers.  Let me say that again.  The Web Front End Servers!  Hackers get to the data from the web front end server that talks to the database backend server.  This useually occurs by something called "Cross-Site Scripting" or "SQL Injection" breaches. 

Here is a trival way of how this happens:

A hacker finds a vulnerable web site.  He sometimes does this by something called Google Hacking.  He uses Google to search for sites that has vulnerabilities on it.  Say a web site has some content on one of the pages that says "Powered by Drupal 4.1".  If a hacker knows that Drupal 4.1 software has a vulnerability in it, he can now target all the search results related to this.  Click Here for more detail.

Now lets say Drupal 4.1 on a web site has a SQL-Injection vulnerability because the developer of the Drupal software didn't do Form Field Validation properly.  A Form field is something you fill out on a web page like a form that asks for the user name and password.  User names and passwords to log into the web site are stored on whats called a Database Server.  Hmmm... So this means the web server needs to talk to the database server right?  Yes!  Keep this in the back of our head for now.  The hacker enters in "Admin" for the user ID and "password doesn't matter 'or 1=1--" for the password.  And presto!  He is logged in to the server as Admin.

The reason he was able to log in is because the web site sends a SQL Database command to the Database server and because the developer of the Drupal software didn't do "Form Field Validation" properly (method of checking for invalid characters like the ' (single quote)  symbol), the user was able to bypass the password.  Notice the 'OR 1=1 command appended to the password.  One does equal one so therefore it will return a TRUE result to the password checker and the OR says use the password typed in (password doesnt matter) OR check to see if one is equal to one.  If its true then the password is valid for this user which is Admin.

Now that the user is on the web server, he probably has the ability to connect to the database server or other servers in the network.  Why?  Because there is connectivity from the web front end to all of the backend servers.  He essently can backdoor his way throughout the network.

Another method is for him to append some SQL statement to another SQL statement.  Lets say their is a FORM FIELD on the website that collects some information from the database to display it to web site users.  It could be entering in the Zip code to find store locations in your area.  Instead of putting in the zip code you could put in "95123 'UNION SELECT * FROM credit_card_table--".  The hacker is injecting via the UNION command (which means join one SQL statement with another one) a command that says grab all (via the asterisk) information out the credit card table.

Lastly, the hacker can use the UNION command to write text of his desire to a text file on the database server.  He may write some nasty code, tell the database to write the code to a file and then tell the server to execute that file.  The code could be used to do a denial of service attack to the other virtual machines or whatever.  The possibilities are endless!!

Anyway, these are high level examples.  I think you get the point.

The Web Front End Virtual Machine has a need to talk to the Web Back End Virtual Machine and security such as Firewalling, Intrusion Prevention definately needs to be in place to have a higher level of security.

Another reason to have security between virtual machines is because servers are now mobile in the virtual world.  They move between trust domains to take advantage of computing resources that may be available on a given piece of hardware.  Lets say one PHYSICAL server was hosting database VM's and another PHYSICAL server was hosting file server VM's.  The file server VM could VMOTION to the same environment as the database VM's.   Now where is your isolation between trust domains or unlike resources?

People should think about this problem in greater detail.  I'd love to hear everyones comments as to whether or not they think security between VM's is needed.

John Peterson
Montego Networks

But two weeks ago a jury in the civil lawsuit against that employer, NDS Group, largely cleared the company -- and by extension Tarnovsky -- of piracy, finding NDS guilty of only a single incident of stealing satellite signals, for which Dish was awarded $1,500 in damages.

"I knew this was going to come," Tarnovsky says. "They didn't have any proof or evidence."

The trial was years in the making, yet raised more questions than it answered. It came down to testimony between admitted pirates on both sides who accused each other of lying. Now that it's over Tarnovsky, who was fired by NDS last year, is eager to tell his side of the story.

Dressed in loose jeans, flip-flops and a T-shirt, Tarnovsky, 37, spoke with Wired.com by phone and in an air-conditioned lab in Southern California where he's been running a consultancy since losing his job. Surrounded by boxes of smart cards and thousands of dollars worth of microscopes and computers used for researching chips, he talked excitedly at lightning speed about his strange journey, which began in a top-secret Pentagon communications center, and ended with him working both sides of a heated electronic war over pay TV.

His story sheds new light on the murky, morally ambiguous world of international satellite pirates and those who do battle with them.

The stakes are high: Earnings in the satellite-TV industry reach the billions. In the first quarter of this year alone, U.S. market leader DirecTV announced revenue of $4.6 billion from more than 17 million U.S. subscribers. Dish Network earned $2.8 billion from nearly 14 million subscribers. Although satellite piracy has greatly diminished from its peak seven to 10 years ago when the events detailed in the civil lawsuit took place, the two companies lost millions in potential revenue, and spent millions more to replace insecure smart cards used in their systems and track down dealers selling pirated smart cards.

Those smart cards are at the center of the controversy over NDS, a British-Israeli company and a majority-owned subsidiary of Murdoch's News Corp. The company makes access cards used by pay-TV systems, most prominently DirecTV -- itself a former Murdoch company. Nagrastar, a plaintiff in the case and NDS's chief competitor, makes access cards used by Dish Network and other runners-up in the market.

According to allegations in the lawsuit, in the late '90s NDS extracted and cracked the proprietary code used in Nagrastar's cards, a fact that NDS doesn't contest. What happened next, though, is hotly disputed. Nagrastar says Tarnovsky used the code to create a device for reprogramming Nagrastar cards into pirate cards, and gave the cards to pirates eager to steal Dish Network's programming. Tarnovsky was also accused of posting to the internet a detailed road map for hacking Nagrastar's cards.

Nagrastar says NDS had an obvious motive for these antics: Their own chip, the so-called P1 or "F Card," had already been thoroughly cracked by pirates, and the company wanted to level the playing field with its competitors.

NDS denied the allegations at trial. The company declined to comment for this article or to confirm details of Tarnovsky's employment other than to say it was pleased that the verdict "ended in a resounding affirmation of NDS and its business ethics and proper conduct."

Tarnovsky began his pirating career in the '90s while serving in the U.S. Army. He had a top-secret SCI security clearance working on cryptographic computers in Belgium for NATO headquarters, and spent a year at Ft. Detrick in Maryland providing support to the National Security Agency for satellite transmissions to Europe.

In 1996, he was stationed in Germany when his colonel sold him a used satellite-TV system, along with two pirated access cards, neither of which worked. Tarnovsky began posting on online pirate forums, and developed contacts in the community, ultimately learning how to fix the cards to access English-language programs from Sky in the United Kingdom.

After leaving the Army and returning to the States, he got a call from Ron Ereiser, a Canadian pirate who'd heard about him through the grapevine. Pirates had found a back door in the P1 card and were vigorously exploiting it to get DirecTV content. But the cards kept failing. In a game of pirate pingpong, DirecTV periodically deployed electronic countermeasures, or ECMs, in the satellite stream that killed the cards in their set-top boxes. Ereiser needed someone to fix the cards.

There was serious black-market money on the line. In Canada, where pirating of U.S. satellite services wasn't considered illegal until 2002, syndicates of dealers did enough business that they could afford to chip in about $50,000 to hire a programmer to reverse engineer the latest cards. Pirate cards would sell for about $200 each, with the profit split between the investors and engineers. Tarnovsky claims Canadian pirate dealers could make $400,000 in a weekend; when Reginald Scullion, a notorious pirate in Canada, was raided in 1998, authorities seized $5.5 million from his bank accounts and safe-deposit boxes, though not all of it was from piracy.

Ereiser, who now works as a consultant to Nagrastar, concedes that the money from piracy was good, but insists that nobody became an overnight millionaire. "It was lucrative," he said in a telephone interview. "But to suggest that millions were being made in a month is an absolute crock."

DirecTV's countermeasures were a nagging drag on this lucrative trade. Every time an ECM was deployed, Ereiser and other dealers would be harangued by customers demanding to have the cards fixed and their TV programs restored.

Tarnovsky, who was known online as "Big Gun," says Ereiser offered him $20,000 to fix cards that were killed by ECMs, and he agreed. Each time NDS created a countermeasure, Tarnovsky would analyze the code and find a way to circumvent the countermeasure. He did it while working full-time as a software engineer for a semiconductor company in Massachusetts.

"I'd be at work and I'd check the IRC (channel) to see if they'd launched their Thursday countermeasure yet," he says. "It was like a chess game for me. I couldn't wait for them to do a countermeasure because I would counter it in minutes."

Tarnovsky suffers from attention deficit hyperactivity disorder, which he says helped with the detailed work.

"I think so fast," he says.

It wasn't long before NDS came courting. Tarnovsky had a contact at the company to whom he'd begun passing information about holes in its software, even supplying patches to fix them. NDS offered him a job earning $65,000 a year. By the time the company fired him last year, he was earning about $245,000 in salary and bonuses and had another $100,000 in stock options, he says.

The company set him up in a lab in Southern California equipped with a computer, some DirecTV set-top boxes, sample DirecTV cards and NDS source code. There was no fancy equipment at first, but his relationship with NDS and the lab grew over the decade he worked with them. Tarnovsky says the job was a dream come true. While living in Europe he'd once seen a news report showing an engineer at a French satellite company writing countermeasures, sitting in a lab with smart cards piled around him on his desk.

"I always thought it would be so cool to be that guy," Tarnovsky says. "Finally I got the chance."

Tarnovsky had two roles at NDS -- to find holes in its software and work undercover with pirates to discover what they were doing against NDS technology.

To conceal his relationship with NDS from pirates, few people at the company knew his identity. He used the name "Michael George" and for the first four years was paid through other companies, including, for about five months, HarperCollins, the Murdoch-owned book publisher.

"It was very hush-hush, because we didn't know who could be an inside informant," he says.

Part of his job was developing ECMs for NDS. He'd examine pirate NDS cards to determine how they worked, then send instructions to engineers in Israel to create a kill for them.

"I didn’t actually load the gun and pull the trigger but I got to make the bullet," Tarnovsky says.

Among the countermeasures he says he created was one known among pirates as the "Black Sunday" kill -- an elaborate scheme that destroyed tens of thousands of pirate DirecTV cards a week before Super Bowl Sunday in 2001.

Instead of being delivered all at once like other measures, the Black Sunday attack code was sent to pirate cards in about five dozen parts over the course of two months, like a tank transported piece by piece to a battlefield to be assembled in the field. "They never expected us to do this," Tarnovsky says.

The kill didn't last long before pirates found a way to jump-start the cards. But it holds an enduring position in pirate lore; for the first time, they could see a cunning mind at work on the other side.

While Tarnovsky was killing cards, however, he was also helping pirates fix them.

Days before Tarnovsky began working for NDS, the company began phasing in its latest-generation smart card, the P2, which was thought to be virtually uncrackable. But word reached the company that two Bulgarian hackers working for Ereiser had cracked the P2. On NDS's instructions, Tarnovsky met with Ereiser undercover in Calgary to get the code. When he got there, Ereiser offered him $20,000 to work for him fighting whatever countermeasures NDS and DirecTV cooked up to thwart their P2 hack.

NDS considered it a great opportunity for Tarnovsky to maintain his pirate identity, but DirecTV insisted on some controls. Under "Operation Johnny Walker," as they dubbed it, Tarnovsky gave Ereiser a program to create pirate NDS cards, but encrypted it so no one could copy it. The program worked only with a dongle attached to Ereiser's computer and created a limited number of cards that could be killed at any time.

But, according to Nagrastar, Tarnovsky wasn't just helping NDS fight piracy by working undercover and creating ECMs, he was also committing piracy against NDS's competitors to weaken their place in the market.

After NDS engineers in Israel hacked the Nagrastar code in the late '90s, Nagrastar says Tarnovsky created a "stinger" program that turned Nagrastar cards into pirate cards. He allegedly gave the program to a Canadian named Al Menard in 1999 who sold reprogrammed Nagrastar cards for $350 each. Then in December 2000, someone anonymously posted code and detailed instructions for hacking Nagrastar's card to two websites, one of them run by Menard, exposing Dish Network to even more piracy. It was estimated in court testimony that between 100,000 and 165,000 pirated Nagrastar cards were released to the market in the wake of this posting.

Nagrastar says Menard began sending Tarnovsky cash from the sale of the pirate cards. At the end of August 2000, authorities acting on an anonymous tip seized two boxes destined for a mail drop Tarnovsky rented in Texas. Inside, they found a CD and DVD player with $20,000 and $20,100 concealed inside.

The boxes were sent from a phony address for "Regency Audio" in Vancouver to C.T. Electronics at Tarnovsky's address. A customs form for a third package that wasn't seized indicated that it was sent from Menard to Tarnovsky and also contained electronic goods.

Tarnovsky was in Israel at the time, and says he didn't know anything about the packages until he was notified that they'd been seized. He thinks they were sent by someone in Nagrastar's camp who was trying to frame him. He says Nagrastar's accusations about the "stinger" program were baseless, and that he never gave Menard any software.

On Feb. 9, 2001, U.S. Customs agents appeared at his doorstep. On advice of a lawyer, he declined to let them search his house without a warrant. Tarnovsky was never arrested or charged with any crime, but suspicions against him were mounting. NDS gave Tarnovsky a polygraph test, but asked only two, self-interested questions that never touched on the Nagrastar accusations: Had Tarnovsky sold any modified NDS smart cards, or company secrets, since he'd been working for the company? Tarnovsky answered no, and passed the test.

He continued to work for NDS for six years. But then last year, Nagrastar confronted NDS with a sheriff's report showing that fingerprints lifted from the seized electronics equipment sent to Tarnovsky's Texas mail drop belonged to an associate of Menard, raising suspicions again that Tarnovsky might have sold pirate Nagrastar cards without NDS's knowledge. NDS fired him.

Tarnovsky says his termination proves he and NDS weren't conspiring against Nagrastar. Had they been, NDS would have done anything to keep him happy, and quiet. He says the fact that Nagrastar lost the case shows he wasn't pirating on his own either.

"I've never sold a single Nagra card, ever," he says.

Although he was angry at NDS for abandoning him, he told Wired.com before the trial ended that he hoped to work for the company again.

"I want to make sure that NDS wins this lawsuit because that will clear my name," he said at the time.

When it was suggested that someone might view this as motivation for him to lie on NDS's behalf, he disagreed.

"That's crazy. I could go to jail," he said. "I would never perjure myself for some company."

Since NDS fired him he's been consulting for two semiconductor companies and a manufacturer of dongle tokens, but he misses his life in electronic warfare. If NDS doesn't want him, he says he'd be happy to work for Nagrastar -- jumping sides once again.

"I could design a whole entire chip for them like I did for NDS," he says. "NDS thinks today that their technology is superior to everybody else's and it probably is, because they're 17 years ahead of Nagra technologically. But Nagra could catch up overnight if they used my services.

"I'm a very valuable asset as far as smart-card technology goes," he adds. "I know everything about (NDS) as far as their intellectual property models go."

He offered his services to the company last year, while the lawsuit was pending. Nagrastar declined.

You can then use the framework to assign priorities and phasing for Information Security actions. So instead of letting the random auditor and their everpresent checklist that the final four assigns you drive your program, use a framework that incorporates the business and its goals. A number of people commented on my post on GRC -

Rich Mogull

Much of what we call GRC should really be features of your ERP and accounting software. ... It’s an additional, very highly priced, reporting layer. ...A GRC tool provides almost no value at the business unit level, since it doesn’t help them get their day to day jobs done.

Mike Rothman succinctly gets to the point with a one liner I am sure will become part of my repertoire:

It's about serving the business, NOT THE AUDITORS. If you protect information effectively (which is a key imperative for the business), then the auditors should be kept reasonably happy. And if not, screw them and fight them. Yes, the auditor can make your life a bit harder, but you don't work for them. Keep that in mind.

So my GRC post seemed to tap into a fair amount of GRC blogohostility , fair enough, but the main point is not slamming GRC, just the overfocus on GRC and substituting misdirected marketecture for real world architecture Hoff got to the heart of the point of what i was saying - its about assets

As I think about it, I'm not sure GRC would be something a typical InfoSec function would purchase or use unless forced which is part of the problem. I see internal audit driving the adoption which given today's pressures (especially in public companies) would first start in establishing gaps against regulatory compliance.

If the InfoSec function is considering an approach that drives protecting the things that matter most and managing risk to an acceptable level and one that is not compliance-driven but rather built upon a business and asset-driven approach

So I submit that you should not start with a compliance checklist, but instead build a security architecture blueprint that captures your stakeholders goals. Assess this against your policy and standards, and your security architecture capabilities. Out of this comes risk management decisions. And off we go into actually building and operating something - hopefully making some profits along the way.

So build blueprints, minimize time spent doing checkbox Olympics. The blueprint I worked on is just generic framework, you may have a different one. I know that the one that I designed is in use in many organizations and in each case I know of it has been tailored to local purposes. So its a beginning not an end, but those two things are more related than you think as someone from the financial services industry once said

In my beginning is my end ... in my end is my beginning

Where you start your security architecture and design matters, and directly effects where you end up.

Anyway, the conference was a lot of fun, I rarely get to do conferences in MN. I got meet Anton Chuvakin for the first time, and went to the presentation on the local OWASP Minnesota chapter - Robert Sullivan, Joe Teff and Kuai Hinojosa did a great job doing an overview of what OWASP is all about, demoing WebGoat and so on.

Good presentation skills are an important and valuable asset. Selling the benefits of an information security program or project can be challenging so it's good to be armed with a good set of techniques for getting across the right messages regardless of audience or the amount of time available.

The rationale behind this answer is based on the fact that weakness (a.k.a. vulnerability) is a relative term. Logically, a relative term requires at least two components – one relative to another. Oh, it’s true that the “flawed” condition within the operating system existed all along, but in order for that condition to actually BE vulnerable, the capability to exploit the condition had to exist. And within the context of a human threat community, capability requires two things: knowledge and resources. Consequently, until the condition was known to be exploitable, it couldn’t be leveraged and wasn’t a vulnerability.

So, if a vulnerable condition occurs when available force becomes greater than the ability to resist that force, then vulnerability can come about in one or more of three ways:

1. Resistance strength is diminished in some manner (e.g., cutting part-way through a rope)

2. Available force increases so that it exceeds existing levels of resistance (e.g., more weight is added to the end of the rope)

3. An asset is newly exposed to threat elements, either because the threat elements are new to its landscape or it enters a threat landscape it didn’t exist in before (more on this in a second)

Regardless of the cause, whenever available force becomes greater than the ability to resist, you have what can be referred to as a “vulnerability event” – i.e., vulnerability now exists where it didn’t before.

In our operating system scenario, nothing changed about the operating system itself. What changed was threat capability, which increased as soon as the threat community became aware of the condition’s exploitability. At that instant, the knowledge component of the threat community’s capability changed, and their resources likely changed soon after, when exploit code was developed.

Vulnerability, not loss

Here’s another example prompted by an excellent question posed by Stacy on the “layer8.itsecuritygeek blog — essentially, how should we classify “near miss” events where, for example, someone sends sensitive information unencrypted over the Internet? Is that a “loss event”? By my reckoning, the answer is no – unless and until actual loss to the organization materializes. Instead, it’s another example of a vulnerability event – i.e., vulnerability to loss now exists where it didn’t before (ref. #3 above).

Why “vulnerability events” matter

If history provides any clues to the future, some folks are going to question why I feel the need to define yet another term. It’s a fair question (pun intended).

If you’re familiar with FAIR you already know that we define two other event types – Threat Events and Loss Events. Threat events occur when a threat agent acts against an asset. Loss events occur when loss results from a Threat Event (i.e., as happens when force exceeds resistance). The reason it’s important that we make distinctions between event types is three-fold:

• It helps us to better understand our problem space, which is always a good thing,

• It allows us to communicate more consistently and effectively, and

• It enables us to identify and make meaningful use of metrics

This last point is especially important as we try to make better use of metrics.