Cloud computing has demonstrated huge cost savings and operational efficiency benefits for the private sector and now Department of Defense (DoD) IT managers are exploring the concept for enterprise and tactical applications. However, DoD planners are moving much more cautiously to assure they have plugged all the potential cyber security vulnerabilities inherent in something as nebulous as a virtual cloud.

Department of Defense (DoD) officials trying to keep the lights on in today’s budget constrained environment love how cloud computing can reduce data center operational costs, bricks and mortar expenses, and staff overhead. Virtually storing data instead of physically in a hard drive is very appealing – especially to younger military personnel who have grown up with virtual technology such as the iPhone and the iCloud. However, military cloud services – just like military smartphones and tablets – will need to be much more secure.

The National Institute of Standards and Technology (NIST) defines cloud computing as “a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.”

“Back in the 2005 timeframe, Northrop Grumman had hundreds of data centers and consolidated them down to five data centers in 2011,” says Joe Cloyd, Director of Technology, Defense Cyber Security and Enterprise Services at Northrop Grumman (www.northropgrumman.com). “In our next round of consolidation we will go down to three enterprise data centers. The DoD will eventually do this as well, consolidating each respective network, and far down the road possibly rethinking a totally segregated approach to having multiple networks with duplication.”

“Many people initially think a cloud is inherently insecure as it is a single point of failure – the cloud goes and all your data goes with it,” says Todd Moore, Vice President of Product Management at SafeNet (www.safenet.com). “However, responsible cloud providers build in redundancy so when they write data to a cloud, they also write it to a disk at the same time. The virtual environment is encrypted and is also stored on a disk.”

“Securing the cloud is simple, as it is about providing assurance,” says Will Keegan, Technical Director, Software Security at LynuxWorks (www.lynuxworks.com). “Users need to feel comfortable that when they log on remotely, every transaction they make will be secure. The complexities of public ISP cloud systems are too high to assure that data loss or leakages cannot occur. In a public cloud you have to assume all users are adversaries, and we rely on the ISP to protect other customers from stealing my data.”

Transforming “government data centers and applications into cloud computing environments, such as what Northrop Grumman is being asked to do on the Army Private Cloud contract, is often done on-site with security built in from the ground up,” Cloyd says. “This includes the full spectrum of options from enterprise data centers to mobile cloud solutions focused on the tactical edge. We call it ‘cloud transformation,’ which is aiding a customer though various stages of maturity from unstructured chaos to a highly structured approach.”

Mapping to NIST

When it comes to securing the cloud from the ground up, many integrators rely on cloud computing characteristics and guidelines set forth by NIST. “When we think of the cloud we map everything back to the policies and procedures that the business and government communities pulled together under NIST,” Moore says. There are four different types of cloud models: private, public, community, and hybrid as defined by NIST – with public and private being the most likely to be adopted by government users. A private cloud – owned and operated by a single organization or with a third party – is made up of multiple units and can be located on-site or off, according to NIST. A public cloud is open for use by the general public, is located on the premises of the cloud provider, and may be owned, managed, and operated by a business, academic, or government organization or a combination of them, according to the agency.

“If you want to have a cloud service, there are five essential characteristics you need to check off: on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service,” Cloyd says. “Each of these is fairly straightforward for commercial cloud networks, but when applied to the DoD, each has unique challenges. [For example], self-service is about the provisioning of authorized users or services. One unique risk associated with self-service authorized end users is the role of insider threats. The DoD-broad community has millions of users; the Army alone has 1.2 million core users. These are huge numbers and within such a large population insider risk is a real threat. A provider needs to provision its services with proper governance to prevent insider threats. Broad network access is one of the most interesting characteristics from a DoD perspective, as so much of the DoD is focused on rigid, tightly controlled networks such as service-specific portions of NIPRNet and SIPRNet rather than on open network access like the Internet at the other extreme. The key is for services to be available across the entire DoD, and this is largely possible today. The problem is as soon as access is broadened, it increases the attack surface, making the idea of a perimeter and a boundary much more nebulous.”

The Army Knowledge Online (AKO) program “is a great example of a system that exhibits almost every one of the NIST cloud characteristics in that the NIPRNet version supports broad network access from anywhere in the world via the Internet, user accounts and resources are self-provisioned and support elasticity and spikes in usage, the infrastructure allows reallocating virtualized resources within or across its multiple data centers, and the system has been designed to support multitenancy and very detailed usage data for potential chargeback,” Cloyd says. “With checks next to each of those essential characteristics, AKO could be poised as a great example of Software as a Service (SaaS).” SaaS is the capability provided to the consumer to use the provider’s applications running on a cloud infrastructure, according to NIST. Other types of service include Platform as a Service (PaaS), and Infrastructure as a Service (IaaS).

“The DoD will likely set up a cloud for each classification level, as multilevel classification within a single cloud environment is just too much to tackle right now,” Cloyd says. “Down the road, I hope they will move to having multiple classification levels in a cloud, as in the long-term if we do everything right with cloud computing, trusted multitenancy at different classified levels should be within reach.”

Data is key to the kingdom

Secure cloud computing is more than just the network; it is also important to focus on the identity and authentication management to make sure each piece of data in a cloud is being accessed by the proper individual. This is roughly akin to needing an ID card and a retina scan to enter a building and also needing additional authentication factors to access a file in a drawer.

“So much client focus in the DoD is about the network,” Cloyd says. “However, you cannot just focus on a network-based, umbrella approach to protect systems. Data is the key to the kingdom so you have to protect the application, as well as the traditional network boundaries. Identity and access management at the application are finally getting the attention that they deserve, but they are not new concepts. With a growing importance on stronger authentication, cloud providers need to increase the number of authentication factors they consider. The typical two-factor authentication approach – typically a Common Access Card (CAC) in DoD – is not enough; they need to add additional factors based on the risk associated with certain data. We are focusing on ‘fine-grained entitlements’ in applications and how to secure everything with a lot of fidelity at the application level and data level. This also includes new approaches and technologies to securing data at rest.”

“There is a general government-focused trend to move to multifactor authentication,” SafeNet’s Moore says. “The government wants to move away from password-based protection to Public Key Infrastructure (PKI) protection. Things such as SIPRNet smart cards provide two-factor authentication and meet PKI standards. There is a large U.S. government Key Management Infrastructure (KMI) program that is focused on creating and delivering keys to government users ensuring that key rotation – the key life-cycle management – is up to date and efficient. The life of a key depends on the mission requirements. It can last from 24 hours to 6 months to a year if necessary.

“Key management plays into cloud security,” Moore continues. “Data encryption is a typical protection in laptop or mobile devices – encryption of the drive and on-device storage. Encryption also will be needed for data that is stored off-premise in a cloud. These virtual worlds are multitenancy environments with many users and servers involved, creating a need for more granular encryption than is provided at the device level. We will need to encrypt data at the object level – pictures, maps, files, and so on. Encrypting at the object level and tagging each object with situational awareness data require strong enterprise key management so data can be securely accessed anywhere from any device. The data just needs to be locked down at the most granular level with the lock being an encryption key management scheme that protects data at the object level.

“One of the biggest threats is the administrative threat, caused by vulnerabilities related to having a super user or super password that can access every file,” he says. “Industry and government are moving away from super users due to leaks that have occurred. If that super user or super password is compromised, every piece of data in a system is vulnerable. At SafeNet we assume someone is bound to get in, so we work at encrypting each object so even when they get in they can’t wreak havoc with the data. The more granular you drive the encryption, the less exposure your data will have to malicious attacks.”

DDoS attacks

A cyber threat that targets clouds that is becoming more common and getting more attention in the media is the Distributed Denial of Service (DDoS) attack, which messes with the shared infrastructure of a cloud, causing all the subscribers to be at risk. “Cloud organizations that host the services of other organizations and operate their data centers are providing public cloud services instead of private,” says Ronen Kenig, Director of Security Solutions at Radware (www.radware.com). “Public clouds are more likely to be attacked by threats such as DDoS. A public cloud, for example, would be a news site that might be hosting multiple user services on their cloud or business-oriented applications. Each client is then part of the cloud’s shared infrastructure. Anything between the Internet and the servers is a shared infrastructure. If something happens to the shared infrastructure, all customers hosted in the cloud will be affected. If a firewall goes down, nobody can access the cloud. About 63 percent of DDoS attacks strike the shared infrastructure as it’s the first thing the attack will hit.

“Prior to recent attacks on financial institutions in the U.S., there was not much awareness or knowledge of DDoS attacks and other cyber threats,” Kenig says. “However, once the first bank became a victim, immediately all the other institutions started to learn more about the attacks, search for solutions, then deploy those solutions quickly. When I look at military cloud security solutions, there are many vendors and partners providing tools and solutions, but not many providing availability security. DDoS attacks are hurting the availability of online services and many antivirus vendors and firewall vendors do not focus on the availability aspect.”

Cloud providers find protecting the shared infrastructure can be challenging because it is an expensive up-front cost, he continues. “However, if a DDoS attack disrupts the shared infrastructure, every client in the cloud will be adversely affected. If a cloud provider can’t protect the shared infrastructure, other customers will be reluctant to do business with them and they could become a joke in the industry. For large-volume attacks, Radware offers a new security service called Defense Pipe that basically is designed to protect the Internet pipe of a provider, no matter what security solution they use to protect their other data. With Defense Pipe, we divert traffic into a scrubbing center, where it can absorb very large volume to mitigate its effect and protect the cloud service. We activate the service when the Internet pipe is about to get saturated to better protect the cloud data center. All the effects of an attack can be blocked in the data center except those that are saturating the Internet pipe.”

]]> http://tech.opensystemsmedia.com/safety-and-security/2013/05/cloud-security-and-the-dod/feed/ 0 http://www.mil-embedded.com/articles/id/?6020 http://www.mil-embedded.com/articles/id/?6020#comments Thu, 02 May 2013 15:00:00 +0000 Rubin Dhillon, GE Intelligent Platforms http://tech.opensystemsmedia.com/safety-and-security/?guid=209512d0e2b94fa617fbd5a395b58cc4

The network is becoming increasingly crucial to the world’s armed forces. Unsurprisingly, it uses the same technologies that are proven in the commercial world, with much of the equipment sourced by the armed forces being of COTS origin. But the military needs a level of security – anti-tamper, information assurance, data destruction, encryption – way beyond what the commercial world requires. COTS solutions have emerged that leverage the innovations driving the commercial mobile data industry while addressing specific military security concerns such as encryption.

