Say “software security” to most people and they will think of hacked bank accounts, or attacks on corporate databases. Closer to home, consider the current trend for hackers to target medical records rather than electronic credit card data as the former proves to be more profitable and less risky.
The natural, immediate response on discovery of a violation would be to shut that access down. Temporary inconvenience to valid users would likely be a secondary consideration to patient confidentiality.
Contrast that with safety critical embedded applications often need to keep going in the event that a problem arises.
Figure 1 A separation kernel and hypervisor add security
For example, in 2005 an implantable cardioverter-defibrillator was reported to be potentially affected by background levels of cosmic radiation such that it would suffer from a permanent loss of defibrillation support.
But clearly there would be no benefit in shutting down its pacing functionality in response to that. The default response is to retain as much functionality as possible. Perhaps that is a key differentiator?
But dig a little deeper and that distinction becomes less useful.
As long ago as 1985 in Canada, a radiotherapy machine was involved in at least six accidents, in which patients were given massive and lethal overdoses of radiation, approximately 100 times the intended dose – all as the direct result of poor software development practice. There is no hint of a security issue here, and yet in this situation, the default option would again be to shut down the device.
Perhaps more to the point, notorious New Zealand hacker Barnaby Jack’s demonstrated ability to wirelessly attack and take control of implantable insulin pumps underlines the fact that where medical devices are concerned, we actually want “safe secure systems”. Jack clearly demonstrated a security breach which rendered the device unsafe – and the recipient of an insulin overdose will really not care which category the offending software belongs to.
Combining Multiple Independent Levels of Security with Functional Safety
The US Food and Drug Administration (FDA) recommends that manufacturers consider cybersecurity risks as part of the design and development of a medical device, and that they submit documentation to the FDA about the risks identified and controls in place to mitigate those risks. That implies applying safety and security best practise.
In the main, functional safety standards such as the generic IEC 61508 / EN 61508 and the medical device industry specific derivative IEC 62304 / EN 62304 demand functional safety requirements to deal with any circumstance likely to compromise safety – including any security threat with that potential.
In each of these standards, a great deal of emphasis is placed on best practise methods in the development of system and software, from design and specification, through to implementation and testing.
Although these practices are designed primarily with safety in mind, code which is well designed, written, and tested will almost inevitably be more secure because many of the errors which lead to vulnerability will be proven absent.
Conversely, it is equally appropriate to complement those safety focused best practice principles with best practice from the security critical world.
This centres on the Multiple Independent Levels of Security (MILS) specification. The core of MILS is the separation kernel, which allows multiple software functions from different development and verification sources to share common resources such as CPU, but have no unwanted interference.
Where a safety critical application is required to be accessible (perhaps via the internet) then a least privilege separation kernel provides an optimal approach to ensuring that such access does not compromise the security and hence safety of the system.
A traditional separation kernel is designed to ensure that different blocks of a partitioned system are not visible to other blocks, except perhaps for certain specified and tightly controlled flows of information. The least privilege model extends that principle by subdividing the contents of the blocks so that such visibility is minimised to provide only that access which is absolutely necessary.
Where such a configuration is host to software written in accordance with the functional safety standards, then best practice from both worlds can be seen to be applied.
Considering figure 1 as an example, suppose we are looking to provide monitoring facilities via the internet for a safety critical application. The aim here is to provide security for safety critical applications such that they can run in an RTOS, or as a “bare metal” application like the “trusted app” in the illustration.
Applications such as the Windows OS shown can interact freely with the internet because the partitioning between it and the “trusted app” means that any successful attack on the Windows OS cannot impact that “trusted app”.
Of course, there will need to be some communication between the two partitions for this configuration to be useful, but the nature of a separation kernel based on least privilege ensures that such communication is highly regulated and hence the security risk minimised. That approach is complemented by means of full virtualisation within the partitions rather than the kernel, thus avoiding a potential access point for any threat.
This approach also minimises the size of the separation kernel itself, and the independence of any device drivers from the kernel means that the separation kernel can be tiny – as little as 25,000 lines of code. The smaller this footprint is, the smaller the amount of shared code and data space between the partitions, and hence the fewer the opportunities for potential attack.
This means that the separation kernel closely regulates the communication paths between the operational technology on the plant side, and the information technology on the internet side.
In this example, if there is a successful denial of service attack on the Internet facing windows partition, then the external operator may well be denied access to the information he is seeking. But the safety critical incubator plant control will be protected by the separation kernel, and will continue to function normally.
In short, the safety function is fulfilled by the application of best practise security focused development.
Just as it is largely academic whether the world ends with Fire or Ice, so it is irrelevant whether a failed safety critical medical device is the victim of a safety or security flaw. We need safe secure systems where similar attention is paid to both elements.
Happily, the best practices espoused by the safety focused process standards such as IEC 61508 / EN 61508 and IEC 62304 / EN 62304 can only benefit the security aspects of those applications too.
Conversely, drawing on best security development practice further addresses the functional safety issues. By applying least privilege separation kernel technology, even in well written code the remaining exploitable software weaknesses can be minimised, thus fulfilling the demands of security related safety requirements.
The activities of the late Barnaby Jack have helped to highlight that the current drive towards Internet connectivity for medical devices increasingly means that any security vulnerabilities are in fact safety issues too, making such an aim ever more desirable. Perhaps even more significantly, current FDA guidelines are that premarket submissions for new devices should now include a description of security measures to be applied.
Mark Pitchford is technical manager with Lynx Software Technologies.
from News http://ift.tt/1En1ipx
via Yuichun
沒有留言:
張貼留言