What if I can’t implement a security control?
Aviation Mission Planning Systems have come a long way in the past couple of decades. From home-baked Excel spreadsheets through to modern day systems such as Joint Mission Planning System (JMPS). As mission planners and crews became more reliant on computer systems the spotlight fell on the airworthiness of these systems.
These systems now also contain, store and process classified data and the focus has expanded to ensuring they have the appropriate security accreditation.
In Australia, military systems are required to implement a number of security controls in order to achieve security accreditation. These controls are listed in the Australian Government Information Security Manual (ISM), Controls Document. Those not familiar with information security will find this 334-page tome daunting. Often the first thing that causes system owners to shy away from compliance is the question “What if I can’t implement a control?”
Mission planning systems have usually been certified on a technical basis in a specific configuration (including the operating system) to ensure safety. This raises the question of whether implementing some technical controls to meet security accreditation requirements would invalidate the technical certification of the system.
For example, the ISM states:
Agencies must prevent unauthorised media from connecting to a system via the use of either:
- device access control or data loss prevention software
- physical means.
On most systems, you can rule out physical means as the hardware ports are actually used by the system for a valid purpose. The remaining choice is between device access control or data loss prevention software. I lean towards the “least touch” approach on the system. My opinion is that implementing device access control via group policy or the system registry has less of a footprint on the certified configuration than installing a 3rd party application.
The problem with doing things like locking down USB ports to specific approved devices via the registry is that it still changes the configuration. I’d recommend raising these changes with the technical certification authority and asking for approval. That can be a long process.
In the short term, flag the non-compliance in your Threat Risk Assessment and implement some alternative mitigation strategies to reduce the likelihood and/or impact of that vulnerability being exploited. You can then request dispensation from the Department Secretary or their delegate (dispensation for “should” controls are typically delegated).
In summary, an inability to implement a technical control does not mean your system can’t be accredited, so long as you have a solid business case to put forward explaining why and you make every effort to mitigate the threat via alternative means (where cost justified).
Pacific Aerospace Consulting have been working with a number of Defence clients on security accreditation of their stand-alone mission networks. We can help your organisation navigate the path to security accreditation without risking your technical certification.