Armed forces around the world, and in particular the United States military, are striving for total information dominance over foreign adversaries. This new focus on information dominance has transformed the battle space, where all assets – unmanned aerial-, terrestrial-, and sea-based platforms; ground combat vehicles; precision guided weapons; handheld computers; and so on – are in constant communication and collaboration over a secure and reliable tactical network. This network is expanded through larger terrestrial networks and support systems in order to provide warfighters and commanders with the information needed for an accurate and real-time common operating environment.

Encryption of all this classified information, both during transmission (“data in motion”) or while it is stored (“data at rest”) is critical to ensure both military operations success and personnel safety. However, a military organization has to be able to communicate securely with its government and potentially other governments, as well as with nonmilitary organizations that might be involved. Using COTS hardware, standard encryption algorithms, key exchange, digital signatures, and hashing enable the timely sharing of classified information.

Encryption transitions to COTS, GOTS

Historically, military critical infrastructure relied on platforms and technologies specifically designed, developed, and delivered for military use. However, initiatives to streamline procurement, improve deployment times, and reduce cost led to the adoption of architectures that increasingly rely on Commercial Off-the-Shelf (COTS) products and technologies or slight derivatives customized for military use – Government Off-the-Shelf (GOTS). This focus on commercially derived technologies is currently seeing renewed emphasis, with these COTS and GOTS platforms leveraging the most advanced and forward-looking technologies and architectures in the industry – for example, virtualization, mobility, cloud computing, and so on.

The migration to COTS/GOTS systems increases the importance and complication of the role encryption plays for the warfighter. How do governments ensure that they can trust these devices to handle their most sensitive data, and how can individual vendors or industry partnerships provide technologies and platforms that facilitate the approved encryption processes?

In the United States, military cryptography is traditionally developed and maintained by the National Security Agency (NSA). Not only does the NSA develop secret crypto algorithms designated as “Type 1” or “Type A” cryptos for classified U.S. government communications, but its responsibilities also include the approval of all military communications and computing devices that implement encryption. As the requirements for military communications have grown rapidly over the past few years, installation, deployment, performance, obsolescence, and maintenance issues and rising costs are becoming an increasing concern. In 2005, the NSA and the U.S. DoD launched the Cryptographic Modernization Program to combat these issues.

Perhaps the most remarkable development of the Cryptographic Modernization Program has been the acceptance and adoption of nonclassified, industry-developed cryptographic algorithms. These so-called “Suite B” cryptos are more conducive to the military’s COTS/GOTS systems strategy.

Cryptographic algorithms are open standards-based

Suite B encrypted systems are based on open standards cryptographic algorithms. Governments such as that of the United States publish guidelines and standards that outline which algorithms may be used for classified and nonclassified information. The Federal Information Processing Standard FIPS 140-2 published by the National Institute of Standards and Technology (NIST) outlines the cryptography requirements for all devices used on a National Security System. Government/military agencies use the Common Criteria for Information Technology Security Evaluation (often referred to as simply Common Criteria or CC) international standard when they specify security requirements. Using a Common Criteria rating scale ranging from Evaluation Assurance Level (EAL) 1 through 7, the government can compare how rigorously particular devices have been tested to meet their security requirements. Implementing standard cryptographic algorithms and key exchange is not authorized on a National Security System until they have been tested and certified. Common Criteria evaluation and validation must be done by an accredited NSA/NIST testing laboratory.

It is important to point out that a higher EAL rating does not necessarily mean that one device is more secure than another – only that it has been tested more rigorously, suggesting a higher level of trust. Most hardware network devices carry an EAL rating between 1 and 4. GE’s RTR8GE rugged secure battlefield router, for example, runs a FIPS-certified version of Juniper Networks’ Junos network operating system and has achieved the Common Criteria EAL 4 rating, which states “methodically designed, tested, and reviewed” (Figure 1). Given the rapid growth in the number of devices going through the evaluation process and the time and cost involved in obtaining such a high rating, EAL 4 rated devices will likely be rare in the future. Most networking devices today only carry an EAL 2 rating, which designates that the solution was “structurally tested.”

Encryption methodologies are evolving

The premise of public-key cryptography is that the mathematical problem that must be solved to decrypt the communication would take so long to solve that by the time it was solved, the information would no longer be useful. Suite B uses Elliptical Curve Cryptography (ECC), which has the advantage of using much smaller keys with an equivalent level of security, thereby reducing the computing power and bandwidth required. The efficiency of ECC enables a high level of security for the wide range of Internet Protocol (IP)-enabled devices available today.

There is no question that Internet Protocol is rapidly becoming the dominant network protocol used throughout military communications networks, and while it is still common to find specialized military- and application-specific protocols in the tactical battlefield environment, these are being replaced. Therefore, Internet Protocol Security (IPSec) (see Sidebars 1 and 2), a set of open standard Internet Engineering Task Force (IETF) standards, is used throughout military networks to configure encryption and secure sensitive communications. IPSec with the approved, tested, and validated encryption algorithms and key management can meet the FIPS 140-2 and Common Criteria requirements for encryption over IP networks.

IPSec is a point-to-point architecture that manages key exchange, verifies the integrity of data packets, negotiates crypto algorithms, and authenticates between two end-nodes on a network. However, regardless of the key management methodologies or security protocols implemented, IPsec might not be ideal for tactical military networks, particularly as they grow in size and complexity. Key distribution and management will likely represent serious challenges, and application performance, dynamic routing, reliability, and management might all suffer.

A group-based network encryption has evolved that promises to address the limitations of traditional IPSec point-to-point architectures. The standards-based Group Encrypted Transport (GET) integrates routing and encryption together in the network and alleviates the need to set up individual point-to-point connections. Since policies and keys are managed from a central point, key distribution and management are greatly simplified. Group Encrypted Transport is well suited to battlefield networks, given their dynamic and mobile nature, with diverse devices transmitting and receiving sensitive data over a large geographic area. Military network architects will likely prefer the flexibility afforded by GET over traditional IPsec tunneling.

Encryption faces new challenges

Server virtualization and hypervisor technologies have grown to enable cloud computing in the commercial/data center world, and these technologies are now finding their way onto the battlefield. Government agencies, including the DoD, continue to embrace emerging technologies such as cloud computing. In fact, cloud computing promises to address some of the DoD’s most pressing issues such as improving deployment time for new warfighter applications and technology, enabling data sharing between joint forces and allies, and simplifying and streamlining network management – all while reducing costs.

The basic concept behind the implementation of cloud computing, virtual machines, and virtual networks is to replace hardware devices with software. A single rugged multicore computing device installed in an unmanned platform, for example, could perform the function of mission computer, router, firewall, and sensor processor – an architecture that provides significant SWaP benefits, essentially replacing four individual devices.

However, this concept of a software-based appliance is challenged by the fact that government and DoD policies, procedures, certifications, and testing methodologies primarily revolve around hardware devices. Foundations have been laid by the NSA that would allow use of software-based Suite B crypto “devices” running in virtual machines, but the evaluation process needs to catch up. Since the benefits of cloud computing and virtualization are so compelling, industry and the DoD are working closely to address these procedural issues and we will likely see this addressed within the next few years.

Commercial users will follow

As the next phase of the Internet begins to develop with the Industrial Internet Revolution, the focus is shifting from communications between people to communication between machines, manufacturing plants, energy production facilities, logistics/shipping hubs and even aircraft engines. All these are transmitting, storing, and sharing data like never before. Other government agencies and Non-Governmental Organizations (NGOs) providing law enforcement and homeland security seek the benefits of cloud computing architectures to share critical and sensitive information as well.

However, many of these nonmilitary industries and applications are unprepared for the security implications that ubiquitous connectivity brings and therefore look to the military sector for the technology and procedures needed. Solutions that have a Common Criteria EAL rating are attractive in nonmilitary markets and, as the Industrial Internet grows, it is likely that more and more devices will embed the encryption algorithms, methodologies, and design principles that are common in military systems. It is safe to say that this will be an exciting arena to watch for many years to come.

Rubin Dhillon is Business Development Manager at GE Intelligent Platforms. He can be contacted at rubinder.dhillon@ge.com.

GE Intelligent Platforms

defense.ge-ip.com

Jim Kelly is Product Line Manager at Juniper Networks. He can be contacted at jkelly@juniper.net.

Juniper Networks

www.juniper.net

]]> http://tech.opensystemsmedia.com/safety-and-security/2013/05/encryption-and-the-migration-to-cots-technologies/feed/ 0 http://www.mil-embedded.com/articles/id/?5965 http://www.mil-embedded.com/articles/id/?5965#comments Tue, 12 Mar 2013 15:00:00 +0000 Benjamin M. Brosgol, PhD, AdaCore http://tech.opensystemsmedia.com/safety-and-security/?guid=6cbd3c1433401682633163bff61be169

DO-332, the DO-178C standard’s supplement on Object-Oriented Technology (OOT) and related techniques, analyzes the issues raised by object orientation in safety-critical software and supplies new guidance to deal with OOT’s vulnerabilities. An important new objective of DO-332 is “Local Type Consistency Verification,” which exploits a type theory result known as “the Liskov Substitution Principle” and helps address some of the key certification challenges raised by OOT’s dynamic flexibility.

Object-Oriented Technology (OOT) is widely used and is supported by a range of programming languages including C++, Java, and Ada, but for various reasons its popularity has not spread to airborne and other safety-critical software. The underlying problem is the complexity of verifying software that makes use of three of OOT’s basic elements: inheritance, polymorphism, and dynamic binding. (Figure 1 explains the object orientation basics.) A simple example illustrates the issues:

Suppose that the Sensor class is the root of an inheritance hierarchy, ref is a polymorphic reference to an object from any class in this hierarchy, and Reset is an operation defined differently for different Sensor classes. The statement ref.Reset(…) dynamically binds to the appropriate version, based on the class of the object denoted by ref. How does one verify that this invocation meets the requirements for the Reset operation?

One problem arises if inheritance is used to define a subclass that is not a specialization of Sensor. This subclass’s Reset may have some effect unrelated to resetting a Sensor, or it may generate an exception. It would be an error for ref to reference an object from such a subclass, and analysis would be needed to show that the error could not occur. This complicates the verification process.

Another issue concerns structural coverage analysis. For systems at any of the three highest levels (A, B, or C) of the DO-178 standards, complete statement coverage must be demonstrated using requirements-based tests. But there are several implementation strategies that a compiler might choose for handling dynamic binding, with different implications on what “statement coverage” means. The scope of the structural coverage should not depend on the implementation strategy that the compiler uses.

