A guard at a BP facility in Alaska is said to have shot an endangered Polar Bear with an explosive shotgun charge. The bear died from internal injuries a few days later.

Late in the evening of Aug. 3, a security guard, employed by Purcell Security, saw what turned out to be a female polar bear walking down the Endicott causeway and headed for an employee housing area. The guard flashed his vehicle lights at the bear, honked his horn and sounded his siren but the bear would not leave the area and instead approached the vehicle and began to act aggressively.

The guard pulled out his 12-guage shotgun and fired what he thought was a bean bag round at the bear. The less-lethal ammunition is designed to hit the bear in the hind quarters and drive it away.

The bear did run off at that point and BP reported the incident to the Fish and Wildlife Service, as required.

But a few days later, the bear returned, swimming off to the west and ending up on a shallow island area near the four-mile long causeway and 30-acre gravel drilling pad.

BP workers could see the bear through binoculars and continued to monitor it. But sometime between the night of Sunday, Aug. 14 and Monday morning, Aug. 15, they realized the bear was dead.

Such a lethal and high-profile mistake has led BP to say it will now consider ways to avoid making another one.

[BP Alaska spokesman Steve] Rinehart said all ammunition will now be clearly marked by its type, with specific packaging colors and labels.

A “back-up bear hazer” also will be required to be on hand and verify that the correct ammunition for the level of hazing is about to be used, he said.

“We want to make completely sure that whatever guard is involved in a hazing incident knows exactly what type of hazing round is being used if it comes to that,” Rinehart said.

The solutions indicate confusion over ammunition type (lethal/nonlethal) and doubt from a single-source. In other words, they did not anticipate any harm from grabbing a lethal charge by accident; and they did not have any method setup for independent verification after a lethal accident. Both seem highly irresponsible management of risk when handling lethal force.

Here’s a good question for the investigators. At what point after shooting an endangered animal should a shooter inventory their ammunition and confirm that they did not harm the animal? Should they wait until it is dead? Was the facility manager looking through the binoculars and saying “Yup, she’s dead. I guess that means it was one of the lethal rounds…”?

It’s unfortunate that BP management demonstrates they will allow a lethal accident to happen before they take even simple measures to reduce the risk of that accident, let alone maintain controls (e.g. responsibility) for high-risk decisions.

You might think BP, a company full of environmental and mechanical engineers, could design and build a camp-site that is passively resistant to bears and therefore not threatened by them so easily. Perhaps instead they did a quick calculation and found it far less expensive to kill endangered animals in their way and just claim a lack of awareness?

The National University of Singapore has announced the winner of a 24-hour coding competition. Here’s the goal:

…a 24-hour programming competition, encourages students and faculty to develop customized applications that advance the search and discovery process of scientific information.

So you might be thinking there would be some cool new scientific tools being developed. Maybe students have added perspective and a new way of thinking about problems, based on data discovery? No, instead the winner is a Google modification — a search engine that ranks scientific papers based on reputation.

First place: Zhao Shanheng and Zhong Zhi, of NUS, developed the iRank Apps, an application which ranks institutes by the number of papers returned in the top search results. This tool can help students decide where to apply for their PhD or pursue postdoctoral research in their chosen field.

Google’s reputation-based system has advantages, but it also has risks. It requires you to trust external sources of verification — the peer-review system depends on the quality of the peers. That seems highly unscientific. It’s a second-person or even third-person view of data.

So the first place award goes to an app that tells you what the search engines tell you about what the peers tell you about papers from institutes. It is a popularity contest app that is at least three steps removed from an actual review of source material.

The huge irony, of course, is that the contest appears to have had a controlled/trusted system to determine the winner. How quaint. Perhaps they should have instead thrown the apps into public search engines and let the one that hits the top search results win. Otherwise, I would say their decision to review and vote for iRank App in a closed system contradicts the mission of the iRank App…

I have been asked a few times about details of the Federal track at VMworld this year in Las Vegas so I thought I would just post the information here for convenience.

Note that all the Federal sessions are security and/or compliance related:

