IT in Transition

Why Software Provenance Matters, Part III: Supply Chain Management

wyatt — Fri, 24 Jul 2009 22:39:34 +0000

Another interesting use case for whitelist-based configuration management is bubbling to the surface (again): IT Device Supply Chain Management

I say *again* because this one came to our attention several years ago, when we built a successful Proof of Concept (PoC), but the IT device manufacturer (who will go unnamed in this blog post) never deployed the PoC as they believed that it was either not that big of an issue/risk/priority or they decided they could handle internally with their own workflow management and in house systems.

Ultimately in that case, the problem was never fixed effectively – and now it has become a high-profile issue in the marketplace.

So here is the problem statement/use case:

I am a manufacturer of a piece of IT hardware that contains software. It may be a computer, a mobile device, a medical device, or even network devices (routers, switches etc.).

I build the hardware, provision the software (most likely these processes are geographically distributed and often outsourced) and then the device is boxed up (with MY brand on the box, shipped thru a few levels of distribution, in and out of customs, and eventually ends up at a customer site.

How do I (as the manufacturer) assure my customer that what was built, shipped and branded by me is what the customer received and installed.

Why does this matter you might ask. Or more specifically, what is the risk?

Well the box may have been opened a couple of times, a VAR or reseller may have added or changed some software (to include their branding or logo for example) – so what I built and shipped IS NOT what actually ended up in the customer site. But I still have warranty responsibility. And I am responsible for my BRAND regardless of how the product made its way to the customer.

Let add another risk dimension:

The device ends up at the customer, it has my brand on it, may have been sold thru channels as “new” but it is actually remanufactured – or worse yet – an actual reproduction that LOOKS LIKE my product. Even though this is not my “fault” – it is still my brand, and my channel (potentially) that is compromised so at least some of the blame/brand damage falls to me.

Ok, you seeing the risk here I hope….but how does known-provenance whitelisting help? Glad you asked.

The PoC that we did a couple of years ago was intended to support this workflow:

- We cryptographically “captured” the software/firmware archive as the device manufacturer built and released new “production code” from their software build systems.

- When the software is “married” to the hardware as a part of the final product/device assembly – we established the relationship of the hardware is connected to the software that is populated on the product/device. This can be as simple as capturing the serial number and the software revisions and cryptographic meta-expressions in a database. In more advanced platforms and use cases, a hardware cryptographic token (such as a trusted platform module) might be used to anchor the authenticity and provenance of the device/platform.

- When the customer installs the device, as a part of the installation/registration process the device reaches out to the database (via encrypted web services) to make sure that the build status aligns with the install status.

This is a classic “close the loop” validation process. Pretty simple to do. And it has many of advantages beyond device/brand integrity. Perhaps the manufacturer has updated the firmware/software and it needs to be reflashed. Also (as the manufacturer) I might be able to benefit from some of the “phone home” data interchange that is enabled by this method. Also gray market or clone products will likely be revealed by this work flow.

These supply chain issues are another important use of known-provenance whitelist software validation.
All of these statements known-provenance, measurement and attestation are really intended to solve the same basic issue. Our compute platforms are “open-loop” by design, as are many of our IT methods and best practices.

We cannot secure what we do not monitor. And we cannot monitor what we do not measure. It is as simple as that.

We MUST fix these issues, and sooner is better than later.

Wyatt.

Unsafe at Any Speed: Distributed Denial of Service Attacks and Whitelisting

wyatt — Wed, 15 Jul 2009 03:16:06 +0000

Some of us gray-haired folks remember Ralph Nader’s provocative book “Unsafe at Any Speed” published in 1965. Basically the book (very controversial when released) took on the automakers for building unsafe cars that threatened the safety of All people that travel the roads. It struck me over the 4th of July holidays that we have a similar situation now on our cyber highways.

Even people that have a life beyond blogging on cyber assurance issues likely would have noticed the front page, and top-of-news coverage about the cyber attacks to the web servers at the Pentagon, Whitehouse, Treasury, State Department (and many other sites). If you didn’t, you can get an overview here: http://www.google.com/hostednews/ap/article/ALeqM5iaaWwzg–SOmIz9Qjdju4UYFB5GgD99B7LNO0

And NBC led their primetime National news last week with this report:

http://www.msnbc.msn.com/id/3032619/#31806714

These attacks are classed as of Distributed Denial of Service (DDoS) of attacks where 100’s or even 1000’s of computers (or more) containing remote-triggered malicious code can be commandeered for nefarious purposes. These so-called Zombie computers (when triggered) will direct their payloads at a set of targeted web servers (or other Internet connected compute processes) in an attempt to overwhelm them with malicious traffic, thus rendering them inaccessible. The amplification effect of these multiple, remote controlled machines is what enables DDos attacks to be as dangerous as they are.

DDoS attacks are far from “new” by the way. One of the first widely publicized one traces back to the year 2000 attack on the Yahoo website. Since then we have learned how to deal better with the SYMPTOMS of an attack (when in progress) by recognizing patterns and routing bogus traffic away from the runtime servers, but we’ve made very little progress on stopping the SOURCE of the problem (Zombies should not exist in the wild).

McAfee estimates that between January and May of this year, 12 million new Zombie computers were armed and aimed. See http://news.digitaltrends.com/news-article/19879/twelve-million-zombie-computers-since-january

Much of the last weeks post DDoS event discussion centered on WHO initiated the attacks and, in my opinion, too little attention has been given as to WHY our systems management and compute infrastructure integrity are so vulnerable that it allows 100’s of thousands, or even potentially million’s of computers, pre-armed, to enter zombie mode when they receive a command from their master — anywhere on the planet. And (you might be wondering) where these Zombie’s are? It is pretty well established that at least some of these Zombies are inside of Corporate and Government offices and datacenters! (Just think if one of your Corporate boxes could be a Zombie-slave to some domestic or foreign master, what other nasty things might it contain?)

How can this be?

One of the many benefits of moving IT systems management to whitelist-based, inclusive software and stack validation methods is that it minimizes (eliminates for all practical purposes) the detection “blind spot” that rogue software can parasitically exist in.

Reference Configuration-based whitelisting establishes software manifest-based monitoring and control on the compute devices which can easily alert the user or IT admin staff if any code is added, deleted, or changed on the target system (from an established, managed build reference). These powerful change detection methods virtually eliminate the exposure to “sleeper” or “Zombie” code existing on systems without user awareness.

With reference configuration-based whitelist image management in place, it is virtually impossible to hide malicious code “in plain sight” as is currently happening. Not only does this help to reduce (and eventually eliminate) much of the DDoS risk (from the standpoint of allowing the presence of Zombie code) – many other benefits accrue from these methods (better compliance, improved security, more stable systems, etc.).

These whitelisting methods also reduce much of the risk of so called “zero day” attacks like the Hannaford Bros. event discussed here. http://zerodaythreat.com/?p=40 and the other malicious and parasitic code risks (like the one that almost wiped AIG’s computer disks in early 2009).

So the Ralph Nader corollary holds in my opinion. The internet is currently UNSAFE AT ANY SPEED, and ultimately it becomes the responsibility of the suppliers/vendors to build better and safer devices to navigate on our cyber highways. It also falls to consumers and users of IT to use “practice safe computing” and use tools and best practices to make sure that they are not contributing to the IT-ecosystem danger factor.

Unfortunately we are barely at the comparative “install and fasten seat belt” stage of relative maturity and yet — at the speed we are traveling coupled with our extreme IT dependence — the severity of the impending (and likely inevitable) crash will likely be catastrophic.

When are we going to learn? Put down the shovel, step away from the hole, and think about it. It is long past time for us to enforce best practices, deploy new tools (think reference-based whitelisting), and find stronger political will to address these fundamental and crucial IT risks.

Wyatt.

Why Software Provenance Matters, Part II

wyatt — Sat, 06 Jun 2009 00:06:07 +0000

I posted a blog a few days ago that covered some of the operational issues of Why Software Provenance Matters, but in talking with partners recently, and listening to other use cases, I thought that I’d add some detail to address these needs and perspectives.

In statistical error analysis we talk about Type One (T1) and Type Two (T2) errors (also known and False Positive and False Negative respectively).

T1 or False Positive is classifying something as true when it isn’t.
T2 or False Negative is classifying something as false with it isn’t.

See the table below:

So in any method where there is a “test” of a state against some actual or known condition, there is a chance of comparison error. The result of the test generally triggers some policy action or alert.

This of course translates to: Accurate measurement is a critical requirement for effective policy implementation.

Let me use a simple example that relates to identity. The test for this example is:

Is this an authorized user?

If it is a legitimate authorized user (Test) I want to grant entry or access (Policy) = True Positive

If it is not a legitimate authorized user (Test) I want to deny entry or access (Policy) = True Negative

If an unauthorized user IS ALLOWED inappropriate access = False Positive or T1

If an authorized user IS NOT ALLOWED appropriate access = False Negative or T2

Both T1 and T2 errors are problematic of course, but the challenge is really the same. How to I precisely identify the user so as to reduce the risk of error?

Precise identification is the answer of course.

Now let me apply this to whitelisting and blacklisting:

Here is the Whitelist Example:

Here is the Blacklist Example:

So again, our “test” must be accurate in order to affect the appropriate policy. Likely the policy in these cases is to “allow” or “deny” the code from loading and/or running.

So the accuracy and provenance (certainty of code hash signature and/or attributes) is THE MAJOR component used to test the condition for both whitelisting and blacklisting methods.

Where whitelisting can compliment blacklisting is generally to reduce the false positives by improving the certainty of the reference methods used in the detection. This can improve customer experience by not inadvertently blocking good code from loading/running.

Also, Symantec and others have effectively used a form of Dynamic Whitelisting (see my blog on whitelisting methods) to create “do not scan again” lists in order to optimize the AV scanning to code that actually needs inspection. This also enhances user experience by speeding up the AV process..

It is for all of these reasons that we think that there are really only BLACK and WHITE lists – and why we believe known provenance is one of the surest ways to precisely establish the reputation reference used for both whitelist and blacklist methods.

Wyatt.

Gartner, Whitelists and Virtualization Methods

wyatt — Tue, 02 Jun 2009 16:11:01 +0000

I have mentioned this post before, but to keep you current see:

http://blogs.gartner.com/neil_macdonald/2009/04/21/its-virtualization-security-week/

This post seems like a great “connect the no-brainer” dots together opportunity. Here’s a recap of Neil MacDonald’s Security No-Brainers (SNB) so far:

SNB #1: We Need a Global Industry-wide Application Whitelist
SNB #2: Use whitelisting in the hypervisor/VMM (especially in the “parent” or Dom0 partition) to prevent the execution of unauthorized code in this security-sensitive layer
SNB #3: Root of Trust Measurements for Hypervisors

(Relating to SNB #1 – we did announce our working relationship with Microsoft in the area of software whitelisting at the RSA show. A key element of that announcement is the standards for whitelist exchange using a Standard Schema Definition – or Data Exchange Format. So a sub-text SNB is standards of method, protocol and exchange).

So against the backdrop of the RSA events, this blog heading, and staying within the limits of certain NDA’s that we (SignaCert) are under – let posit a connect-the-dots hypothesis:

The highest cyber security goal in both the P (physical) and V (virtual) worlds is ultimately the same; namely, to instantiate a computing environment—a software stack on a hardware platform—as secure, reliable, safe and trusted. This trusted stack (hardware plus software) then can become one of the cogs of a business process (a “Service,” in ITIL parlance).

It is important to note here that while the goals in the P and V world may be largely the same, the complexities in the V world are likely to make these goals even harder to achieve largely because the V world velocity of change is likely to be higher, and we may not even know (or care) where the image physically resides anymore. Even more reason to think about all of this very carefully.

All of the moving parts of any completed IT service (AKA the business process) should ideally be trusted from end-to-end, right? Not just to a point of instantiation (when it is deployed and turned on), but thru to the point of de-instantiation (un-deployed and turned off). This is really and issue of maintaining lifecycle integrity. (There are some interesting compliance issues here to, but I’ll leave that story for another blog post).

We now know that to achieve the goal of end-to-end trust, the following processes are necessary (at a minimum):

1. A root of trust for measurement (RTM) should be established in the hardware in some fashion, say with a Trusted Platform Key, and establish RTM for HV/VMM (SNB #3).

2. A Trusted Platform Module (TPM) key, or other cryptographic identifier, should be passed and used to request and validate (attest) the HV/VMM in the Domain Zero (Dom0)/parent layer (SNB #2). This is for the purpose of determining whether the Dom0 can be trusted.

3. Then, with a “known/trusted” parent environment in place (and hopefully a way to keep it that way), we pass our “trust baton” up the stack.

4. Finally, we need the HV/VMM to instantiate the rest of the software stack with positive attestation methods provided by the Global Industry-wide Application (software) Database (supported with known provenance ISV-sourced software “measurements,” see SNB #1).

And then it would be useful if we had a way to rate the trustworthiness of the entire system and score the results, in normalized terms. Our goal is to attest/certify what we’ve instantiated with a proactive statement of platform/image trust, make certain it’s stable and durable, and to enable a method to continually “prove it”.

We might also want a way for that service process stack to be able to offer its “platform trust credentials” to other business/service processes, both in and out of the physical domain in which it resides. This credentialing could be used to exchange relative platform trust with partner service process, for example.
(Disclaimer: SignaCert has two U.S. patents issued on the notion of Stack/Platform Trust derived from element trust scores.)

A crucial element to make this all a reality is one of the first rules we learned in kindergarten: how to play well with others.

The platform players must work with closely with the virtualization players, who must work closely with the whitelist eco-system folks, who need ISV support to play their role, etc. And all must collaborate regularly with the systems management vendors and solution providers.

Such collaboration is not easy, but it’s not impossible. If deep trust services become a required credential for connecting with partners, demonstrating regulatory compliance and meeting government IA standards…it will suddenly be in everyone’s strong self interest to get onboard the instantiation train, and pass the trust baton.

By the way, in our experience number four above is one of the trickiest parts. How do we manage multiple complex heterogeneous V and P stacks? How do we create and express broader trust credentials across a matrix of dynamic business/service processes?

And another important design tenet relates to persistent and non-persistent connect scenarios. We need to carefully avoid the circular loop of “we need a connection to attest trust credentials – but can’t get a connection because we don’t have trust affirmations”. Cooperation with eco-system partners is required to pull this one off too.

Net-net: We need to think and act differently. The “old” P security methods have largely run out of gas already, so let’s use the V (virtualization) transition to bake in trust and security, as a first principle.

Wyatt.

Why Software Provenance Matters

wyatt — Fri, 29 May 2009 19:11:19 +0000

We have announced and talked about the concept of “known provenance” as a crucial software-assurance and IT-lifecycle-management metric for some time, but it struck me today that I haven’t really underscored some of the reasons and use cases that led us to this conclusion.

Firstly, there are multiple dimensions to software integrity assurance that leverage cryptographic validation (hashing) methods including:

1. Do I know that the software elements that I am loading and running on my platform ARE what they say they are?)

2. Security quality assurance – can I couple (1) with a quantitative expression of code vulnerability statements? (Is it the code it purports to be and is it secure?) For example, our recent work with Veracode.

3. And what proof do I have that this was the code that I am using was actually built by the named vendor? (The filesystem may think that it is XYZ ISV, but it is the software that is vouching for itself, perhaps with the aid of a installer-embedded certificate. Inconclusive at best, especially after installation)

So we have taken the position early on that we need PROOF that the code was actually built by the named supplier as a crucial attribute of software and device validation or attestation. We call this (AKA Source Origin or Known Provenance.

The road to obtaining provenance and delivering it across various use cases is clearly the harder road when collecting software measurements. It requires “quality over quantity” dedication…..means that ISV’s and other software producers and integrators need to be involved. After all, true known provenance can only be delivered with a certifiable “chain of custody” all the way from the original software vendor and then managed all the way to the end system.

Open standards in method and schema are key, and the industry has done a decent job at collaborating on these—with additional iterations now pending.

But back to the title of this blog: So What?

Here is quick snapshot of use cases where provenance is increasingly critical:

1. Software Forensics – The objective here is to identify the problem by definitively separately the “good” from the “bad” (and the “unknown”). This is simply common sense, as our objective with forensics is to spend our time as efficiently as possible while looking for the “needle in the haystack”. Efficiency demands that we make the haystack smaller ASAP in our quest for the needle.

2. Supply Chain Assurance – This one deals with both the supply and purchaser concern of “Is this the device that I think it is? (i.e., was it in fact built by the named supplier, and is the h/w and s/w integrity demonstrable?).

3. Service Level Assurance (SLA) Management – This is the classic issue of “Ok, something doesn’t work, and whose fault is it?” (I’m sure you’ve never seen finger pointing on this one.)

4. Compliance – Needless to say, when provenance is clear and trusted, we can improve statements of compliance as well. (I know that I have the right software build in place—i.e., the right software manifest and integrity; and I prove the software and work product in the build is from the named author?)

So the power to prove, enabled by software and hardware provenance, is not a luxury item. In this age of globalization and outsourcing of design, manufacture, distribution, and systems management, we must establish and maintain “trust chains” to all the devices that we build and supply.

For suppliers of complex hardware and software, provenance is a cradle-to-grave issue. How can we truly and cost-effectively own and support our “Brand” without it?

So, as we enter the next chapter of ubiquitous computing (aka Web 2.0), our ability to design trust into our devices early in their lifecycle and systematically validate and pass that trust through the lifecycle of our “brand” in a non-repudiated manner will become a key market differentiator.

One might even go as far as to say:

Those who do not embrace this view may not survive the next wave of consolidation (which by the way is already well underway).

Wyatt.

Enter Configuration-Based Whitelisting

wyatt — Wed, 27 May 2009 17:28:13 +0000

This post is going to tie a couple of prior discussions together (I hope).

In August 2008, I posted a blog entitled:

Whitelist Emerges from the Shadows: Re-enforcing the Three-Tier Security and Systems Management Model

And in my most recent post entitled:

The “Whitelist Space” seems to be heating up a bit….

I took a stab as creating a taxonomy for whitelisting methods, as this space is really just taking shape – and clearly not all “code-whitelisting methods” are created equally.

So the “dot-connection” is this:

Effective whitelisting is really about total configuration enforcement, not just blocking individual elements. And as I stressed in the first blog, it is really a THREE-TIER architectural challenge, not a traditional two-tier problem like blacklist solutions.

And interestingly, the “heavy lifting” to make all this work is not at the ends of the architecture (Tier 1 or Tier 3) but in the middle – Tier 2.

(Refresher: IMHV, Tier 1 is the whitelist cloud services, Tier 2 is the domain whitelist caching and the reference-configuration management), and Tier 3 is the endpoint measurement and policy enforcement agent/client/OS/Hypervisor support).

We think that the real power, manageability and scalability of the method comes into view when we move from just “Good File” to “Configuration-based Whitelisting”, where we pass more whitelist “intelligence” to the method (things like parent-child relationships of the elements and provenance of the elements being enforced).

Clearly, the cloud and local whitelist agents are needed to collect and pass that information – but the key is supplementing that information with additional domain-specific configuration and element data, and organizing the entire lot into configuration-setting and software stacks that should be present on the platform under management.

And all of this must be platform/device decoupled, must be data-type independent (files, registry, config settings database fields, etc), must be mappable in the reference configurations and must be vendor/platform/software-type neutral.

Whew. Sorry, that was a mouthful.

Real and immediate use cases for this include requirements like Federal Desktop Core Configuration (FDCC) and other compliance issues.

These are exciting times for the space, IMHV. Stay tuned for more.

Wyatt.

The “Whitelist Space” seems to be heating up a bit….

wyatt — Thu, 21 May 2009 16:48:25 +0000

These pages have been talking about the bigger issues of “IT in Transition” for a long while. The shift to “defense in depth”, with the AV players adding whitelist methods, has been a persistent theme on these and other blog pages.

Well in the last few weeks, we’ve seen a couple major moves: first, Microsoft endorsing the concept and working with us to provide their signatures to the market, and now a significant move with the imminent acquisition of Solidcore by McAfee (MFE).

http://newsroom.mcafee.com/article_display.cfm?article_id=3520

It is interesting that MFE will assimilate Solidcore in the Governance, Risk and Compliance Business Unit. It is what I would consider a “bite-size” move to application enforcement based on whitelisting by MFE. Recently, Solidcore has done a good job delivering value to fairly static endpoint devices – largely focused on the embedded device, ATM, and POS market spaces.

There is also mention in the release of SCADA devices commonly used to control physical infrastructure devices such as electrical and water control/management systems. This could bolster work that MFE may be targeting in Government, where they have done well with the ePO platform.
Solidcore describes their method as “dynamic whitelisting” – also pretty good marketing IMHO. So now we have another bullet on the whitelist method slide. So far we have:

Application Whitelisting or Allow Listing (single executable locking/blocking/allowance)
Dynamic Whitelisting (aka Self-Referencing – see below)
Whitelist Caching (this is what Symantec is doing in their latest Norton offerings so that they don’t have to rescan “known code” again with their malicious detection tools)
Comprehensive Whitelisting (this is a superset of Application Whitelisting where entire applications or software stacks may be “measured”, and based on device health” determined by these broader measurements – certain policies may be invoked (like allow/deny platform access to other resources)

(These are the just the “code signing” methods. There are other whitelisting and reputation services being employed for email and URL filtering that is another category entirely.)

Dynamic whitelisting is basically a synonym for “self-learned or self-referencing” configuration image and integrity models where the “whitelist” is derived from the device(s) themselves. Tripwire has been doing this pretty well for a few years.

(Full disclosure again – I co-founded Tripwire, and Solidcore competes directly with Tripwire in the desktop and server integrity market space)

While Self-Referencing whitelisting can be useful, it has a number of limitations and drawbacks. Scalability, manageability, and noise management are just a few of them. By “noise management”, I mean too many false positives, such as when merely upgrading a version of software generates thousands of “file-changed” hits. Also, what if your reference master was corrupted? Or … ?

So, on the one hand, we are happy to see a major AV player dip a toe into the whitelist waters as another validation for the space. We’ll be even more excited when customers and vendors really stretch their legs – and push the envelope with deep and comprehensive whitelisting and reference configuration management methods.

Let’s move beyond executable-lock-and-block methods, and configuration monitoring based on self-learned methods – and get to full and scalable compute-platform attestation, with both root of trust (Trust PROOF built INTO the platform) and known-provenance, list-based whitelisting (PROOF that the code was built by the named authors).

Connecting these dots is necessary to have true platform-intrinsic, end-to-end trust – not just to validate the “easy devices” like POS – but for the more complex servers and workstations use cases.
Yes, it is hard. But the pain will be worth the gain.

It’s time to build more trust into our systems.
Wyatt.

Speaking of Standards…..

wyatt — Thu, 30 Apr 2009 23:55:31 +0000

I continue to follow with interest the work that Neil MacDonald from Gartner is doing as he examines trends in physical and virtual security methods and trends.

Here is his latest blog reporting on some observations gleamed from RSA around virtualization and security. Good stuff Neil.

http://blogs.gartner.com/neil_macdonald/2009/04/23/rsa-and-virtualization-security/

I lock onto these things partially just because I am a geek at heart, and because I think it is fascinating to watch, ponder, and hopefully contribute something of value to effort along the way. And also believe that the Physical to Virtual IT transition point presents an excellent opportunity to “think differently”. I posted my thoughts on that in Neil’s latest blog.

And also because it is just freakin’ important to get these IT systems working better. You see I have this silly (and perhaps old-fashioned) notion of leaving the world better place than I found for my part in it.
And the only way I know how to do that is to work with a world-class team (like the one we have here at SignaCert) and to challenge the status quo day-in and day-out. And the only technology and discipline area that I know well is Information Technology security and systems management.
So here we are……

We’ll keep hammering on this with our friends, colleagues and trusted partners. With enough effort and will, even the biggest rocks can be moved.

Wyatt.

A Standards-based approach

wyatt — Fri, 24 Apr 2009 17:06:48 +0000

A few months ago a bunch of my friends and colleagues decided to do something crazy:

To collaborate and write a book pooling collective knowledge, experience and vision around the state of the security and information assurance business.

My good friend Carlos Solari took the lead (he really did the heavy lifting regardless of the exceptionally generous, “About the Contributors” intro).

After a ton of work on long plane flights, and many lost weekends, the book is complete and was published at the RSA 2009 conference this week.

We’d enjoy your input and comments.

Here is a PDF of the intro:

http://www.signacert.com/resources/downloads/Security_Book_Intro.pdf

And here is a link to Amazon.com where you can buy a hardback copy:

http://www.amazon.com/Security-Web-2-0-World-Standards-Based/dp/0470745754/ref=sr_1_1?ie=UTF8&s=books&qid=1240590998&sr=1-1

With special thanks to Carlos and the entire team for their dedication to this book project, and for the passion they show every day to improve the discipline of our field.

SignaCert Announcement relating to Microsoft at RSA

wyatt — Tue, 21 Apr 2009 21:19:27 +0000

Today at RSA we announced a significant “arrangement” with Microsoft. We also participated in the Microsoft Theater (link to presentation coming soon).

Obviously this is a big deal for us, but that is not why I am writing this blog entry.

This blog is titled “IT in Transition” and if this isn’t transitional, I don’t know what is. From the release:

“This is a very important step in enabling much better trust, security and management solutions for Microsoft customers. It underscores the ongoing commitment of Microsoft to provide expanded object reputation services within its products and services as new security standards and methods evolve,” said Greg Kohanim, Product Unit Manager of Microsoft. “As an ISV, Microsoft is proud to extend this common repository with its own information to enable the industry to increase security across the board.”

Thank you Mr. Kohanim.

Also from the release:

“Software whitelisting is becoming strategic for protecting compute devices. Who builds and maintains the list is one of the more significant issues,” said Neil MacDonald, VP and Gartner Fellow. “Since ISVs are the source of much of the software (including the OS foundation), it makes sense to have the worldwide ISV community contribute, in a standard way, to a whitelist that has the broadest adoption and impact versus the complexity involved in building or contributing to proprietary databases.”

And thank you for your contributions Mr. MacDonald. The insight around important IT trends, and identified “no brainers” in your blog posts are spot-on IMHO.

Here are the main elements of the arrangement without the required p/r marketing spin

SignaCert to deliver rich content services with direct-from-Microsoft software measurements
Microsoft to deliver products with known-provenance, cross-platform third-party content aggregated by SignaCert
Data Exchange Format to be made available for ISV/OEM Partner use

Thank you Microsoft.

We are very proud to have been selected as a key partner for Microsoft, and it is a tribute to the work of countless people who have supported and encouraged us to continue our work in these important areas for the last decade or so. And thanks to all of our investors for the support of the vision and product creation.

Now the work really begins.

Stay tuned.
Wyatt.