DO-332[1], the OOT supplement to DO-178C[2], has addressed these issues through the new concept of local type consistency, which exploits the principle that inheritance should only be used for class specialization.

Inheritance and the Liskov Substitution Principle

In an object-oriented design, the system’s architecture reflects the classes and their relationships. A particularly important relationship is specialization (“is a”), but there are many others. Implementing the design involves choosing language mechanisms for capturing the relationships.

In an object-oriented language, inheritance may be used to implement a variety of relationships between two classes. However, anomalies can arise when inheritance is used for anything besides specialization since operations defined for the superclass might not make sense for the subclass. Restricting inheritance to specialization relationships has been studied in the context of type theory, where it is known as the Liskov Substitution Principle (LSP)[3]. Informally, LSP means that wherever an instance of a superclass can be used, substituting an instance of any subclass should be permissible.

Using inheritance for specialization has an important interaction with an operation’s preconditions and postconditions (its “contract”). A precondition is an assumption that the operation is making with respect to the program state when the operation is invoked. A postcondition is a guarantee that the operation is making on the program state when the operation is completed. Pre- and postconditions may be specified explicitly – either in the source text, as in Ada 2012[4] or SPARK[5], or separately – or they may be implicit in the logic of the operation.

If inheritance is to comply with LSP, a subclass’s version of an operation should not impose a stronger (more restrictive) precondition than the superclass’s version. Otherwise an invocation might succeed in some cases (on a superclass instance) but fail in others (on a subclass instance). Analogously, a subclass’s version of an operation should not specify a weaker (more general) postcondition than the superclass’s version.

Complying with LSP thus means satisfying two properties:

• Contract consistency: No subclass operation strengthens a precondition or weakens a postcondition of the superclass operation that it is overriding.
• Behavioral consistency: Each subclass operation meets its superclasses’ requirements.

DO-332 captures these concepts in a new objective, Local Type Consistency Verification. This objective does not require demonstrating that the class hierarchy complies with LSP, which would be overly restrictive. Instead, it reflects that the verification effort is simpler for class architectures that do comply, and that the analysis only needs to consider local context.

Local type consistency

Figure 2 shows the activity associated with verifying local type consistency, which DO-332 requires for software at levels A, B, or C. The wording “for each subtype where substitution is used” refers to contexts where dynamic binding occurs, such as ref.Reset(…), and the “subtype” in question is the class of an object that ref could reference at that point. The potential classes will not necessarily be the full hierarchy, and different sets of classes may be applicable at different invocations of the same operation.

Consider a particular occurrence of ref.Reset(…), and let HeatSensor be one of the possible subclasses for the objects that ref could reference there. Local type consistency of ref.Reset(…) for HeatSensor may be demonstrated either “optimistically” or “pessimistically.” The optimistic approach works if HeatSensor satisfies LSP, and may be carried out in two ways:

• Through formal methods, by demonstrating that HeatSensor’s version of Reset meets the requirements for Sensor’s version and does not strengthen the preconditions or weaken the postconditions of Sensor’s Reset.
• Through testing, by running the requirements-based tests for Sensor’s version of Reset, using an instance of HeatSensor.

Formal methods may be facilitated by appropriate support from the programming language and its toolset, for example, Ada 2012 or SPARK.

The optimistic approach will demonstrate contract and behavioral consistency between the superclass’s and subclass’s versions of the operation. Additional verification is obtained through requirements-based tests for the subclass and possibly also through formal methods.

If the classes do not comply with LSP, or if there are few dynamically bound calls or the hierarchy is shallow and/or narrow, then it may be simplest just to test each possible case that can arise. This is the pessimistic testing specified in the third bullet item in Figure 2. Requirements-based tests are needed to exercise the operation for each subclass that could arise.

DO-332, local type consistency, and LSP guide certification

Local type consistency verification is just one aspect of using OOT safely; DO-332 contains guidance on other OOT elements as well as related techniques such as generic templates. DO-332 is “language agnostic”; more specifics are available on how to apply OOT in safety-critical or high-security systems, using Ada 2012 as the programming language[6].

DO-332’s local type consistency guidance is consistent with DO-178C’s general approach to verification, ensuring that all tests are based on requirements. It adapts the verification activities in a novel way to reflect the semantics of object orientation and the class structure’s degree of compliance with LSP. The new guidance should help to promote the safe use of Object-Oriented Programming (OOP) in avionics and other critical domains.

References

[1] RTCA/EUROCAE DO-178C/ED-12C. Software Considerations in Airborne Systems and Equipment Certification, December 2011.

[2] RTCA/EUROCAE DO-332/ED-217. Object-Oriented Technology and Related Techniques Supplement to DO-178C and DO-278A, December 2011.

[3] B. Liskov and J. Wing. “A behavioral notion of subtyping,” ACM Transactions on Programming Languages and Systems (TOPLAS), Vol. 16, Issue 6 (November 1994), pg. 1811-1841.

[4] Ada 2012 Language Reference Manual (December 2012), www.ada-auth.org/standards/ada12.html

[5] J. Barnes with Altran Praxis. SPARK – The Proven Approach to High Integrity Software. Altran Praxis, 2012.

[6] AdaCore, High-Integrity Object-Oriented Programming in Ada, July 2011. extranet.eu.adacore.com/articles/HighIntegrityAda.pdf

Dr. Benjamin M. Brosgol is a senior member of the technical staff at AdaCore. He has more than 30 years of experience in the software industry, concentrating on languages and technologies for high-integrity systems. He has presented papers and tutorials on safety and security certification at numerous conferences and has published articles on this subject in a variety of technical journals. He holds a Ph.D. in Applied Mathematics from Harvard University. He can be contacted at brosgol@adacore.com.

AdaCore 212-620-7300 • www.adacore.com www.linkedin.com/company/adacore www.twitter.com/AdaCoreCompany

]]> http://tech.opensystemsmedia.com/safety-and-security/2013/03/do-332-the-liskov-substitution-principle-and-local-type-consistency-ramp-up-do-178-certification/feed/ 0 http://www.mil-embedded.com/articles/id/?5872 http://www.mil-embedded.com/articles/id/?5872#comments Wed, 05 Dec 2012 15:00:00 +0000 admin http://tech.opensystemsmedia.com/safety-and-security/?guid=28c0b1af6b18fc5ace33ae4b61cb5d62

Military planners want warfighters to have the same capability that civilian consumers get from their commercial smartphones and are testing different devices. However, they still have to overcome security hurdles and the short development cycles in the commercial market before full-scale deployment can happen.

The typical civilian smartphone – whether it is an iPhone 5, Samsung Galaxy III, or even a Blackberry – is easier to use and has more processing capability than any handheld device that soldiers, Marines, sailors, or airmen use in combat environments today. Modern cell phones have amazing technology, but are not seen as rugged or secure enough for military use on the battlefield. That is until recently. Different programs are in development in the Services to leverage commercial smartphones for battlefield use. One Army initiative – the Nett Warrior program, run by PEO Soldier – expects field these devices as early as 2014.

“No defense company in the world can beat the reliability and performance these small devices deliver,” says Jason Regnier, Acting Program Manager for the Nett Warrior program at Ft. Belvoir, VA. “It is money well spent. What is enabling their use in part from a policy was a relaxing of the requirements about the environments they would be used in. For example, they don’t have to survive a nuclear blast anymore. We are still looking at more ruggedized devices for underwater use and the like, but right now we are focused on commercial devices due to the tremendous cost savings and they are meeting all of our objectives so far.”

“Smartphone development within the DoD is a testing environment,” says Brett Kitchens, Senior Director, DoD Strategic Programs, U.S. Federal Government Markets at Motorola. “PEO Soldier wants a smartphone device at the edge running secret-level security, but it is not a program of record yet today. I think the efforts will move quickly. Some brigades are already testing different smartphone equipment and software. Eventually there will most likely be a pool of devices for the services to choose from based on their mission needs and user preference.”

Nett Warrior

Right now Nett Warrior – an integrated, dismounted situational awareness and mission command system – is in the operational testing phase and begins fielding in 2014, Regnier says. However, the Army is in a hurry to get this technology out earlier and is fielding Motorola Atrix Android-enabled smartphones with certain brigades this year to improve situational awareness. They are still secure with strong encryption, but not certified by NSA for secret data. It is not under a program of record, but is more of an experimental requirement.

The Nett Warrior program is currently using Rifleman Radios from General Dynamics C4 Systems during demonstrations to interface with various smartphone devices running the Android operating system, Regnier says. The Rifleman Radio is an interim solution until the Army finishes developing the Nett Warrior tactical radio, he says. General Dynamics C4 Systems also is developing the Nett Warrior radio, which will weigh less than 2 lbs., communicate using the Soldier Radio Waveform (SRW), and enable access to the U.S. government’s classified networks at the secret or sensitive but unclassified levels, according to a General Dynamics release. The Low Rate Initial Production order is for 2,052 radios, scheduled to begin delivery early in 2013.

“For the smartphones, we are looking at commercial devices that have a dual or quad processor design, are low power, are unlocked so we can remove their software and install the government code, and have a bright, easily readable display,” Regnier says. “The WiFi and Bluetooth functions are turned off on these phones and only connect through the tactical radio. Each device functions essentially as a mini computer with a dual- or quad-core processor.

“One common frustration with using these commercial devices is that just when you have one modified and the proper software added, the company stops selling them,” Regnier continues. “An example of this was a Samsung Note device we looked at that had a large, bright screen that the warfighters liked, but we were too late as Samsung has already stopped selling them and moved on to the next one. The commercial development cycle goes even faster than we thought it would. For Nett Warrior to make it through each year, I will have to look at what the next smartphone will be to keep up with what the commercial cell phone guys are doing. For example, many cell phone companies are moving to Organic Light Emitting Diode (OLED) displays, which will be brighter but easily detectable at night. We need to make it dark so the enemy can’t detect it and make the displays compatible with night vision goggles.

“The key will be to eventually have software that will work across multiple platforms even if the physical devices go obsolete,” Regnier continues. “If you do it right and follow the coding it will work. But for us there are only certain phones that will work because the manufacturers do not unlock all the phones in the same way. We need the devices unlocked so we can remove their code and upload our certified software. The reason is we have to have secret capability in the end user device.”

Securing smartphone communications