Session ID and Title

• CAP1992 Building Resilient, High Performance, Distributed Applications that are Data-Intensive
• SEC1544 Compliance and Trust in the Cloud
• SEC1747 Desktop Security Zones with VMware View and vShield App: A Reference Architecture Review
• SEC1980 Department of Defense Reference Architecture using vShield
• SEC2114 Customer Panel: Ensuring Compliance in a Virtual World
• SEC2162 Achieving a Trusted Cloud
• SEC2192 Case Study: Building a Virtual Data Center at the Department of Homeland Security to Meet FISMA Moderate to High Data Security Requirements
• SEC2942 Building Trusted Clouds – Proof Points not Promises
• EUC1988 Case Study: Using VMware View to Strengthen Disaster Response Systems for Federal Agencies
• SEC2284 Securing Government Virtual Environments: Part II
• EUC2048 Panel Discussion: Modernizing the Desktop to Provide Better Business Continuity while Reducing Operational Costs for State and Local Government

Aside from helping prepare some of the compliance sessions I am presenting on the art of applying penetration testing skills to the cloud. And I’ve been asked to sit on a PCI expert panel. Hope to see you there:

• SEC1236 Penetration Testing the Cloud
• SEC2484 PCI-DSS Compliant Cloud—Design and Architecture Best Practices

Come see how far things have progressed since the early days of VMware

Today I received an email “newsletter” from the CEO of Townsend that announced a new product for database encryption:

Today we are excited to announce the availability of our new Alliance Key Manager for SQL Server (AKMSS). AKMSS is a Hardware Security Module (HSM) for encryption key management that protects access your encryption keys.

A quick look at the specifications, however, and an odd gap appeared between the marketing language and the actual product.

First, they seem to have stretched the phrase “Hardware Security Module” (HSM) to mean software running on a standard Linux x86 system. It used to be that an HSM had a specific meaning for cryptography. Wikipedia, a general reference, gives us this:

[HSM] are physical devices that traditionally come in the form of a plug-in card or an external TCP/IP security device that can be attached directly to the server or general purpose computer. […] The tamper evidence, resistance, and response — tamper protection — are the key and major differences HSMs have from usual server computers acting as cryptographic accelerators.

The Townsend product does not appear to meet the basic definition of an HSM.

Second, Townsend themselves say on their product specification page they have achieved validation only to NIST FIPS 140-2 Level 1. So they only use software-based security to protect the keys. FIPS 140-2 Level 1 by definition implies a software-based crypto-module since crypto-hardware certification begins at Level 2. A quick check of the NIST FIPS Validated Modules list page reveals item #1449 has the following text:

When operated with the Red Hat Enterprise Linux 5 OpenSSL Cryptographic Module validated to FIPS 140-2 under Cert. #1320 operating in FIPS mode (approved algorithms retested on listed operating environment)

Townsend’s “HSM” thus derives its FIPS security from an open-source OpenSSL software module, which previously achieved FIPS certification due to open-source community efforts — an OpenSSL crypto-module is their source of FIPS certification. That’s a good start but use of this crypto-module when not in FIPS mode would negate their FIPS-certified security.

Note: search for the string 1320 on the NIST list page will show many companies derive their FIPS certification from OpenSSL, including IBM (see #1433).

Townsend Security makes a good case for the need for an HSM in the market, and that does not yet appear to be what they are offering to sell from their own product specification. It reads like a software-based key-management system, offering OpenSSL for FIPS security, running on a Linux system. That does not rise to the same level of security that even a TPM would provide, let alone a FIPS 140-2 Level 2 or above certified cryptographic hardware security module.

They suggest this product is a solution for compliance, but buyer beware. I find their marketing material to mislead by equating low and high security levels:

Certified Solutions Ensures the Highest Level of Compliance with Regulations

Alliance Key Manager for SQL Server 2008 is certified to the FIPS 140-2 Level 1 specification.

Level 1 is the highest level? Um, no. Level 1 provides the lowest level of compliance with regulations. And they say it ensures…let’s not even go there.