Multi Level Security Made Easy
Gerry Tyra - July 2015
Multi Level Security (MLS) is difficult, especially in an avionics environment. And usually, it isn't required or appropriate. However, I've identified two cases where MLS is needed and how to cope with this problem.
As has been discussed in other papers here, I am not a fan of MLS. I usually consider it to be an elephant sized solution for a mouse sized problem that frequently doesn't exist. After all, in a classified avionics system most everything needs to be able to communicate with everything else. So, solve your security issues with proper handling procedures and save a lot of development and validation pain.
That being said, there are two potential exceptions to this generalization: The “Black Box” payload and maintenance data.
The “Black Box” Payload:
It has been known to happen in the history of aviation that a special payload is brought to the flight line, with the orders to fly it. With some variation, you don't ask what it is, or why you are to fly it to the specified location. It just is.
Okay, so I'm over stating this a little. But it sets the right frame of reference.
Aside from weight an power, there are two critical factors on flying a package like this:
Is the “owner” of the package satisfied with the security of “their” data?
And does the connection of this system in any way impact the normal operation of the aircraft (aka, safety of flight)?
A working solution is setting on the shelf right now, Virtual Private Networks (VPN). The special payload may or may not have its own encryptors to keep the data secure. But, if the aircraft provides a VPN connection at the mount point, the payload's data can be routed any where on the airframe or over a communications link, and provides a high level of assurance that the data stream will not co-mingle with any aircraft data.
There is one caveat to this design. There needs to be a second port available to the payload through which it can obtain aircraft data (e.g., position, air data, etc.). This port requires a simple guard on it to effectively make it a one way data stream. This is not intended as an “approved” MLS data gateway. Its intention is to prevent a wayward payload from putting corrupting data onto the aircraft's network. This is about safety of flight, not security. Actually, it may be the opposite of security in that some of the data being passed to the payload may be highly classified. But this security issue has to be worked out between the operator's of the aircraft and the owner's of the payload.
When a brand new Nth generation aircraft pulls up on the tarmac after a highly classified mission, there is a lot of data on board that. The security of that data must be maintained until it is delivered to the intended, cleared recipients. But, from an operational standpoint, you want the ground crew to be able to immediately start servicing the aircraft. Waiting for an authorized download of the less classified maintenance data isn't acceptable.
Just to make the point explicitly, if you are operating only a couple classified aircraft, the operator should be able to afford an appropriately cleared ground crew. On the other hand, if you are operating a fleet of classified aircraft (think F-22, F-35 or B-2), most of the ground crew does not need to be fully cleared, so why take on the additional operational expense of doing so?
This is a real Multi Level Security problem. But there is a “cheap” solution. Using the revision tolerant messaging system discussed on this site, a single MLS gateway can be built and validated. In context, this gateway could become a commodity item, in the sense that it is looking for the same types of data from the same message definition, irrespective of the vehicle that is being used on.
This can be implemented in three steps:
A maintenance logger is instantiated on the classified side of the gateway. It is tasked to request, as a client, all of the desired data. This data will fall into two groups, that which will stay classified and that which will be downgraded. The classified data is sent to the appropriate storage device. The messages to be downgraded are checked to be in a revision that the gateway “knows”. If not, the message is repackaged in an appropriate revision.
The data, now in a known revision for a limited set of messages, is passed to the security gateway. The gateway verifies that the data matches the rule set and zeros fields as needed.
The downgraded message is then passed to the less classified storage device, which will be available to the ground crew immediately after landing.
This approach can significantly reduce the cost of maintaining the gateway. Assuming that the gateway is running from a set of libraries of rules, and given the revision methods discussed elsewhere, the libraries could be selected in a “Chinese Menu” manner to provide the appropriate data set for a given aircraft. Any surplus rules not required for the current aircraft will go unused.
By way of example, there would be at most a small number of engine performance base messages. There could be derived versions of a single base message to handle the differences between a turbo-prop, turbo-fan and a turbo-jet. Of this set, there would only be a couple active revisions flying. So, of six messages, only one would be used. But since each one has a unique identifier, the gateway will always be able to tell them apart.
Periodically, the libraries would be updated. Older, depreciated, revisions would be dropped and newer revisions would be added. However, if a library update were delayed, it would not impact the operation of the aircraft fleet, as the existing messages would still be providing the required data.
Security is important, but the arbitrary use of Multi Level Security is an extremely expensive way to solve the problem. The use of a VPN to isolate special payloads and a single, carefully crafted security gateway can overcome the security issues that still remain.