“The first hurdle for smartphone acceptance in the military is the security aspect, and industry and the government have got to prove it. But we think we have [gotten] it solved,” Kitchens says. “We anchor the data at rest, which then goes through the chip as encrypted packet and users will have the keys to secure. Also if you pull the data out without the key, you kill it. The NSA is looking at certifying the security solutions and there will be different paths to agency certification of devices. They will also need criteria for mobility. It will be up to the authorities to take the risk, and right now 256 encryption looks good enough as it has not been broken, and 256 B is even tougher.” Motorola secure smartphones include their AME 1000, which is based on the ES400 device for enterprise applications (Figure 1).

“Warfighters see the value of what you can do with a smartphone, but before it gets into the field en masse, the devices really need to be secured,” says Tim Skutt, MILS Solution Architect at Wind River. “Right now smartphone use is kind of in a middle ground, going through limited experiments, not in widespread deployment yet. Wind River’s secure Android offering has a holistic approach that supports integration of security enhancements tailored to the use case, as well as unique commercial Android capabilities, into security enhanced devices. We have five pillars that we are implementing when developing Android solutions – attack detection and prevention; device integrity; isolation; infrastructure security; data protection and system protection, which includes the ability to sanitize remotely.”

Trusted Handheld Platform

“Enabling top-secret security in a COTS phone is a difficult challenge,” says Gordon Jones, INTEGRITY Secure Virtualization at Green Hills Software. “Certifying a COTS phone for use can be done, but by the time the phone is certified, it may be obsolete before you can deploy it to the troops. What is needed is a way to keep the security portable across architectures that also meets the commercial release process.” Green Hills is participating in a Marine Corps effort called the Trusted Handheld Platform that is looking to advance the development of commercial mobile device technology for the DoD by enabling a capability to access multiple security domains, Jones says.

The program has four requirements, with the first seeking an isolation technology such as a separation kernel or security kernel, he continues. This will isolate the software components, control the intra-domain access, and also isolate the other resources on the devices. Second, it must be multipersonality, so the devices support multiple personalities on a single handset. Another requirement is that it use commercial standards and not be a custom government design. The fourth requirement is that it have a common product line architecture across multiple platforms, Jones says.

“Green Hills engineers are applying their separation kernel – INTEGRITY – and running multiple versions of Android on top of it and controlling the device,” Jones says. “This guarantees separation time and space for the applications on top and also runs a complete virtual machine monitor. There will be applications running inside of Android, and since Android is a large and complex piece of code, the level of assurance for any code running inside of Android is low so isolation is required. What we do is isolate Android from the rest of the system. For instance, one Android could be connected to the Secure Internet Protocol Router (SIPR) network and one will be connected to the Non-secure Internet Protocol Router (NIPR) network, but they will be isolated from one another on top of the INTEGRITY kernel.”

This dual domain phone would have an IT persona and a private persona – both isolated from each other on top of a trusted environment that would have an NSA-certified separation kernel like INTEGRITY, Jones says. A dual domain smartphone for the warfighter could operate in a classified and unclassified network as well as separate personal and work data. Having only one physical device also enables the warfighter to save on size, weight, and power, he adds.

“For protection of data at rest when implementing the INTEGRITY kernel on a device with Android as a guest, we insert a virtual self-encrypting drive that guarantees that every piece of data written to memory is encrypted by INTEGRITY in a trusted partition before being written to memory in the phone,” Jones says. Therefore, as data moves in and out of Android unknown to Android, it is encrypted by the architecture when in motion or at rest and cannot be compromised.

Secure networks and tactical app stores

Engineers at Lockheed Martin are enabling the use of commercial tablets and smartphones by developing a secure 4G tactical cellular network they call MONAX, says David Weber, Business Development Manager, C4ISR Systems at Lockheed Martin Information Systems & Global Solutions in Philadelphia. The network can be set up in places where there are no cell towers and, within hours, a private, secure cellular network is operational (Figure 2). No matter the smartphone or tablet device used for voice, video, and data transmission, users will still be able to access the network if they have the proper clearance, Weber says. Once connected, their device accesses a VPN tunnel that is encrypted, he adds.

“Once you get into the network, there are multiple layers of security via the Mobile Device Management (MDM) feature, which enables users to set secure access policies,” Weber says. “The system can also be Common Access Card (CAC) enabled. For data at rest protection, the system can be remotely zeroed out through the MDM feature. Tactical radio users also can access MONAX by just entering the VPN tunnel, he adds.

“We have a MONAX application store that is very minimal because we don’t build apps, but we will have the capability to download apps or purchase them from other vendors,” Weber says. “Five apps that come with the MONAX solution are VOIP, tactical app, chat, map app, and an NSA app. The apps are developed for or rehosted on a smartphone, then approved and made available to warfighters in the app store. You can download popular apps, but we recommend you turn that capability off. If the customer wants to, we can enable it, but it can be risky as it opens up to the ‘dirty’ Internet.”

The system consists of a portable MONAX Lynx sleeve that connects touch-screen smartphones and tablets to a MONAX XG Base Station infrastructure located on the ground or on airborne platforms, according to a Lockheed Martin MONAX brochure. Currently the Marine Corps uses MONAX in military exercises and it is also used for humanitarian disaster relief, Weber says. The Coast Guard is using MONAX with iPads in all their medical clinics across the U.S., he adds.

Ruggedizing the smartphone

While commercial smartphones have state-of-the-art processing capability, they are not what the military would traditionally call “rugged,” but have features and interfaces with which warfighters are comfortable. The Army did run a program for rugged handheld development called the Joint Battle Command-Platform (JBCP) Handheld System, which has since been moved under Nett Warrior. It is no longer an active program, but the Army is still looking at the ruggedization developments.

DRS Tactical Systems’ first rugged handheld offering came out of that program and was called the SCORPION H1. “Although we met the initial requirement, it became clear it didn’t meet with user expectations,” says Bill Guyan, VP at DRS Tactical Systems. “Warfighters have the same expectations – in terms of ease of use – that they get from their personal smartphone: lightweight, small enough to fit in a pocket, and an efficient touch screen with good visibility and graphics. So for the next version – the H2 – we went a bit outside the box. We ruggedized a commercial handheld instead of building it from the ground up.”

The H2’s appeal is its modularity that enables warfighters to customize it for their mission. Its sled mating system mates through a connector that allows for expansion sleds for extended battery life, USB hub, SAASM GPS, information assurance, RFID, IR camera, dead reckoning, a cold weather module chemical/biological detection, or a combination based on customer specifics. If the phone is damaged or a newer model is available, it also can be easily swapped in and out of the housing. The 3G/4G-ready H2 features the Google Android 2.3.5 (Gingerbread) preinstalled and is Android 4.0 (Ice Cream Sandwich) ready. It uses a Qualcomm Snapdragon S3 Processor and has 1 GB of RAM. It weighs 8 ounces and has about 8 hours of battery life and can be charged while interacting with tactical radios.

The General Dynamics Itronix GD300 rugged smartphone also came out of the JBCP, says a General Dynamics spokesperson. The device meets MIL-STD-810G and is resistant to dust, rain, shock and vibration, and humidity. It has GPS capability, can be worn on the arm or chest, and weighs less than 10 ounces. The GD300 also can interface to a tactical radio network for secure communications.

]]> http://tech.opensystemsmedia.com/safety-and-security/2012/12/smartphones-on-the-battlefield/feed/ 0 http://www.embedded-computing.com/articles/id/?5844 http://www.embedded-computing.com/articles/id/?5844#comments Thu, 08 Nov 2012 15:00:00 +0000 Sasan Montaseri, ITTIA http://tech.opensystemsmedia.com/safety-and-security/?guid=8137ebb17ff0b235038426765d0febbc

Securing data is becoming more critical and more difficult to accomplish as embedded application development has increased in complexity, especially when different communication protocols are incorporated into embedded designs. Developers need to know the options for managing data in a secure way and understand the role of a database in maintaining security over data management channels.

Security is an important consideration when mobile devices and other embedded systems interoperate with other systems and components. Unauthorized access, eavesdropping, session hijacking, and other security threats can result in irreversible damages such as data loss, intellectual property theft, and malfunction.

Data management security is a fundamental requirement of applications developed for embedded systems. From industrial automation and medical devices to solar power inverters and even home entertainment systems, data must be protected both at rest on the device and during communication. But who bears responsibility for data security? All device components must employ a security-conscious design, from the application and embedded database down to the hardware.

Safeguarding embedded data

Embedded application development is becoming more complex, and developers are interested in learning how to manage data securely across all phases of development for embedded systems. Whether an engineer is building a mobile device, solar inverter, medical equipment, or any other embedded system, data security is the riskiest part of a design.

Authentication and encryption technologies are essential to secure data storage and distribution, but what does an embedded developer need to know to secure an embedded database? As securing data becomes more critical and regulators and consumers demand serious data protection, an application developer might ask: How do I ensure that my application will be secure? Should data be secured at the application level or at the database level? Can security be implemented by simply assembling the right combination of technologies?

As long as data remains local to an embedded system with no communication layer, security management is not very complex. However, as communication protocols such as TCP/IP are added to the design, security supervision becomes more problematic, and developers must learn about various options such as securing the socket layer so data can be accessed safely.

Securing data at the application level

Databases and applications can offer a safe haven to make data secure. Developers can encrypt data before it leaves the application and arrives in the database, but this is only viable for unsearchable data. For example, an embedded system that manages security for a gate will have a list of staff and their credentials, such as PINs or passwords. The credentials should be encrypted by the application so they can be verified individually. However, any information used to identify or list staff members must not be encrypted by the application.

Physical security is also important. A gate security system should not store data on removable flash media that could be easily replaced to circumvent security. However, even if data is stored internally, a dedicated attacker with physical access to the device can almost always access the data stored there. Storage-level encryption is necessary to protect sensitive data in this scenario.

Securing data at the database level

Encryption is a recognized security method where data is encoded with a specific encryption key and the same data can only be read by supplying the same key. File encryption is a way to keep the data secure, as it will block access to each database file until the application provides the correct key. This method protects data in case of media theft and, as long as access to data is limited to local connections, is a preferred method for offering security.

In the past, encrypting data before it left the system was a common way to manage and secure data. However, this approach can make it difficult to analyze data and search for individual information.

Securing remote access and data distribution

