Bit9

Skip Navigation
 

Enterprise Application Whitelisting

Current Articles | RSS Feed RSS Feed

The iPods data hole - an argument for device control

Posted by Naveed Ihsanullah on Thu, Jan 29, 2009
  | Share on Twitter Twitter | Buzz This  Google Buzz | Submit to Digg digg it |  Share on LinkedIn LinkedIn 

 

This article, man-buys-used-ipod-gets-60-pages-of-sensitive-military-data.ars, on Ars Technica made me both laugh and groan. The subject of the article purchased a second hand mp3 player. Apparently the former owner was using the device as a removable storage disk to ferry data around. Many of us have done exactly the same thing. The difference, however, is this data contains the names and personal details of US soldiers

 

The US government has many rules and processes that govern secure data. There is a wealth of information on this at the Federal Information Security Management Act (FISMA) NIST site.

 

We can guess at which rules and what processes the original owner violated to enable this breach. That exact rule broken isn't as important as recognizing this breach happened because it was possible in the first place. 

 

In the effort to get jobs done short cuts often are taken. I can certainly think of a scenario where, in a time crunch, this government employee took some secure data home so they could finish up their task over a weekend. His employer may have acknowledged the sensitive nature of the data he was working on and required that this data exist only on computers attached to a secure network that has no connection to the internet. Unfortunately that tempting front mounted USB port calls to people. They bring in their camera and music player, their USB keys and webcams. Heck they may even bring in their USB rocket launchers to blow a little steam at the end of a tough day.

 

This article isn't the first time that removable storage has led to data loss.  The massive TJX breach comes to mind. More recently the details of more than 6,000 prisoners was lost. Through malicious and accidental acts gigabytes of data leak out USB ports around the world.

 

Physically removing USB ports may work for some organizations. Some have even suggested epoxy as an answer. USB ports have their uses, though, and these tactics are often too extreme. Antivirus and application whitelisting software can prevent the running of malicious code from these devices but they don't adequately address data loss issues. 

 

What then is the answer? Whitelisting hardware is something that is still in its infancy but for this class of problems I think it shows a lot of promise. Selectively allowing USB devices by the device's serial number or by the logged in user allows a flexibility that none of the others solutions posses, not even epoxy. :)

 

I would love to hear your thoughts on these issues. Are there better solutions out there that we, the security industry, should be exploring?

 

 -- 

Ex post facto introduction - Since this is my first time blogging for Bit9 a quick introduction might be in order. My name is Naveed Ihsanullah. I have worked in the field of software development and security for the past fifteen years. I have always been a firm believer in white listing as a solution for IT infrastructure control and to the ever increasing glut of malware. After hearing about the exciting Parity product, I joined Bit9 in Autumn 2008 as a Development Architect.

0 Comments Click here to read/write comments

Making Firmware Software Trustworthy

Posted by Mario Vuksan on Sun, Jan 25, 2009
  | Share on Twitter Twitter | Buzz This  Google Buzz | Submit to Digg digg it |  Share on LinkedIn LinkedIn 

It is old news that Seagate has built-in encryption directly into the hard drive firmware. In short succession the rest of the industry has followed suit or announced plans for it. This has made digital forensics practitioners screaming in agony ever since, as if it was not hard enough sifting through TBs of data that a typical Enterprise investigation now takes.

Researchers and more importantly intelligence professionals have been playing with cold boot attack mechanism, bringing in a healthy dose of science fiction into what really is a purely digital problem, by spraying DRAM memory chips with a coolant, so that HD encryption keys could be taken out. Here's an interesting report from Bruce Schneier.

More interesting angle to this is to consider the encryption firmware itself. Should we mention that it may be highly proprietary and difficult to reverse? Or not, but how are we to know? Or should we fantasize about some government's hidden backdoors and decryption mechanisms that were forced upon these hardware vendors? Think US Government, if you are on the left, or Chinese or Russian if you are on the right. Last Year Chinese offered to buy Seagate. It caused quite a stir.

We do not have problem with encryption. Protection is a right (should we say your first amendment right?), but we need to be able to certify our encryption solutions and verify their functionality and integrity long after the purchase date. Only in that way, will we be protected and assured of our digital assets. In a more open environment, even forensics solutions will find a way to adopt and use more straight forward ways to acquire the data.

0 Comments Click here to read/write comments

Success with Application Whitelisting: Finding a perfect Security for YOUR problem

Posted by Mario Vuksan on Sun, Jan 18, 2009
  | Share on Twitter Twitter | Buzz This  Google Buzz | Submit to Digg digg it |  Share on LinkedIn LinkedIn 

There are hundreds if not thousands of anti-malware researchers who are extremely hard at work trying to give us the best possible set of signatures, the best possible protection against the bad things that are trying to harm us. They are the so-called blacklisters. We need to thank them. We also need to explain that not all security products fix all security scenarios. New challenges are making the old processes obsolete. Advances in security breed advances in malware creation, hence the flood of incoming samples.

Application Whitelisting in the current form, on the other hand, does some things extremely well. It is the best solution to lock down an end point to an acceptable set of applications and their derivatives. It has always been a challenge to deal with automatic updaters, patches, services packs and the like that continually change your system's basic software image. Application Whitelisting can give the flexibility of forgetting about these challenges and focusing on a positive security model.

But lockdown is not for all end point or all end users. They may need to have a flexibility to experiment, go outside of the box and drill down into more exotic areas of the Internet. Even though, Application Whitelisting could help them with software reputation and software assurance that the system has not been compromised by unknown software applications, it is still very prudent to combine the benefits of a whitelisting solution with that of a typical anti-malware suites.

1 Comments Click here to read/write comments

When SAFE is really safe

Posted by Mario Vuksan on Sun, Jan 11, 2009
  | Share on Twitter Twitter | Buzz This  Google Buzz | Submit to Digg digg it |  Share on LinkedIn LinkedIn 

We have been asked many times about SAFE, our "Software Approval for the Enterprise" mechanism. What is it and why is important? SAFE lays at the heart of Bit9 Parity system and it encapsulates the most complex part of Bit9 Parity end point system. It is Bit9's answer to mistakes made by the first generation of Whitelisting products, extending the concept to what we today refer to as "Application Whitelisting".

The greatest problem to solve with Whitelisting is the complexity that comes with management of millions of files that can be found on an average Enterprise network. Once an administrator os given the power to ban or approve every script, dll and executable, the responsibility is on him or her to do the right thing.

Bit9's SAFE implementation is a smart logic layer that can determine what a software application is, apart from the operating system and not including malicious hooking that could potentially promote an application trust to a malicious software component. As such, SAFE allows Bit9 Parity to view and manage software application as collections of files, giving them a distinct level of trust and manageability.

SAFE is Bit9's mechanism that truly distinguishes it from a standard blacklisting solution because it can be driven by numerous types of trust policies, be it by using digital certificates, trusted repositories or any other automatic approval method already in the Bit9 Parity arsenal.

0 Comments Click here to read/write comments

All Posts

Subscribe by Email

Your email: