Tuesday, December 14, 2010

DARPA makes Lockheed Martin sit for three months on one of 2010's most important military technology stories


Posted by John Keller

Here's the good news: military electro-optical systems designers at the Lockheed Martin Mission Systems & Sensors (MS2) segment in Akron, Ohio, announced today that they are building several One Shot laser-based military sniper fire-control systems that improve accuracy and reduce the possibility of detection under terms of a $6.9 million contract from One Shot program sponsor, the U.S. Defense Advanced Research Projects Agency (DARPA) in Arlington, Va.

Here's the bad news: Lockheed Martin won that contract at the end of September, and had to sit on an official announcement for nearly three months because the public affairs folks at DARPA wouldn't give permission to announce the follow-on contract for the One Shot fiber optic laser-based system that is designed to help military snipers compensate for cross winds to hit their targets with their first shots.

The One Shot program, and Lockheed Martin's latest contract, haven't been a secret over the past quarter, however, while DARPA dithered on authorizing an announcement. We here at Military & Aerospace Electronics had been covering the story from the beginning.

Our original story, Lockheed Martin to continue One Shot program electro-optics work to help snipers hit targets in crosswinds, which ran on 1 Oct., also received considerable attention in other media -- most notably Fox News and Popular Science.

Fox News picked up the story a couple of days after we broke it, and posted a well-read story online entitled Self-Aiming Sniper Rifles Coming Next Year. Popular Science, meanwhile, posted a story entitled Darpa's Self-Aiming "One Shot" Sniper Rifle Scheduled for Next Year.

Fox News and Popular Science very graciously posted links back to the original story in Military & Aerospace Electronics, which as of today has received 10,591 page views and has been our most-read online story of 2010 -- by far.

It's too bad the public affairs folks at DARPA didn't place the same level of importance on this military technology story that the reading public of Military & Aerospace Electronics and other major online media did ... and kudos to the public relations shop at Lockheed Martin MS2 for showing such patience.

Monday, December 6, 2010

Security holes are everywhere even in secure virtualization systems, says Green Hills Software CEO


Posted by John McHale
If the Wikileaks scandal shows anything it proves that no system is secure as people may think it is -- especially software virtualization systems, said Dan O'Dowd, chief executive officer of Green Hills Software during the company’s Software Elite Users Technology Summit. "Virtualization adds nothing to security," he added.

O'Dowd pointed out that virtualization systems have less code, "but that just means they are less bad, not more secure. Running bug-ridden operating systems in virtual machines does not solve the security issue unless the virtualization system itself is secure."