Database security is important to developers who are concerned with data confidentiality, integrity, and availability. While steps such as creating a procedure for end-user access can restrict physical access, database security requires special attention and greatly affects risk management for an embedded system. Developers of mission-critical applications and business intelligence systems experience critical safety vulnerabilities if malicious systems on the network or malware applications intercept access to confidential data.

How can a developer secure remote access from an unauthorized session? Remote access requires protection from unauthorized access, as well as eavesdropping and session hijacking. These faults can be caused by a lack of security for data management and data distribution.

When consumers access data remotely, they might connect to the database without authorization, allowing anyone to access this data online. Therefore, it is necessary to implement an authorization token so consumers can use passwords to access the database. This secures communications to prevent direct access to the database by an unauthorized party.

Embedded database security features

Some applications collect data locally and periodically post that data to a server on the Internet. Other computers on the Internet or local network can observe or tamper with that connection if it is not encrypted. Developers often look for security and authentication features in the embedded database to offer flexible data safety techniques that address these problems. Using database security features, developers can achieve data security in embedded applications by encrypting both network communications and storage media.

ITTIA DB SQL is a database software library for mobile devices and other embedded systems that offers secure file storage, remote access, and replication (see Figure 1). Whether a database file is only accessed locally or shared over a public TCP/IP network, the encryption features provided by ITTIA DB SQL ensure that data is protected from unauthorized access, eavesdropping, and session hijacking.

To protect data at rest on a device, each database file can be encrypted with an AES-128 or AES-256 key. Advanced Encryption Standard (AES) is a data encryption specification that has been adopted by the U.S. government and other governing bodies across the world. Even if the database is removed from the device, it cannot be read or modified without the encryption key. As a result, sensitive data can be stored on or backed up to the removable media on a consumer mobile device without compromising security.

Security becomes an even greater concern when an embedded device can share data with other devices and back-end systems. Whether data is shared over an active client/server connection or through passive replication, communications should be authenticated using a protocol such as Salted Challenge Response Authentication Mechanism (SCRAM) that does not require the database password to be transmitted over the network. This ensures that only authorized parties can initiate a connection and modify the embedded database.

Connections over a public network such as the Internet should also secure the communication channel with Transport Layer Security (TLS) or its predecessor, Secure Sockets Layer (SSL). This prevents eavesdropping from other devices on the network and man-in-the-middle attacks such as session hijacking that can compromise security even after an authenticated connection is established.

Whether an application targets Windows, Linux, Android, ThreadX, QNX, or one of the many other operating systems commonly found in embedded devices, software developers must consider the security implications of data sharing and storage. Selecting an embedded database that provides the required features is critical to the specification and design of secure applications. While it is ultimately up to the application to implement adequate security measures, an embedded database that offers the fundamentals for managing security is essential to protect embedded designs.

Sasan Montaseri is the founder of ITTIA.

ITTIA sasan@ittia.com www.ittia.com

Follow: Linkedin YouTube

]]> http://tech.opensystemsmedia.com/safety-and-security/2012/11/embedding-security-into-data-management/feed/ 0 http://www.mil-embedded.com/articles/id/?5760 http://www.mil-embedded.com/articles/id/?5760#comments Tue, 04 Sep 2012 15:00:00 +0000 Chris Tapp, LDRA http://tech.opensystemsmedia.com/safety-and-security/?guid=1f2655907f118763af197114e78ce6da

The Common Weakness Enumeration (CWE) lists the common-mode failures that have led to security breaches in numerous software systems. It can be used to help improve the robustness of critical networks and infrastructure to help thwart cyber attacks.

Net-centric warfare uses a system of networks to share information within a combat theatre. This advanced communications network enhances situational awareness with the aim of improving mission effectiveness.

The network that underpins such a system has the potential to expose a significant attack surface to the enemy, raising significant security concerns. After looking at what measures need to be adopted to ensure secure systems, the following examines the Common Weakness and Enumeration (CWE) and demonstrates how it can be used to enhance security in battle communications.

Security concerns

Internal networks are often targeted as a means of gaining access to confidential information. In 2008 classified and unclassified systems within a U.S. Military Central Command network were found to have been compromised. Investigations showed that a military laptop was infected by a portable USB drive. This infection then spread through network connections to secure areas and is believed to have been used to transfer significant amounts of data to a third party. Infected machines are still being found four years after the initial attack.

External attacks are also attempted.For example, network vulnerabilities within one or more contractors working on the Joint Strike Fighter were exploited to gain access to sensitive project data. The attack appears to have started in 2007, but was not detected until 2009. The attack comprised installation of sophisticated spyware within the development environment. The spyware was used to transfer terabytes of data to a third party. The exact nature of the compromise is unknown as the data was heavily encrypted before being sent.

It is not always easy to understand why a system has been attacked, and it is possible that some attacks are accidental. The systems used to control the Predator and Reaper drone fleet were recently found to have been infected with a virus containing a key-logger payload. The key-logger recorded the actions of drone pilots while on active service but did not affect system functionality. It appears that no data was lost, though this might simply be because of the lack of exploitable external network connection. The network infection is proving hard to eradicate and has been found to have spread to classified and unclassified systems. It is thought that the virus was unintentionally introduced by a portable USB drive used to transfer map and other data into the control system.

Loss of sensitive information is not the only possible outcome of an attack. A virus detected within a military air traffic control system has the potential to allow a third party to render radar data untrustworthy, leading to confusion or asset loss.

Security considerations

Many of these security concerns arise because of device interconnection within a system-of-systems. It is hard for an attacker to exploit systems that are operated in isolation. However, if they are networked, even if intermittently, the network allows many other systems to be attacked. If they are all based on the same technology, then common security vulnerabilities can be exploited to allow rapid dissemination of malware.

CWE examined

The vulnerabilities exploited are generally related to code implementation or requirement errors. For example, a buffer overrun event triggered by invalid network data might be used to trick a system into running arbitrary code injected by an attacker. According to research by the National Institute of Security Technology (NIST), 64 percent of software vulnerabilities stem from programming errors.

CWE is a strategic software assurance initiative run by the MITRE Corporation under a U.S. federal grant, cosponsored by the National Cyber Security Division of the U.S. Department of Homeland Security. It lists the programming errors that have led to security failures within systems with the aim of improving the software assurance and review processes used to ensure connected devices are secure. Enumeration of the vulnerabilities in this way allows coding standards to be defined to target them so that they can be eliminated during development.

The CWE database

The CWE database contains information on security weaknesses that have been proven to lead to exploitable vulnerabilities. These weaknesses could be at the infrastructure level (for example, a poorly configured network and/or security appliance), policy and procedure level (for example, sharing usernames and/or passwords), or coding level (for example, failing to validate data). The CWE database holds information on actual exploits, not theoretical, and so only captures those coding weaknesses that have been exploited in the field.

Benefits of CWE compatibility

CWE should be used within the development environment to ensure that known vulnerabilities are not introduced into the software. Many of the issues that have been identified are amenable to automatic detection by static and/or dynamic checking tools. To obtain maximum benefit, such tools should be used as early as possible in the development process, as trying to add security in at the last minute is very unlikely to succeed. The adoption of other tool-enforced security standards, such as the CERT-C Secure Coding Standard, compliments this objective and enhances the security characteristics even further.

Ensuring system security

Many security vulnerabilities can be traced to coding errors or architectural flaws and are generally hard and/or expensive to fix once a system has been deployed. Unfortunately, many developers are only interested in the development and testing of core application functionality. Security is rarely tested with the same rigor.

The security of a system needs to be considered one of the most important attributes of a system. Security requirements need to be included up front in the system design and implemented during normal development if the final system is to be secure. CWE can be used to help in the identification of appropriate high-level security requirements.

Figure 1 illustrates the attributes associated with system quality. By focusing on these measures at all phases of the software development life cycle, developers can help eliminate known weaknesses.

To prevent the introduction of security vulnerabilities, a development team needs to have a common understanding of the security goals and approaches to be taken during development. This should include an assessment of the security risks and the establishment of the secure coding practices that are to be used. Once again, CWE can help during coding as it highlights the constructs that have led to security compromises in other systems, reminding developers where they need to take extra care during implementation.

The risk assessment determines the quantitative and qualitative security risk for the various system components in relation to a concrete situation and recognized threat. This information is used to reduce security vulnerabilities in the areas that will have a high impact if their security is breached. The assessment results in the development of a set of security control and mitigation strategies that will form the core of the system security requirements.

These security requirements become part of the same development process used for all other requirements. Detailed at the outset, the security requirements are then traced through the design, coding, and testing stages to ensure fulfillment of the initial requirements. These linkages form documentation that demonstrates how the final system meets the security objectives laid down at the beginning.

CWE: Not a coding standard

CWE is a “do not get caught by” list and is not an actual coding standard. However, coding standards can be used in complement to ensure that the CWE issues are not present in a project. Compliance with these standards helps ensure that project security goals are achieved, especially as many security issues result directly from the coding errors that they target. Additionally, compliance with a recognized standard helps to demonstrate that contractual security obligations have been met.

Compliance with the chosen coding standard (or standards) should be a formal process (ideally tool-assisted, but manual is also possible), as it is virtually impossible for a programming team to follow all the rules and guidelines throughout the entire code base.

Adherence to the standards is a useful metric to apply when determining code quality.

Static and dynamic testing should be considered essential practices. Static analysis tools confirming CWE compatibility systematically enforce the standard across all code. Dynamic analysis assures that the code does not contain runtime errors, including those that could be exploited to compromise security.

Traceability matters

If a claim is to be made that a system complies with a security standard like CWE, then evidence must be provided to support that claim. Traceability [which makes it possible to show which test result(s) prove that a particular security requirement has been met] from requirements to the design, verification plan, and resulting test artifacts can be used to support such a claim.

Figure 2 illustrates how traceability can be linked back to requirements, and the related test cases. Such graphical representation makes it easy for developers to immediately spot unnecessary functionality (code with no requirement), unimplemented requirements, and failed or missing test cases.

Moving forward

Adoption of a security standard that targets the CWE vulnerabilities allows security quality attributes to be specified for a project. Incorporation of security attributes into the system requirements means that they can then be measured and verified before a system is integrated into a network, significantly reducing the potential for in-the-field exploitation of latent security vulnerabilities by the enemy.

The use of a qualified and well-integrated Application Life-cycle Management (ALM) tool to automate testing, collation of process artifacts, and requirements traceability dramatically reduces the resources needed to produce the documentation required by certification bodies. It minimizes the workload for developers and allows managers to efficiently track progress.

