Michael Mongold's Technology Security

Disk Encryption and NAC

The integration of disk encryption and network access control is something that I have been preaching for awhile and I thought we were starting to see a little bit of that here.  Unfortunately I don't see anything with that combination that isn't already available from a number of other encryption vendors.

Ultimately, we will see network access control providers that are able to allow/disallow devices that are connecting to the network based upon the encryption status of the hard drives. Why? Because encryption is hot right now and if NAC providers can piggy-back onto that techonology they might be able to push a few more sales.

At some point organizations are going to want to insure that all their devices that are connecting to their network are encrypted. NAC can easily provide that functionality. This will allow organizations the ability to segment non-encrypted devices to areas of the network that are free of sensitive data.

I'm calling it out, let's see who steps up.

Michael Mongold

Technorati tags: Michael Mongold, NAC, data, encryption, ControlGuard, PGP

Data Loss to the Maxx

So you have a situation where you KNOW someone broke in and pilfered a lot of data but because of your data retention policies you are unable to accurately say how much is lost.

From TJX's 10-K filing: "We are continuing to try to identify information stolen in the computer intrusion through our investigation, but other than the information provided, we believe that we may never be able to identify much of the information believed stolen."

But, in reality, not even their data retention policies were  being followed because there was a nine month period where the data was supposed to be deleted and was not.

Of particular interest to me is in an article by information week that states:

"TJX's security may have been further compromised by the cyber criminals having access to the decryption tool for the encryption software that TJX uses. This could have been the result of an insider or a successful hack by the cyber thieves into a TJX database where the keys were stored."

Poor TJX, they are learning a hard lesson in the dangers of encryption key management. If the keys to the kingdom are not truly safe then you are risking being the poster-boy for bad security.

Security is a multi-dimensional environment that requires protecting at every angle. They made the first couple of steps in the right direction but failed in the execution of insuring application encryption was fully and properly implemented.

We won't even talk about the fact that their perimeter was egregiously violated. From July, 2005 to January, 2007 (the last stolen data was December, 2006), intruders swiped data at will. 

TJX has already spent $5 million dollars on their investigation and this is before the lawsuits have started piling up.

There are some good comments out there about where TJX went wrong but ultimately I believe that it is a combination of a large amount of sensitive data not being given the attention it truly deserves. Measures were taken but not implemented uniformly. Security teams did not press their C-level bosses as though their jobs depend upon it, and they should have.

There are real bad people out there. It's not just some kind of industry-hype to make people buy our products. If you're a security professional, push this as though your lively hood depends upon it.

Those that you are accountable to, will hopefully never know how much they owe you for it. The CEO of TJX certainly knows this first hand.

Michael Mongold

Technorati tags: Michael Mongold, TJX, TJ Maxx, Encryption, Data, Theft

Encryption over the LAN

I had the opportunity to sit in on a presentation given by Mark Carboni of Utimaco discussing their product LanCrypt. I have to say I was very impressed by the functionality of the product and the thought given to its design. The product is basically a way to centrally administer the encryption of shared documents. LanCrypt allows multiple levels of administration to define various sets of policies and apply them to different users so that they are only able to access the documents that they should have access to on the network. All of it is done via the groups already in your LDAP/Active Directory/NDS infrastructure. I found the products ability to scale between very granular access to global rules to be incredibly intuitive. Additionally, key management is a snap (basic x.509 cert that can be saved on any kind of token) and it's ability to work even while the backend database is offline is a big plus. They also allow for split-authentication (or what Mark calls "Four Eyes Technology") that basically says you need multiple people to be present to allow for certain access/modifications. Suffice to say, I look forward to playing with the product more in the future.

If you have a product that sounds similar (Pointsec MI, etc.), let me know about it. Or if you have exerpience with LanCrypt I would be interested in your observations of the product.

