Secure apps in a secure ecosystem: the next challenge

This is the fourth in a series of columns exploring the possibility of building a next-generation secure Internet.

Applications are hard to secure. Anyone can create one, anyone can download and install one, and unfortunately today, anyone can modify one. Viruses, worms, Trojans, and bots essentially get away with their maliciousness because they can alter computer software instructions at will, changing either OS instructions or application functionality.

In a secure ecosystem, all software components in the OS or any application would not only be signed and authenticated, but would seek approval before executing or being loaded into memory. There are already several initiatives underway toward that goal. Microsoft, for example, is working on the concept of authenticated applications for the next version of Windows; a much smaller version of it is used for ActiveX controls, where the installer package with all the included executables is signed.

Other vendors already have or are working on similar application authentication scenarios. SignaCert, a company started by CEO Wyatt Starnes, former CEO and president of Tripwire, has an interesting solution. SignaCert has been collecting the digital signatures of tens of millions of executables. These file hashes are placed into a Web-accessible global repository, and administrators can add their own in-house application metadata and file signatures. The admins then define which files are allowed to load into memory on a particular computing device. Each and every executable has to be predefined and validated before it can run.

Wouldn't you love to turn off all of Dell's dozen or so dial-home executables automatically? Wouldn't it be nice that when the newest, polymorphic botware tried to execute, it just couldn't? SignaCert has client-side applications to help you manage your environment and configuration. What is not previously defined is not allowed. SignaCert even has agreements with large non-Windows OS vendors and APIs to allow OS vendors and third parties to leverage the core system and global file signature repository in a way that fits most seamlessly into that environment.

I've been watching SignaCert for nearly a year now, and if the product is half as useful as the company claims, it will still be 10 times better than 99 percent of the other computer security solutions out there right now.

Yes, there are many more challenges in a secure ecosystem beyond secure applications. For one, who is to say that a legitimate application won't be used maliciously? (That's why we need better authenticated users.) Or that its data isn't used maliciously -- macro virus, VBScript worm, and so on? (That's why we need network packet authentication.)

To pull this off, OS vendors are working hard to educate developers and give them better tools so that they can determine what least-privilege permissions are needed to run their application. If you think about it, it's a joke on us that network and application security has been defined any other way.

How will the global application authentication database be updated when any of the following happens? There are a couple of options: an OS puts out a new patch; a software vendor auto-updates its application; a new in-house application gets pushed out; a user builds their own macro. Regardless of the update method, though, a comprehensive, responsive global file signature repository is a step in the right direction.

Some vendors are working on another angle at the same time -- forcing developers to set least-privilege permissions on their applications. Right now, an application is installed by the network administrators, who, in turn, basically have to take their best guess at which users need what rights and permissions. The administrator is lucky if the vendor tells them what permissions are needed, but many developers seem to think giving full admin rights to all end-users is the easy-out solution.

In the near future, developers will hard-code the necessary permissions and privileges into the application. The developer will create role-based groups that have least-privilege permissions pre-assigned; when the network administrator installs the application, they can ask the business owners which network users belong in which role-based groups. When the users are added to the role-based groups, the appropriate permissions necessary to carry out their particular function are automatically assigned. No more guessing.

Application validation is a pretty big requirement of any secure ecosystem. Once you have that solved, a whole lot of the other pieces fall into place more easily.