It is clear that system developers need to rethink their assumptions if net-centric warfare systems are to be secured against information leaks and remote manipulation. Leveraging the knowledge contained within CWE and choosing to develop and test software with the aid of CWE-aware tools represent significant steps forward. Companies that incorporate CWE and embark on a process of continual improvement help ensure that only dependable, trustworthy, extensible, and secure systems are delivered to those who put their lives on the line to protect our countries.

The CWE list and further information on CWE are available on the MITRE website at http://cwe.mitre.org.

Chris Tapp is a Field Applications Engineer at LDRA with more than 20 years’ experience in embedded software development. He graduated from the University of Durham in 1987 and has spent most of his career working within the automotive, industrial control, and information technology industries, mainly as a self-employed consultant. He is chairman of the MISRA C++ working group and an active member of the MISRA C working group. He joined LDRA in 2007 and specializes in programming standards. Chris may be reached at chris.tapp@ldra.com.

LDRA 650-583-8880 www.ldra.com

]]> http://tech.opensystemsmedia.com/safety-and-security/2012/09/net-centric-security-and-cwe/feed/ 0 http://www.embedded-computing.com/articles/id/?5742 http://www.embedded-computing.com/articles/id/?5742#comments Wed, 15 Aug 2012 15:00:00 +0000 Jennifer Hesse, Editor, OpenSystems Media http://tech.opensystemsmedia.com/safety-and-security/?guid=c14ec65a520168846c7fcac078e07cb0

IDC is predicting that 15 billion intelligent devices will be connected to the Internet by 2015. This explosion in connected embedded devices has spawned a new generation of hackers targeting mobile devices, automobiles, medical equipment, and other systems. Alan discusses what these latest security threats to embedded devices look like and what steps companies should take to protect their devices from attacks launched via the Internet.

GRAU: We are seeing a surge in attacks against embedded devices. Attacks range from simple automated probes to sophisticated attacks targeting specific features of the embedded devices.

IP and Web attacks that have long been used against enterprise networks and Web servers are now being used to attack embedded devices. Hackers have compromised medical devices, reprogrammed printers, and even hacked antitheft and vehicle control systems in cars. The list of possible attacks is limited only by the creativity of hackers.

A few other common threats are dictionary attacks, where hackers attempt to log in and gain control of the embedded device using weak or default passwords, and insider attacks, where disgruntled employees steal passwords and sell them to hackers.

ECD: What steps can designers take to protect their devices from these attacks?

GRAU: Security needs to be considered from the very beginning of the design phase. Engineers must assess the possible attack vectors available to hackers. Each interface provided by the device is a potential attack vector for hackers. Wi-Fi, Ethernet, Bluetooth, serial communication, and even debug ports have been targeted by hackers. Once the risks are determined, engineers can begin designing security measures for the identified risks.

Many embedded devices include security protocols such as Secure Shell (SSH) or Secure Socket Layer (SSL) to ensure secure communication with the device. While that is an important step, it is not sufficient. A firewall is the critical layer of security that is missing in most embedded devices. A firewall allows the creation of policies that define and enforce what communication is allowed with the device. The policies define, at a minimum, with whom the device communicates, which protocols are supported, and which ports are open. An embedded firewall is integrated into the communication stack and blocks packets at the lowest layers of the stack. By enforcing communication policies, many attacks are blocked before a connection is even established.

Consider a Supervisory Control and Data Acquisition (SCADA) controller that incorporates the Icon Labs Floodgate firewall and is configured with communication policies that define a set of trusted senders and block all ports and protocols not used by the device (see Figure 1). If hackers attack the device, they will be blocked because the communication is not originating from a trusted sender. Even if hackers steal passwords from an insider, they will not be able to log in to the device because they are not trusted senders. The firewall will block packets at the IP layer before a log-in is attempted.

ECD: How difficult is it to port security software to an embedded system? What are the impacts on performance and memory size?

GRAU: Most embedded systems require security software that is designed for use with the specific requirements of embedded systems in mind. Security systems for Linux or Windows are generally large, slow, and not easily ported. A product like Floodgate that is designed to be small, fast, and portable between Real-Time Operating Systems (RTOSs), on the other hand, can be easily ported between embedded systems. Floodgate has been ported to devices as small as 8-bit MCUs and can be configured to as little as 15 KB of RAM and 15 KB of ROM.

Performance is another reason to use security software designed for embedded systems. These solutions will be faster and use fewer memory resources than desktop solutions.

ECD: If embedded devices are to be deployed on a closed network, should designers consider security?

GRAU: Security needs to be designed into all embedded devices, regardless of how they will be deployed initially. Many devices originally designed for use on closed systems are later repurposed, and subsequently may be deployed on open networks. For example, many legacy SCADA systems were designed without security because they were built solely for use on closed networks. Today, many of these devices are connected to the Internet and have few, if any, security features to protect them from hackers. The result is scary; embedded devices are serving critical functions in our infrastructure and remain easy targets for hackers.

Stuxnet showed us that closed networks can still be compromised. Hackers can penetrate the network, or, as with Stuxnet, viruses, worms, and other attacks can be introduced through USB drives and other physical media. In addition, there is always the risk of insider attacks. Someone with authorized access to the network could launch an attack against devices on the network.

Enterprise networks are designed using multiple layers of security. Network firewalls protect against attacks from the Internet, security protocols protect communication, and endpoint firewalls and antivirus/antimalware software protect individual nodes on the network. Embedded devices need to follow a similar approach, adding a firewall to the device to provide an extra layer of protection, regardless of how the device will be deployed at the outset.

ECD: Are the built-in security provisions in OSs such as Android adequate for embedded applications?

GRAU: As we all know, Android runs on the Linux OS. However, many people are surprised to learn that in various Android distributions, some Linux security features have been stripped out to reduce memory usage. For example, support for packet filtering using iptables is not included in many Android distributions, meaning that firewall support is not included. So Android may not be as secure as many people believe it to be.

Security is about risk management. Hackers will break into a device or network for many reasons. Some are politically or financially motivated. Others just want to prove they can do it. The number and sophistication of attacks continue to rise. Any device with a network interface, even a device on a private network, is a potential target for attack. If the device has a Wi-Fi interface or is connected to the Internet, it almost certainly will be attacked. Devices with a Web interface will likely be targeted by automated Web hacking tools. Reports estimate that between 20 to 30 percent of all Web traffic is from hackers or other malicious packets.

As engineers should assume their devices will be attacked, they face a number of questions. How difficult can they make it for hackers to breach the device? What security measures can be put into place, and what are the costs and benefits of each of these? Five years ago security protocols such as SSH and SSL were considered enough to protect an embedded device from hackers. They are no longer sufficient. An embedded firewall is a simple and effective way to protect embedded devices from hackers capitalizing on the openness of the Internet.

Alan Grau is president and cofounder of Icon Labs.

Icon Labs alan.grau@icon-labs.com www.iconlabs.com

Follow: YouTube

]]> http://tech.opensystemsmedia.com/safety-and-security/2012/08/the-missing-layer-of-security-in-connected-embedded-devices-qa-with-alan-grau-president-and-cofounder-icon-labs/feed/ 0 http://www.mil-embedded.com/articles/id/?5718 http://www.mil-embedded.com/articles/id/?5718#comments Fri, 27 Jul 2012 15:00:00 +0000 John McHale, Editorial Director http://tech.opensystemsmedia.com/safety-and-security/?guid=03777e706d8de1a6921f4cf8599c7363

Federal Aviation Administration (FAA) officials have started clearing the way for UASs to enter national airspace, causing a stir about how to assure they are just as safe and secure as manned aircraft.

Military Unmanned Aircraft System (UAS) designers for the most part have been able to design their aircraft free of Federal Aviation Administration (FAA) regulations for safety certification and other design regulations.

The FAA has become more open to UASs flying in the national airspace. The agency requires that “federal, state, and local government entities must obtain an FAA Certificate of Waiver or Authorization (COA) before flying a UAS in the national airspace. The FAA is also required to streamline that process. Meanwhile, some law enforcement and military aircraft already are flying in civilian space.

“At the FAA we required a chase plane when a UAS was flying in controlled airspace,” says Bobby Sturgell, Senior Vice President of Washington Operations at Rockwell Collins in Cedar Rapids, Iowa and former Administrator of the FAA. “Once the UAS entered restricted space – typically military controlled – the chase plane was not required while it flew in restricted airspace. What the FAA also will do is dedicate an air traffic controller to watch that UAS while it flies over civilian airspace.”

“There also are specific rules for smaller UASs – dubbed Class 1 – such as the tiny robotic helicopters that weigh only a pound or two or three,” says George Romanski, President and CEO of Verocel in Westford, MA. These are just starting to enter service for applications such as law enforcement and users “have to ask FAA permission and comply with various other rules such as they can only fly less than 400 feet high and have to maintain a line of sight and be more than 5 miles from the nearest airports.”

“The concern with UASs in the national airspace revolves around what happens when something goes wrong in the aircraft or its resident airspace and there are no pilots onboard to handle the situation,” says Chip Downing, Senior Director, Business Development, Aerospace & Defense at Wind River Systems in Alameda, CA. “If you have just one person, i.e., a military pilot, in an aircraft, he can avoid danger by manually flying the aircraft away from populated areas. With unmanned aircraft, it is more critical to have autonomous systems in place based upon a reliable safety and security foundation, which will enable the aircraft to react safely when things go wrong. Unmanned aircraft will need to have higher levels of response in emergency situations.”

Later this year FAA officials are expected to release a proposed rule that will establish procedures, policies, and standards for UAS users, according to the FAA website. In the meantime, there is still concern about how to get UASs to be equal with manned aircraft when it comes to operating safely in civilian airspace.

Safety certification for UASs

Rules are also the biggest question mark when it comes to safety certification of UAS flight software. The expertise is out there, but how, when, and where UASs need to comply is still murky.

“The biggest challenge to work out is what the rules are,” Romanski says. “Today they are not clear. We know the rules for manned aircraft so we want equivalent safety for unmanned aircraft. However, what does that mean? We still need to work out the rules.”

“The certification issues regarding DO-178B, DO-254, etc., will play out in different ways for different classes of aircraft,” Sturgell says. “The transport category will have the highest levels of certification requirements, while the ultra-light and experimental aircraft have a lot fewer layers of certification. Operational requirements are what will drive certification levels in the long run. For example, if an experimental UAS is flying over populated areas, it will need to have higher levels of certification than one that does not.