Also, in the spirit of full-disclosure, it should be stated that I have worked with Utimaco's team in the past and probably will in the future. However, I am vendor agnostic and non-judgemental when it comes to encryption products due to the different encryption manufacturers I work with on a daily basis.

 

Michael Mongold

Technorati tags: Michael Mongold, Utimaco, LanCrypt, Pointsec, encryption, technology, data

A few random notes from today...

First, for all of the true geeks out there you can find some sexy geek machines in an article at computerworld.

 

For those who think that carrying printed data is a safe option, then you should check out what this poor sucker is going through...

 

Here is an article that is just crazy talk. The majority of people don't encrypt their e-mails? I just can't believe it! Man, where can I get some money to do studies like this...

 

This is an article that points out that VOIP is insecure. I love working in an industry that creates a technology that lacks proper security and then sells the same customer security for that product. Genius!

 

There's a couple more tasty morsels but I want to delve into them a little deeper tomorrow.

 

Enjoy!

 

Michael Mongold

NAC and Cheese for breakfast...

There is an "interesting" article concerning how NAC products are "impossible to manage" on Computerworld's website today. I happen to like the concept of NAC and have seen a number of manufacturers work well in a number of environments. I have also seen it fail miserably during the very very early days of NAC, but that seems to have gone away as the products have matured.

Mark Bouchard, a consultant speaking at a Computerworld breakfast covered in the article, re-labeled NAC - "Network Access Confusion". HA HA! Well, I may disagree with Mr. Bouchard's analysis of NAC but at least he has a singular wit about him. And I would agree that there is a number of individuals that are confused about Network Access Control and apparently Computerworld found a few of them to speak at this breakfast.

Of course there are the obligatory numbers that come from somewhere and show NAC vendor revenue increasing from $323 million in 2005 to $3.9 billion in 2008. That is a lot of money and one that I am sure someone on the outside of the NAC world would like to deflect their way.

Curiously, he also states a "slow growth curve" for the integration of NAC in 2007. Only 10-20% in the coming year, it looks like. Sooooo, ONLY 10-20% of all enterprises are going to deploy NAC this year? Uhhhhh, I don't believe it. Don't get me wrong, I like NAC but I think that would be a little overly optimistic - at least on the high end. Regardless, how are organizations going to deploy something so frightfully confusing? Jeepers, are you scared yet?

My favorite quote from Mr. Bouchard is the following:

It relies upon knowledge of the network, the user and the access controls in place to function properly.

Gulp!

Now you need knowledge of your network! This whole NAC thing sure is tedious.

Grrrrr

Folks, yes you will need knowledge of your network. Also, a good NAC product will integrate access controls into their enforcement functionality.

NAC will not cure all of the ills of the world. However, I assure you, when you power it up for the first time and start testing devices that are attaching to your network and you see how out-of-shape, out-of-date, and dirty these devices are, you will see the value of the product within the first 10 minutes.

I will never forget playing around with a NAC product in my company's office for the first time (very old 1st generation stuff). There were devices that were behind on anti-virus patches, windows patches/hotfixes, P2p software, etc. all over the place. We were not even quarantining the devices yet, but rather just looking at what was out there. It was ugly.

It kind of reminds me of tearing out our carpet this weekend to make way for some stained concrete. We tore up the carpet and looked underneath and it wasn't pretty. That was a very similar experience.

So, the rest of the article is spent by a guy at Sourcefire saying why NAC is bad (while pushing how good IPS is). Of course this would explain why Tipping Point is making such a big play in the NAC market. (What are the odds that within the next twelve months Sourcefire will be pushing some form of NAC functionality in their products?)

I like NAC and what it can offer. I'm not knocking IDS/IPS because I think they have a role in protecting networks. I think that data loss protection may be too expensive for some (at this time), and unavoidable for others. I absolutely agree that Encryption and Security Information Management are hot, but more the former than the latter.

Ultimately, all of these products complete a piece of the puzzle that creates a picture of data security. One device is not going to be the solution. Qualified security professionals working with a number of different devices present the best answers for these issues. Manufacturers working together to follow a defined standard (such as TCG) to improve interoperability helps provide more flexibility to those security professionals.

The reason so much money, so much hype, and so many companies are focused on NAC is because there is a need for it and it is part of the solution.

Michael Mongold

 

Technorati tags: NAC, Encryption, Sourcefire, Tipping Point, Computerworld, IDS, IPS, Data Loss Protection, Michael Mongold

Send me my password...

Let me know if this sounds familiar: You are visiting a website that requires you to create a profile in order to gain access to the site. So you put in your name, perhaps an address, an e-mail address, a username, and a password. Everything is great, you gain access to the website, you buy the sock monkey slippers you were dying for, whatever. Then you check your e-mail and BAM! There is an e-mail from the website you just signed up on, letting you know your username AND password that you just entered on their website. Holy credentials, Batman! This is such a poor policy and one that makes me cringe to think who is running security at these organizations. I know that they mean well and just want to make sure you have your password so you don’t forget it, but it’s really not doing you a favor.

A password that is sent in a non-encrypted e-mail should be only one thing, temporary. If anyone thinks that what is in their e-mail is secure, that person needs only to Google for "email password". Additionally, it does not matter that you have encrypted e-mail on your end if they have not encrypted e-mail on their end because they are sending YOU the password.

If a password is sent to a user, it should be a password that was generated by the website and forces the user to reset the password the next time they login. Too many people use only one password for everything, thus if you entered your usual password on the website, your domain password and bank website password are now sitting in your e-mail. Bad policies and bad habits can combine to create an very bad situation.

So, next time, if you receive your self-configured password in an e-mail, let the organization know that you do not appreciate the lack of concern for your privacy. It is simple for the website to correct and when resolved, will show they are doing what is right for their customers.

Michael Mongold

NAC Defense

With any new product technology that is introduced into an industry, there will be evangelists and naysayers, highs and lows. Network Access Control is no different. I think what I find most interesting is the amount of buzz that has been generated over the last couple of years for the technology. I have read some articles that equate NAC to a product in search of a problem. Apparently, they are not speaking to the customers I have come in contact with.

I typically interact with customers that are pursuing data encryption but when I segue over to Network Access Control, they inevitably become very interested in the technology. And why wouldn't they be? If a product can help insure that devices that are connecting to your network are compliant with the security policies you have set in place, that seems like a good thing. Not to oversimplify things here, but companies are being hammered to show due diligence when it comes to their efforts towards technology security. This product helps them to that end. As PART OF a comprehensive security solution, NAC is an essential element.

While there are some organizations that may have had some misses with their deployments; that seems par for the course of technology. There are misses and there are hits, those that miss go away and those that hit the home run become the market leaders. There is going to be a shake up in the market soon. In the beginning of every release of a product technology, there are a multitude of players that are trying to stand on each other to be noticed. Then natural selection kicks in and the weak and unlucky are weeded out.

Critics should stand back and look at the bigger picture and take a peek at the longer time line and place NAC in its appropriate stage of development and growth. There is no reason to believe any hype that purports NAC to be the cure of all ills, nor should industry types overlook the importance of including Network Access Control into any security solution they provide to their organizations and/or customers.

I have complete confidence that NAC will become centrally integrated within all major organizations within the next 2-5 years. The need is there, the demand will soon follow.

 

Michael Mongold

What a tangled web we weave…

What a tangled web we weave…

I imagine that most technology security readers are aware that Oracle has sued SAP for acts of industrial espionage that represent "theft on a grand scale."  By using the credentials of Oracle's customers and generating SAP's own credentials on Oracle's website, SAP was allegedly involved in some blatantly subversive activity.

Now I do not want to sentence SAP before they have responded, that is not proper. But I do want to point out that it is not a stretch to think that a large legitimate company would involve itself in an illegal activity to further its success.