He then made a point that I think resonates well beyond virtualization systems. "The security claims of popular virtualization systems are just marketing fluff to exploit the desperate need of all computer users for security," O'Dowd says. These systems have only been evaluated to the National Security Agency's (NSA's) Common Criteria EAL4+.

According to the Common criteria EAL4+ "makes them appropriate for protecting against 'inadvertent or casual attempts to breach system security,'" O’Dowd said. It's as if they have five doors to their house but only locked four, he added.

O'Dowd was working up to making the case for his company's EAL6+ secure virtualization software, but, I think he's also right on that this is not just a virtualization security phenomenon.

People are lazy when it comes to securing their computers. They all want their systems to be secure, but typically buy into the marketing fluff of certain technology because they like the convenience it provides. However, in the long run they are setting themselves up for security breaches.

It reminded me of something an export compliance officer at a major aerospace company once told me that he tells his employees who travel overseas. He says they need to assume that their emails are being read and their phone conversations are being listened to. It doesn't make you paranoid, it makes you vigilant, he said.

Speaking of vigilance, let's get back to the secure virtualization discussion.

During their work in this area O'Dowd's engineers found security vulnerabilities in standard device drivers in virtual machines. He said they attempted to use I/O memory management units (MMUs) to improve the security of virtual machines, but found that "it doesn't work.

"We weren't looking for vulnerabilities, we were just trying to make the device drivers work," O'Dowd said. "Modern I/O devices often contain huge software control programs consisting of hundreds of thousands lines of code and they have just as many security vulnerabilities as traditional operating systems."

He made the case that if users want to be vigilant with their virtualization systems they need to use an EAL6+ secure system like that offered by Green Hills. Makes sense but with that vigilance also comes cost.

Systems like Green Hills do not come cheap, so it becomes a matter of managing risk. Military and avionics systems cannot take that chance, but companies in less mission/life critical applications may be able to get away with it.

What's more expensive paying for the security ahead of time or not paying and hoping nothing happens? I guess it depends on whether or not you think you, your company, or your technology is actually a target.

Security holes are everywhere even in secure virtualization systems, says Green Hills Software CEO


Posted by John McHale
If the Wikileaks scandal shows anything it proves that no system is secure as people may think it is -- especially software virtualization systems, said Dan O'Dowd, chief executive officer of Green Hills Software during the company’s Software Elite Users Technology Summit. "Virtualization adds nothing to security," he added.

O'Dowd pointed out that virtualization systems have less code, "but that just means they are less bad, not more secure. Running bug-ridden operating systems in virtual machines does not solve the security issue unless the virtualization system itself is secure."

He then made a point that I think resonates well beyond virtualization systems. "The security claims of popular virtualization systems are just marketing fluff to exploit the desperate need of all computer users for security," O'Dowd says. These systems have only been evaluated to the National Security Agency's (NSA's) Common Criteria EAL4+.

According to the Common criteria EAL4+ "makes them appropriate for protecting against 'inadvertent or casual attempts to breach system security,'" O’Dowd said. It's as if they have five doors to their house but only locked four, he added.

O'Dowd was working up to making the case for his company's EAL6+ secure virtualization software, but, I think he's also right on that this is not just a virtualization security phenomenon.

People are lazy when it comes to securing their computers. They all want their systems to be secure, but typically buy into the marketing fluff of certain technology because they like the convenience it provides. However, in the long run they are setting themselves up for security breaches.

It reminded me of something an export compliance officer at a major aerospace company once told me that he tells his employees who travel overseas. He says they need to assume that their emails are being read and their phone conversations are being listened to. It doesn't make you paranoid, it makes you vigilant, he said.

Speaking of vigilance, let's get back to the secure virtualization discussion.

During their work in this area O'Dowd's engineers found security vulnerabilities in standard device drivers in virtual machines. He said they attempted to use I/O memory management units (MMUs) to improve the security of virtual machines, but found that "it doesn't work.

"We weren't looking for vulnerabilities, we were just trying to make the device drivers work," O'Dowd said. "Modern I/O devices often contain huge software control programs consisting of hundreds of thousands lines of code and they have just as many security vulnerabilities as traditional operating systems."

He made the case that if users want to be vigilant with their virtualization systems they need to use an EAL6+ secure system like that offered by Green Hills. Makes sense but with that vigilance also comes cost.

Systems like Green Hills do not come cheap, so it becomes a matter of managing risk. Military and avionics systems cannot take that chance, but companies in less mission/life critical applications may be able to get away with it.

What's more expensive paying for the security ahead of time or not paying and hoping nothing happens? I guess it depends on whether or not you think you, your company, or your technology is actually a target.

Wednesday, December 1, 2010

Revealing the flight plan of Santa; what else are we giving potential terrorists?


Posted by John Keller

On the heels of devastating WikiLeaks revelations of U.S. State Department secrets, causing irreparable damage to U.S. diplomacy around the world, comes news that the U.S. government itself is about to publicize detailed movements and locations of one of the most important Christmas icons of Western Civilization -- Santa Claus.

The North American Aerospace Defense Command (NORAD) at Peterson Air Force Base, Colo., announced plans today not only to track the movements of Santa Claus during his Christmas Eve rounds, but also to report his every location on a public Website, www.noradsanta.org.

We live in dangerous times; no one at NORAD needs to be told that. This is an organization that regularly scrambles jet fighters to intercept any aircraft in violation of U.S. controlled airspace, yet these people are about to put a holiday symbol of the magnitude of Santa Claus in jeopardy by revealing his whereabouts to the potential terrorists and other adversaries.

Think about what could result from this ill-advised scheme. The hooves of those eight tiny reindeer are more than enough to set off a well-placed improvised explosive device (IED). That sleigh laden with gifts would be a fat target for any nefarious character with a shoulder-fired missile. I won't even mention the damage that a suicide bomber could wreak.

To be sure, we're not just talking about the possibility of some disappointed good little girls and boys here; this could shake Western culture to its core. Think of the disruptions to national economies. It could spell an end to Christmas as we know it.

NORAD simply must rethink such a cavalier plan that puts so much in danger. If nothing changes, we risk a Christmas Eve disaster more profound than any other in memory of this or past generations, and I'm appalled.

Thursday, November 11, 2010

Thank you to all that serve


Posted by John McHale
A few years ago during a internal company presentation our team at Military & Aerospace Electronics described what we do as "covering the technology that helps protect those who protect us." By "those" we mean the men and women who make up the Army, Air Force, Navy, and Marine Corps. Thanks to all of you for your service.

The sacrifices our military personnel make today in Iraq and Afghanistan and those made by veterans of past wars are very humbling. It has been an honor to cover you and get to know many of you during the 14 years I've covered the defense industry.

On behalf of my colleagues at Military & Aerospace Electronics I wish you a Happy Veterans Day. Please know you are appreciated.

Tuesday, November 2, 2010

FACE consortium tries to succeed where others have failed in crafting open-systems avionics computers


Posted by John Keller

Embedded computing providers, in unguarded moments, often blurt out their frustration with major avionics computer designers who make just enough tweaks to commercial off-the-shelf (COTS) hardware and software to create what are essentially proprietary solutions with what ought to be open-systems avionics components.

We've all seen these before. Remember the Common Integrated Processor (CIP) design for the F-22 Raptor advanced tactical fighter? It was developed two decades ago by what was then Hughes Aircraft (bought later by Raytheon), and was based on the Intel 80960 processor. Hughes promoted the CIP as an open-systems computer, but anyone who took a look at it quickly realized that Hughes held the keys to the architecture, and no third-party suppliers could participate in the CIP without the approval and support of Hughes.

Today an industry group called the Future Airborne Capability Environment (FACE) consortium is trying to change all that. This group, launched last July, is attempting to formulate industry standards for a common operating environment in avionics computer systems.

To date the FACE consortium has backing from the U.S. Navy Air Combat Electronics Program Office, the U.S. Army Aviation and Missile Research and Engineering Center, and 19 defense industry avionics suppliers -- including Lockheed Martin, Boeing, Rockwell Collins, Raytheon, Northrop Grumman, General Dynamics, and Harris Corp.

The group was formed to address the lack of common standards among aircraft systems, which has hindered interoperability while increasing the cost and time necessary to develop, integrate, and maintain modern avionics computers, consortium officials say.

Other FACE consortium members include ATK, CMC Electronics, Elbit Systems of America, Green Hills Software, Wind River Systems, LynuxWorks, Objective Interface Systems, Physical Optics Corp., Real-Time Innovations, Stauder Technologies, System Planning Corp., and
ViaSat.

Truly open-systems avionics have been a long time in coming, and many of us over the years have seen failed attempts in this direction. The Joint Integrated Avionics Working Group (JIAWG), which tried to come up with open-standards avionics for the F-22 and the long-cancelled RAH-66 Comanche attack helicopter, immediately come to mind.

It will be a long, uphill climb for proponents of the FACE consortium, but efforts will be worth it if this organization can succeed where others have failed.

Thursday, October 28, 2010

Counter-MANPADS for commercial aircraft, where'd it go?


Posted by John McHale
Counter-MANPADS (man-portable air defense systems) for commercial aircraft got a lot of press after the terrorist attacks on Sept. 11, 2001 and I covered it quite a bit in our Homeland Security Solutions magazine back then, but I have not heard much about it in recent years till this week at the AUSA in Washington, DC.

Some of the technology explored for Counter-MANPADS was based on the Advanced Threat Infrared Countermeasures (ATIRCM) system from BAE Systems in Nashua, N.H. I learned this while interviewing Burt Keirstead, director of integrated ASE (aircraft survivability equipment) at BAE Systems in Nashua, N.H., this week at AUSA about the ATIRCM.

The Department of Homeland Security (DHS) Counter-MANPADS program was basically shelved due to reluctance from the airlines to spend money on the system unless subsidized by the government or if there is an attack from a shoulder-fired missile on a commercial airliner causing COutner-MANPADS to be mandated, Keirstead said.

Technologically "it was a success story," he said. BAE System's solution flew about 5,000 hours on a Boeing 767 back forth between Los Angeles International Airport (LAX) in Los Angeles and John F. Kennedy airport outside of New York, Keirstead continued. A couple of the flights included celebrities such as Brittany Spears and Liza Minelli, he added.

It was mounted upside down about 10 feet in front of the fuselage and painted white, Keirstead said. The system was optimized for use on commercial jets with a different cockpit display and a lightening protection unit, among other adjustments, he added.

The system works and could be added in on to the aircraft if it is ever mandated, Keirstead said.

Let's hope it's not necessary.