“When you get to bigger and more sophisticated UASs such as the Predator, their communication and electrical systems have much redundancy built in for reliability and safety,” Sturgell continues. “In that way, they kind of mirror business and air transport aircraft. The certification efforts in these vehicles are consistent with the way manned aircraft go about ensuring certification and reliability.”

Economics are also an issue. “Budgets are an issue for Office of the Secretary of Defense (OSD) personnel when it comes to adding safety and security certification for UASs,” says David Sequino, Vice President and General Manager of the INTEGRITY Security Services business unit at Green Hills Software in Santa Barbara, CA. “They go through their budgets and know that everybody wants it, but also know that there is no money to spend on it right now.”

“Eventually every component will undergo safety analysis with a category level worked out for each component,” Romanski says. “If a failure could cause a catastrophic event, some components will need to be certified to Level A, while others may be able to be certified to lower levels as they are in manned aircraft, where every component is certified to its prescribed level. To get where we want to go, we need to make sure we have a safe and secure platform where we can compose a system made up of certified components. Even though we don’t know all the components, we do know that the platform will have to have a safe and secure foundation.”

“We have a lot of experience with DO-178B, and no deaths have been attributed to software using this guidance document,” Romanski continues. “The FAA mandates that you do safety analysis and work out [the] level and certify to that level. The problem with UASs is that many currently flying were produced quickly to serve a purpose in theater and not required to meet DO-178B-type processes. Now if they are flying in national airspace, they will have to follow the same rules as the rest and government [will] take the time to make sure the software and hardware meets the proper safety certification levels. For UASs, the Ground Control Station (GCS) is an extension of the cockpit and must have equivalent levels of safety; in other words, a UAS flown on a Windows operating system probably won’t be compliant. A fault in GCS software could quite easily send bad data into the aircraft, which could result in catastrophic failure.”

“Most commercial aircraft already have very sophisticated autopilot controls, so the next steps for UASs are gaining public trust and having a reliable safety and security record for the software and hardware flying the aircraft,” Downing says.

Security

“In addition to safety, security is also paramount for military UAS operations and for when UASs enter civilian airspace,” Sequino says. “The data links need to be encrypted to and from the ground control station to the UAS so there are not more security and reliability problems. They need to get 99.999 percent reliability with the data links. A lot of ground stations today are not secure.”

“The National Security Agency (NSA) typically recommends that Suite B security standards be applied for defining the cryptography used in all government classified communications,” Sequino continues. The Green Hills ISS business unit offers an embedded cryptographic product – ISS Security Solutions – which consists of Suite B-Compliant Security Protocol Toolkits and a Device Lifecycle Management (DLM) system. (For more information, visit www.ghs.com.) “We’ve got some customers implementing the solution and are working on an ISS solution for the Army for UAS programs.”

Security is also a key part of the DoD’s effort to create a universal control station architecture for UASs – the UAS Control Segment (UCS) (www.ucsarchitecture.org/page/home).

“They are still in negotiations on what types of security levels and other standards will be used, but the Multiple Independent Levels of Security (MILS) approach is one being looked at,” Romanski says. “One of the objectives of UCS is to have the ability to provide mixed levels of security and to make it also dynamic. Video feeds coming through to the analyst observing video at the ground station most of the time are benign. However, once he sees something that is important, it now becomes secure information. So he presses a button to tag the data as top secret, then he distributes it around the proper channels where it can only be decrypted by those with the proper clearance. There is a fair amount of work still to be done in this area.”

FACE can help

Compliance with safety and security regulations could go more smoothly and cost effectively by getting the UAS community to adopt common standards. They could take a hint from the military avionics community, which is doing just that within the Future Airborne Capability Environment (FACE) Consortium.

“I’m seeing crossing over between FACE and the UAS community in the military,” Sequino says. “FACE is classic avionics, and now the FACE Consortium really has its act together and [is] telling the UAS community to just adopt FACE. It is a matter of changing the culture and a little bit like herding cats to get the different vendors, OSD, and various program offices to move away from using competing standards and get everyone on the same page. They are beginning to converge, but it is a long process.”

UCS is also being built along a similar philosophy to FACE. “With UCS, the government is trying to encourage an ecosystem of suppliers as these services are published and find what interfaces exist that you can get from different suppliers,” Romanski says. “If there is not a service available, the government can pay someone to supply one and get it put into the repository. These services then can be sold and plugged in the new type of model the government wants. It is a different type of business model, an open business model that fosters innovation and grows the market so people can supply components to the UCS architecture.”

FACE, with more than “40 members from both industry and government, has developed safety and security operating system profiles for military avionics systems,” Downing says. “The FACE technical standard is an open, modular, multivendor software environment enabling portability and reuse of software components across multiple programs and platforms. Next-generation military avionics platforms will require a common compute platform based upon open industry architectures to enable portability across aircraft types. Because these platforms will be sharing a common infrastructure, FACE systems should be able to lower the cost and risk of achieving safety and security objectives.”

“Common core platforms such as those based upon ARINC 653 have been very effective in Integrated Modular Avionics (IMA) in commercial aircraft, but these advancements have simply not occurred in military avionics systems,” Downing says. Wind River’s ARINC 653 product, VxWorks 653, has enabled IMAs on 55 different aircraft. (For more information visit, www.windriver.com.)

]]> http://tech.opensystemsmedia.com/safety-and-security/2012/07/certifying-and-securing-uass-for-civilian-airspace-is-more-about-rules-than-technology/feed/ 0 http://www.compactpci-systems.com/articles/id/?5594 http://www.compactpci-systems.com/articles/id/?5594#comments Sun, 25 Mar 2012 15:00:00 +0000 David Pursley, Kontron http://tech.opensystemsmedia.com/safety-and-security/?guid=878a70a544b6a227097daa715976abe2

Network-centric architectures are now a prevalent requirement in today’s military systems, such as those that manage communications across multiple security enclaves. Even applications that aren’t seemingly network centric, such as radar beamforming and processing, often are implemented using network-centric COTS architectures with multiple compute nodes networked together to essentially implement a mini-supercomputer. At the same time, SWaP reduction is always desired, if not required, especially for aerial and unmanned platforms.

MicroTCA’s switched serial network architecture and small form factor make it a logical option for these types of applications. Growth of MicroTCA in military deployments has been fueled by additional MicroTCA specifications that add the ruggedness required for harsh deployments. Conduction-cooled and rugged air-cooled specifications have been ratified by PICMG, and these types of MicroTCA systems are being deployed in military environments worldwide. Looking forward, another rugged MicroTCA specification will be available later this year that allows higher power modules to be used in these rugged environments.

Meeting the need for high bandwidth and high-end processing in a standards-based small form factor is attractive to military designers seeking advantages in size, scalability, and communications bandwidth. These same demands are typical for telecommunications designers. In fact, many of the demands typical of a deployed telecommunications system are similar to the network-centric systems being used in military settings, making MicroTCA (“TCA” stands for “Telecommunications Computing Architecture”) an effective mission-critical platform that offers high communications bandwidth, high processing capacity, and high reliability.

Making MicroTCA tick

The heart of MicroTCA is the Advanced Mezzanine Card (AMC) payload board, a 2U circuit card Assembly with 21 high-speed serial connections to the backplane, each capable of delivering bandwidth of at least 2.5 Gbps. A single system can include up to 12 AMCs communicating with each other via the high-speed serial links, typically implementing a combination of Gigabit Ethernet (GbE), 10 GbE, PCI Express, Serial RapidIO, SATA and/or SAS connections. MicroTCA also defines a standard profile for how each of the 21 serial connections (“ports”) should be used if implemented. For example, ports 0 and 1 are typically GbE for the control plane, while ports 4-11 can be used as x1, x2, x4, or x8 fat pipes for data plane communications. Figure 1 shows the port mapping for a typical processor AMC SBC.

Communications topologies can be a combination of star, dual star, or point-to-point. The star or dual star topology is typical for the control plane. A system’s communications bandwidth capacity can range from 40 Gbps to greater than 1 TBps, depending on how the system is implemented. An example topology including both star and point-to-point topologies is shown in Figure 2.

Making MicroTCA rugged

Even the telecom-focused version of MicroTCA has some rugged underpinnings. MicroTCA boards and systems by specification must allow compliance to Network Equipment Building Systems (NEBS) Level 3 requirements, which validates thermal margins, fire suppression, emissions, and the ability to remain operational during a severe earthquake. NEBS-certified MicroTCA boards and systems are validated to withstand extreme heat, humidity, altitude, and up to Zone 4 earthquake shock (7.0 Richter scale and higher), as well as an extensive range of other extreme environmental conditions. Being smaller than a 3U CompactPCI or VPX board, an AMC’s small size helps in rugged environments. Smaller size means less bending and flexing under shock and vibration loads.

Further growth of MicroTCA in military deployments is fueled by add-on specifications that make the most of its rugged family tree. Certified by PICMG, these new specifications for rugged air-cooled and conduction-cooled derivatives leverage the ANSI/VITA 47 specification and define the environments in which these certified boards will perform.

For example, in 2011 PICMG announced the adoption of the Hardened Conduction Cooled MicroTCA (MTCA.3) specification. This specification defines the requirements for systems needing to meet more stringent levels of temperature, shock, vibration, and other environmental conditions, addressing military and some commercial systems in sealed environments with no airflow at all. MTCA.3 does this by placing the AMCs inside of a metal “clamshell,” with wedge locks to stiffen the board and also provide a conductive path for thermal dissipation through the chassis. Typical applications include military systems hard mounted to a mobile platform (an ATR is one example), or military communications systems deployed outdoors.

Similarly, MTCA.1 specifies a rugged air-cooled flavor of MicroTCA. Currently underway is MTCA.2, which employs a novel hybrid air- and conduction-cooling approach to maximize the amount of heat that can be effectively dissipated. The result will mean that systems in higher temperature environments will be able to more effectively use higher power modules.

There may be multiple MTCA derivatives that answer a system architect’s long list of design issues. With each of these related specifications, the goal is to reuse the exact same AMC printed circuit board and as much of the MTCA base specification infrastructure as possible. Figure 3 shows an overview of the PICMG MicroTCA specifications.

MicroTCA for net-centric applications

When it comes to network-centric applications, MicroTCA’s telecom heritage makes it a logical COTS architecture choice. For example, when considering a secure network application, system designers must first determine the level of inbound and outbound data, as well as what tasks must be performed while the data is moving through the network. Once the performance environment indicates that data processing is approaching the demands of 10 GbE, MicroTCA becomes an ideal option. An example of one such system is the Space Network Ground Segment Sustainment (SGSS) project, an effort to modernize the ground segment of the satellite communications network used by the National Aeronautics and Space Administration (NASA).

