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.
Related: Trusted computing: application development, testing, and analysis for optimal security
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.
Related: Trusted computing hardware features for maintaining cyber security during operation
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.
Steve Edwards is technical fellow at the Curtiss-Wright Corp. Defense Solutions Division in Ashburn, Va. His email address is [email protected]. David Sheets is senior principal security architect at Curtiss-Wright Defense Solutions. Contact him by email at [email protected].
Ready to make a purchase? Search the Military & Aerospace Electronics Buyer's Guide for companies, new products, press releases, and videos