Oracle should be aware of this considering it was sued by J.D. Edwards in 2003 to the tune of $1.7 Billion for wrongful conduct and unfair business practices.

The fact that SAP has within its organization the Apollo Group, a self-professed “Attack Oracle” group designed to combat Oracle does not bode well for SAP’s defense.

In the past year we have seen HP executives bringing the word “pretexting” into the common vernacular. An incredibly dirty and illegal method of obtaining information under the “pretext” that you are the owner (or someone who should have access to) that data. Now it appears that KPMG is also involved in a pretexting matter.

Wal-Mart just a few days ago apologized to The New York Times for spying on TNYT by intercepting text messages and phone calls of Wal-Mart employees and journalists. A matter that I believe will get much worse by the time it is done.

HID threatened legal action by raising the specter of patent infringement when a security researcher attempted to show the vulnerabilities of their technology. This could have a stifling affect on the technology research that is performed daily to better the technology sector.

 

And then there is the Telecom Italia fiasco where a team of security personnel at Telecom Italia infected publishers with a Trojan and stole documentation from their laptops. Then one of the members of the group had the gall to show the publishers their documents that were stolen and offered to take over the publishers’ security so they would be better protected.

Outside of the world of technology, there are also plenty of issues: Chiquita, for example, gave $1.7 million between 1997 and 2004 as protection money to Columbia’s United Self-Defense Forces, defined as a terrorist organization by the US Government.

It’s a shady world, folks. And just because you are paid well and everyone can speak proficiently on technical matters does not mean they have the moral fiber to avoid such lascivious behavior. I am constantly amazed at how smart people can be so under-handed. If you haven’t seen “Enron: The Smartest Guys In The Room”, please rent it soon and observe.

Technology is truly a device of our own creation. We can either give it the ability to make our existence better or we can pollute it with that which is the worst in us.

Michael Mongold

This Is Harder Than I Thought...

Within the past couple of weeks, I have come across information that indicates that some organizations sold on the value of certain hard drive encryption technologies are more problematic than they are worth. I am not going to mention them by name but there are two data encryption software companies that are in the process of being booted or are already OUT of deals that were already signed, due to the difficulty in deploying them.

Now, it is important to note that encrypting a hard drive can be an invasive process that requires a number of resources and some time in order to deploy properly. And that is if it is performed correctly. Mistakes in the testing phase, misrepresentation by the sales monkeys, and over-expectations by the customer can make an installation even more complicated. Nothing too significantly different than any enterprise software deployment, right? Well, not exactly.

See, hard drive encryption is a rather stressful event for a drive to endure. It touches every sector on the hard drive (if it doesn't you bought the wrong software) and gives the ole platters and apertures a good work out. So, right off the bat, before you deploy one copy of an FDE product, make sure you perform a chkdsk such as the following:

chkdsk c: /R /F

This will take care of a couple things for you: 1) it will give your disk a good stress test to insure it can handle the rigors of being encrypted, 2) it fixes the errors on the disk, and 3) it locates the bad sectors and recovers readable information. This could, of course, cause your hard drive to fail if it is on its last legs or could result in lost data due to the fact that a sector that was marked bad is no longer accessible and that sector happened to contain an important piece of data.

So, you must step back a little bit further and make sure you have been practicing a prudent backup policy within your organization. If you have not, then you are just a few errors from unemployment as it is and should concentrate more on your resume. But I know YOU are making sure that no xls, doc, ppt, pdf, mdb, or, MOST of all, pst files are being stored locally, or if they are, they are being backed up regularly so there is no need to hit Dice just yet.

So once you have verified your backups are working well and that chkdsk with repairs has ran on all of your devices, you are ready to think about encrypting the hard drives. And we're not talking a gentle recommendation here. You will see a drop from failure rates as high as 25% to less than 1% if you just run a chkdsk. Granted the organizations that hit the 25% mark were using some old hard drives. So, do it. A hard drive that fails during encryption can be an unpleasant thing.