SGSS relies on satellites and spacecraft in low-Earth orbit to continuously relay data to ground stations in White Sands, New Mexico and in Guam. Data is relayed through the Tracking and Data Relay Satellite System (TDRSS) network, the central focus of the SGSS initiative. Modernization will improve situational awareness for TDRSS network operators by upgrading computing and signal processing equipment, as well as enhancing reliability and maintainability, improving efficiency, and reducing operations and sustainment costs.

MicroTCA in unmanned applications

While systems deployed on most military platforms struggle with SWaP (Size, Weight, and Power) requirements, SWaP comes to the forefront most when designing systems for unmanned applications.

For example, consider an unmanned platform for ISR (Intelligence, Surveillance, and Reconnaissance). These platforms are typically performing computationally intensive tasks onboard such as beamforming and filtering to sift through multiple sensor streams, which are typically coming in at less than 1 Gbps. Although the network bandwidth alone would not necessitate the use of MicroTCA, the compute payload can be significantly smaller and lighter when using MicroTCA as compared to a 6U or even 3U COTS architecture. This has led to the adoption of rugged MicroTCA in unmanned platforms.

The future of MicroTCA

MicroTCA has proven itself as a military computing architecture, and will only become more relevant as the move toward secure network communications and higher bandwidth data grows steadily throughout military operations. Military leaders are under constant pressure to choose the right technology path – investing in the future versus maintaining and expanding current systems. MicroTCA’s high connectivity in a small footprint ensures that its adoption will continue to grow in this space, as do its newer rugged variants.

David Pursley is an Applications Engineer with Kontron, responsible for business development of the MicroTCA, AdvancedTCA, CompactPCI, and ThinkIO product lines in North America.

Kontron

david.pursley@us.kontron.com

www.kontron.com

]]> http://tech.opensystemsmedia.com/safety-and-security/2012/03/swap-gains-enlist-microtca-in-the-military/feed/ 0 http://www.compactpci-systems.com/articles/id/?5590 http://www.compactpci-systems.com/articles/id/?5590#comments Thu, 22 Mar 2012 15:00:00 +0000 John Long, RadiSys http://tech.opensystemsmedia.com/safety-and-security/?guid=9310a79e434efb8239aeeea87a66eb94

Entire Aerospace and Defense (A&D) networks, from base stations to the core, are being consolidated into small, ruggedized communications platforms that provide the ability for an entire network to be picked up and moved. Femtocells are now being found on Humvees, ships, and even carried in a soldier’s pack, providing unparalleled communications right where it’s needed most. Compact network cores can fit in 2U and 5U ATCA chassis and can easily be transported. However, these ultra-portable cellular networks require a combination of hardware and optimized software that meets specialized Size, Weight, and Power (SWaP) requirements for next-generation network-centric warfare.

Our military networks have been lacking agility and reliability in comparison to the commercial cellular devices the enemy has at its disposal. Efforts in Iraq and Afghanistan have exposed this gap between proprietary radio communications and commercial cellular networks. Smart phones and cellular networks are allowing an unprecedented level of situational awareness, giving soldiers a significant advantage in the palm of their hand, but cellular networks can be difficult to deploy from a military transport vehicle, such as a Humvee or destroyer, because they tend to be very large, heavy, bulky, and power-hungry. In addition, the network nodes are too cumbersome to be portable, lack the ability to deliver ad-hoc communications, and are not easily customizable to deliver the reliability and security that the military requires.

The military wants to take advantage of proven commercial cellular technology and the associated economies of scale for the next-generation mobile communications systems. However, it cannot simply re-use this technology as is. These portable networks require particular architectures and specific hardware and software elements to meet the specific requirements, such as Size, Weight, and Power (SWaP), of network-centric warfare. This is leading to tremendous changes in how the military implements its wartime communications networks as it moves toward adoption of standards-based cellular technology with 3G today and LTE in the future.

Transitioning from proprietary solutions to COTS hardware

The telecom industry has been steadily moving from proprietary to standards-based designs due to refined standards and the development of a healthy supplier ecosystem. As telecom companies transition from proprietary to standards-based architectures, some are now saving resources and capital by outsourcing critical design and validation tasks. By using Commercial Off-The-Shelf (COTS) hardware as opposed to designing a computing system in-house, Network Equipment Providers (NEPs) are now in a position to avoid hardware design altogether and can focus development efforts on software-based value-add features. NEPs are finding that equipment based on open standards architectures typically costs less to deploy because it makes sound economic sense to design scalable platforms that can be employed across multiple applications (Figure 1).

Open standards-based COTS solutions not only address many issues facing equipment manufacturers, they also meet the needs of military programs. Military and aerospace system designers, who are in the process of replacing proprietary architectures, are seeking COTS technologies that competently accommodate the toughest environmental conditions (such as extreme temperatures) yet are efficient enough to meet application needs for power, performance, and heat dissipation. For example, the military is now looking outside of its engineering ranks to guarantee that its components are rigorously temperature tested. Many COTS technologies were designed to both withstand the rigors of military environments, and offer developers readily available, interoperable hardware that reduces design effort.

Putting the pieces together

Next-generation network-centric warfare requires ultra-portable cellular networks that squeeze the entire system, from base station to the core, into a small, ruggedized platform that can be picked up and moved, or even carried in a soldier’s pack (Figure 2). COTS technologies have made tremendous progress in satisfying the size, ruggedness, and performance requirements for a wide range of Aerospace and Defense (A&D) applications.

When combined, COTS technologies such as AdvancedTCA (ATCA) and COM Express provide a complete, deployment-ready solution with the flexibility for design and software enhancements. Together they support a network of networks in a manner that is standards compliant, providing a high level of interoperability and scalability. Many protocols can be consolidated onto one platform of nearly any size to accommodate a variety of missions, with base stations ranging in size from a big box to several smaller distributed units.

No matter the computing technology, year after year designers try to find ways to increase performance. Successfully integrating a high level of computing power basically comes down to board size, board power consumption, and backplane technology. In all of these areas, ATCA has a significant advantage. ATCA is a bladed platform that easily scales features and performance by adding blades that support new applications or more computing power. With its roots in telecom, ATCA was designed to maximize serviceability and availability, leveraging hot-swappable components and redundancy (for example boards, switches, fans, and power entry modules). In the field, an ATCA chassis is powered by stepping up the military vehicle battery voltage to 48 volts, thus avoiding the 120-volt (AC) supply required by a rackmount server. Yet, to attain the maximum benefits from ATCA equipment, manufacturers have realized it takes a combination of telecom and ATCA expertise to bring all of the elements together — chassis, blades, operating system, middleware, and platform management software — into a cohesive platform.

Boosting performance is especially challenging for designers of small form factor systems who face stringent space and power constraints. It’s also difficult to keep up with the design churn associated with implementing new processor generations and increasingly complex design rules. As a result, military system developers are turning to COM Express boards, which remove the processor, chipset, and memory from the rest of the design. For example, for the purpose of reducing size and cost, a leading provider of military mobile telecommunications technology and software development completely revamped its system architecture using COM Express, and now the core network is the size of a shoebox and one-tenth the cost of other available solutions.

The case for small cells in military applications

Small cells provide unparalleled communications right where it’s needed most without adding extra weight or taking up a lot of space. As opposed to a traditional macrocell on a hilltop or a tall tower, a small cell is a wireless base station that is portable and transmits at very low power. Small cells typically use an IP broadband connection (such as cable, DSL, or fiber) for backhaul and eliminate the need for dual-mode handsets, as virtually any existing wireless handset should work seamlessly with a small cell offered by the carrier.

A wireless equipment manufacturer recently set out to design a flexible LTE network solution that could scale from small to large networks to serve U.S. state and local governments seeking to improve public safety. Increasing capacity had to be as simple as adding processing blades to the chassis and activating additional subscriber licenses, while minimizing SWaP was essential for supporting military or disaster response applications in which the wireless network may need to be transported via van or military Humvee. For customers with existing mobile infrastructure, the solution required the flexibility to make use of legacy equipment. To meet its objectives, the equipment manufacturer developed an Evolved Packet Core (EPC) that is available in different hardware configurations, making it a highly scalable and cost-effective solution. The EPC ships in either a 2- or 14-slot ATCA chassis from Radisys, running the full complement of Trillium LTE protocol software including open interfaces for integrating external network elements.

But is it secure?

Commercial cellular networks have built-in security and integrity protection features. These, however, are being modified for military applications. Existing features that can be customized include:

1.  Air interface ciphering – In commercial networks this is based on the Advanced Encryption Standard (AES) and KASUMI and SNOW 3G algorithms, but can be modified to use any defense-grade encryption approach.

2.  Integrity protection – Mobility and session state information is encrypted and decrypted in the core of the network leveraging commercial-grade algorithms, which may be customized for military requirements.

The ATCA platform enables a robust telecom security gateway that offers world-class security features with multi-gigabit performance to secure the backhaul capabilities — the infrastructure for connecting cell sites to the core network. Furthermore, the COM Express combination of Intel Active Management Technology (Intel AMT) and Trusted Platform Management (TPM) ensures remote access transactions are safe and secure. In addition, since small cells are portable and not left in the same spot for long periods of time, they are less vulnerable. However, many NEPs are also addressing security through protocols. For example, Radisys provides the COTS solutions for mobile infrastructure and the expertise needed to customize the solutions based on SWaP constraints, while NEPs bring the specific insight needed to wrap A&D security features around the standard offering.

Warfighters need more situational awareness on the battlefield and better communications back to the command center. Adoption of commercial standards-defined cellular technology solves the agility, reliability, and cost challenges, but does not deliver an ultra-mobile solution enabling ad-hoc network roll-out and the network of networks concept central to next-generation network-centric warfare. These ultra-portable cellular networks require a combination of hardware and optimized software that meets specialized security and SWaP requirements. Modular, ruggedized computers combined with a customizable carrier board provide COTS-based hardware ideal for ultra-portable warfighter communications applications and are specifically developed to support the extreme conditions in the field. The addition of small cell software solutions provides unparalleled communications right where it’s needed most, without extra weight or bulk.

John Long is a product line manager at Radisys, with a focus on ATCA single board computers and storage.

Radisys

www.radisys.com

john.long@radisys.com