Articles

Developing a Secure COTS-based Trusted Computing System: An Introduction

July 25, 2018 | BY: David Sheets, Steve Edwards

Published in Military & Aerospace

Security and trusted computing, at the end of the day, really are all about the system. While the pieces and parts, such as the individual modules, operating system, and boot software, all are important, system security is not an additive process; it can’t simply be bolted-on to make the system secure.

The designer must look at each system element and understand how they work together. If a single discrete element of the system is insecure, it is not possible for the designer to claim confidently that the entire system is secure. You need to know how each system element integrates with the rest, what interfaces are available to those elements, and how each element communicates with the other parts of the system.

The systems designer must make all efforts possible to eliminate any risk of inadvertently providing an insecure port of entry into the system that makes it vulnerable to malicious attack.

Defining security requirements

Frequently, designers can meet system-level security requirements in several different ways. For example, to resist a particular malicious attack targeting one weak hardware component, the designer could use either a more resistant component or implement a distributed system approach, presenting the attacker with the far more difficult task of targeting multiple components at the same time.

The systems designer must understand how he can implement different system-level architectures to address the same security requirements. Designers also must understand the tradeoffs of each architectural option. Different program managers will want to make different choices based on their unique priorities and key performance parameters.

Designers can achieve some security protections either at the system or the module level. While that decision already may be established, sometimes cost, schedule, or the limitations of a particular component may drive the designer's decision of what level to implement a protection.

Interfaces and data communications

Another important topic for system level security is how to set up interfaces, within and between systems. The designer must consider the best way to design communication pathways to ensure that the system handles data in transit appropriately.

The designer must make decisions about intra-system communications between the individual modules and how to protect that data. Where interfaces send data also is important, because intra-system communications often have very different security considerations from inter-system communication.

What’s more, the ways in which the system uses those interfaces, whether during operation or in maintenance activities, may raise additional considerations. The designer must perform an appropriate level of validation or authentication of data prior to its acceptance for processing at each different levels of integration. That means the designer must make choices about what sort of access control or authentication capability is necessary at the I/O boundary.

Working with COTS vendors

Security requirements flow down either from the customer or the program office to the systems designer to provide specifics for anti-tamper or cyber security protections. The designer must decompose those requirements to define what each one means for the system, and for each of the components within it.

Sometimes designers can meet for anti-tamper and cyber security with one solution. In other cases the designer must resolve the competing requirements of different domains. Security requirements next flow down to the COTS vendors to implement any necessary mitigating technologies.

In an ideal world, one trusted and capable vendor would handle all components to optimize security. Yet security challenges often stem from using modules from different suppliers. Frequently, the system integrator must deal with multiple COTS vendors, but not every COTS vendor can support the same levels of trusted computing capabilities, so the designer also must weigh supply chain management issues and their COTS vendor’s ability to meet the system's needs.

Performance and testing

The designer also must address and understand the performance aspects of security implementations, because secure networking, encryption, and authentication can affect nominal throughput for booting, processing data, networking data, and system latency; the designer must consider all of a system’s key performance parameters.

The impact of trusted computing on performance will vary from system to system, and may require tradeoffs between security and performance. Size, weight, and power (SWaP) limitations also can play a part in weighing tradeoffs. For new “bleeding edge” system designs the tradeoff might be between implementing security (and/or other overhead) and meeting the mission requirements.

Testing for system-level security brings its own set of challenges. For some security implementations, the designer might need to classify pieces of a system, and test them in a classified laboratory. Afterward, when security is enabled, the system can be tested in an unclassified environment where the sensitive component can be integrated with additional elements of the system. The challenge is how to undertake the integration of classified and unclassified components in a way that’s cost-effective and ensures the ability to perform debugging in each set of environments effectively.

System security in the field

Maintaining and upgrading fielded systems is another area with potential implications for security. The designer has to make decisions about whether to allow software updates in the field, and if so, how to validate the software.

If one system module fails in the field, there must be a process to authenticate its replacement properly. When the system comes in to a maintenance depot for repair, it’s important to understand what parts of the system its maintenance ports can access.

Prior to a system’s deployment, the designer must decide how to manage security certificates and keys. The key management plan must be fully vetted, and include the ability to revoke keys to reduce the program’s long-term maintenance costs. These decisions should be made early in the program, since the choices will affect how they are designed into the system.

When to think about system security

It’s always easier to make decisions about trusted computing protections at the very beginning of system development; there is great value in discussing anti-tamper and cyber security at the earliest stages of system design. Security touches every element of the system. To add in needed “hooks” after a module or system is already designed often requires undoing a lot of previously undertaken and costly design work.

While requirements for security might not exist at the beginning of a program, the systems designer often can anticipate them for the future. It’s important for the systems integrator and his suppliers to discuss long-term expectations for security early on in the design stage.

Implementing trusted computing protections later in the design cycle can be expensive and wasteful, since all other system development must wait for the security approach to be chosen, and all the related implications that those decisions have on the rest of the system fully understood.

Read the full article here

 

David Sheets

Author’s Biography

David Sheets

Senior Principal Security Architect

David Sheets joined Curtiss-Wright in January 2018 as Security Architect. In this role David helps guide technology development and strategy on Anti-Tamper and Cyber Resiliency for Curtiss-Wright Defense Solutions products. David draws on 18 years of embedded engineering experience, including 10 years working on multiple US DoD programs architecting, implementing, and integrating security solutions. David has a Master of Science in Computer Science from Johns Hopkins University.

Author’s Biography

Steve Edwards

Director, Secure Embedded Solutions & Technical Fellow

Steve has over 25 years of experience in the embedded system industry. He managed and co-designed Curtiss-Wright’s first rugged multiprocessor and FPGA products and was involved in the architecture, management and evangelization of the industry’s first VPX products. Steve has Chaired the VITA 65 working group and currently leads Defense Solutions’ strategic initiative in Anti-Tamper and Cybersecurity. Steve has a Bachelor of Science in Electrical Engineering from Rutgers University.

Share This Article

  • Share on Linkedin
  • Share on Twitter
  • Share on Facebook
  • Share on Google+
Want to add a comment? Please login
Loading...
Connect With Curtiss-Wright Connect With Curtiss-Wright Connect With Curtiss-Wright
Sales

CONTACT SALES

Contact our sales team today to learn more about our products and services.

YOUR LOCATION

PRODUCT INFORMATION

Support

GET SUPPORT

Our support team can help answer your questions - contact us today.

REQUEST TYPE

SELECT BY

SELECT Topic