Next you have deployment. This is where companies shoot themselves in the foot. Hard drive encryption companies come in and show what a great backend they have. They have glossy presentations that show a sexy user interface and tons of reporting that can be done at the drop of a hat. But, they don't get into how difficult this is going to actually be to deploy. So, now you're going to need a new dedicated server with someone who knows it inside and out and how the management works with all of the keys that must be backed up. Ah, the keys. What a pain in the ass. Trust me when I say that almost none of the companies out there want to get into key management when they are trying to sell the product to you. They may have to talk about it because you are asking, but they know it's not pretty.

You really have to think about hard drive encryption a little differently. It is not something that needs to be touched after it is deployed. Think of it like scotch guard for a couch that never wears off. If you had scotch guard that you sprayed on your couch that never wore off, why would you ever mess with it again? And really, hard drive encryption should be that simple. You encrypt the drive and never touch the encryption software again. It does its job quietly in the background and that is it. Thus, the whole backend management really complicates what should be a transparent process to the IT staff and the users. To deploy the product, you simply should be able to push it out via SMS, Altiris, etc. and never have your end user be the wiser.

Ultimately, transparency is the key. Don't interfere with your end user's ability to do their work. Do not change the experience that the end user is accustomed to. This will make the help desk and IT department in general, a much happier place to be.

Also, a note on Pre-Boot Authentication:

I personally do not recommend for most customers that they use Pre-Boot Authentication. Most users will require significant training to deal with a PBA screen popping up to them when they turn on their computer.

Now you and I may not be phased by this but if you are like some of our customers - someone who is forced by their boss to use one of these new fangled computer thingies then the first thing you're going to do when you see that alien screen pop up immediately after you turn your computer on is... call IT. Then the help desk call board lights up like a Christmas tree that was placed too close to the menorah and suddenly you are much less popular for just trying to protect everyone's data.

So, skip the PBA, the hard drive is still encrypted, bad guys can't use l0phtcrack, or slave it, or boot to a live cd and read the hard drive. It's all good. There are some POTENTIAL vulnerabilities but nothing within the realm of the probable or realistic. And if you want to know more about those vulnerabilities, I'll run over them in another post.

If you go for the simplest yet securest solution, you will find it the easiest to deploy and manage.

Data Incontinence Syndrome

I have to start with saying, I am not a huge fan of the term "Data Leakage Prevention" Sorry, McAfee - I know that you can get some easy name recognition with a number of TV manufacturers promoting DLP (how they are promoting data leakage I'll never know). (wait for it) Ok, I kid I kid. Plus, we know that humans can only remember three letters at a time and if we were to go beyond that mental boundary we would immediately spin off into the abyss never to return again.

So we have DLP but some manufacturers out there like Information Leakage Detection and Information Leakage Protection.

Noooooooo

Not another IDS/IPS mish-mash! ILD/ILP makes DLP look like a linguistic paradise.

However, the real crux of the issue for me is the middle word in all of this - leakage. I am sorry but when I see that word I have an association in my brain with Depends udergarments and incontinence issues. This is not really what I want to envision when I'm plying away at work. Perhaps the industry should just jump both feet in and call it data incontinence prevention to help us with our data incontinence syndrome. Wouldn't our customers be able to better understand what we're selling if we related our products to biological functions? I suppose there are some similarities that are already out there. When your desktop blue screens and states it is taking a dump, there is certainly some correlation between the mechanical and the biological at that point.

Now there are some that are promoting the term Data Loss Protection.

Hmmmm

OK, well it certainly has a familiar ring to it without conjuring up images of people dribbling in their diapers. Which for me, is a good thing. And I have to say I like the idea of being protected more than prevented since prevention seems only before the fact and just not as warm and fuzzy as being protected. So, I think that henceforth I will call products that protect the loss of data - Data Loss Protection. Unless everyone likes the incontinence stuff.

Michael Mongold