In 2015, the undersecretary of Defense issued a memorandum outlining the need to enforce open architecture practices for technology projects within the DoD. The underlying goal of the directive was to reduce cost and ensure that funds spent on projects did not result in solutions that were too fragile or difficult to maintain and expand.

Open architecture can bring a plug-and-play solution to complex systems. If one component or product in a system is obsolete, becomes too costly to maintain or has an issue, it can be swapped out for a more suitable or up-to-date component.

But as we know all too well, hackers are becoming increasingly adept at breaking into systems, and open architecture can leave an organization vulnerable to intrusion. System developers can no longer be sure that the systems they produce are secure just because the designs or implementations have been kept secret. (In fact, many organizations move forward on implementations even when presuming that their designs and implementation details may have been compromised.)

Where security risks occur

The challenge with open architecture lies in defining the standards and interfaces to which component pieces must conform. It can be tricky to clearly specify the interfaces between system components in an open and flexible manner, and this challenge gets more difficult as the complexity of the system grows.

Open architecture system interfaces must be descriptive enough for vendors or teams to build to, but not so restrictive that the system is limited and short-sighted once it has been completed.
In the case of large government systems, the architecture must also be shared or made public to allow for competitive bidding or in some cases collaborative development.

All of this information sharing allows wide scrutiny of the interfaces between components and makes them vulnerable to attack once their workings are understood.

Another possible security complication stems from one of the benefits of open architecture—the internal implementation of a component does not need to be known by an integrator. As long as a component matches the interface specification, it can be used in the system.

These components are sometimes called “black boxes” because the source code that powers them is not viewable. But because black boxes are opaque, inherent weaknesses or vulnerabilities may be introduced into the system once they are integrated.

Mitigating risks with encryption

Despite the inherent security risks associated with open architecture, organizations can deploy a “secure” open system by applying protection directly to the data it manages.

What’s the best way to protect your data?

In a word, encryption.

Encryption inherently applies protection to the data itself so even if perimeters are breached, data is still protected.

There are three steps to implementing an effective encryption strategy:

• Identify sensitive data. Inventory your data and determine what is sensitive. Sensitive data is data that an organization or individual needs to protect from unwanted disclosure. Examples of sensitive data are financial records, plans and strategy or on a more personal level, a social security number or credit card information. These are all things that in general would prove disruptive if they were released unintentionally. Check data-at-rest in storage, file servers, applications, databases and removable media. Check in both on-premises data centers and cloud and virtual environments. The process of identifying sensitive data starts with users and stakeholders. They have a unique perspective on why certain data is important and the impact its unintentional release would have on an organization, process or individual. The data users can also provide guidance on how and when the data they use is needed, which can help dictate the type and level of protection that the data warrants. Don’t lose sight of data that travels across networks. Data-in-motion is often sensitive too.
• Protect sensitive data. After identifying data in need of protection, encrypt the data to keep it safe. Effective encryption should meet two core requirements. It must provide access controls to define who and what can access your data. And it must protect data directly, applying protection and controls that sit with the data itself. To protect sensitive data at rest, you can use self-encrypting drives or apply encryption directly to the databases, application or files where the data resides. For data in motion, you need to encrypt the network itself, which can be done though high speed encryption.
• Manage the protection. In addition to employing strong encryption, it’s critical that your cryptographic keys are treated with the same level of care. For maximum security, dedicated hardware key management can protect sensitive cryptographic keys from attack. Cryptographic management solutions can be deployed in tandem with an encryption solution. By adding in a key manager, you can manage numerous keys, for numerous discrete operational needs, in a single environment.

The benefits of open architecture are undeniable, and the government is moving in that direction anyway. To gain the greatest benefit from this new direction, data encryption can ensure that open architecture doesn’t spell open season for hackers.

Lloyd Mitchell is VP of Engineering for SafeNet Assured Technologies. He can be reached via (Lloyd.mitchell@safenetat.com) email.

Copyright © 2024 Federal News Network. All rights reserved. This website is not intended for users located within the European Economic Area.