Using Risk Assessment during Application DesignMuch of what I did say in the Security Considerations: Healthcare RESTful Resource specifications is usable at Application Development time. However at Application Development time you will be making some Design decisions. I would encourage being as open as possible, meaning being as configurable as possible. This openness and configurability is important to allow your application to be usable in many deployment configurations. The idea of this openness and configurability is to allow the individual or organization that takes your application to have flexibility in how they use it. But recognize that the clause “… as possible” is an indication that it is almost never possible to be perfectly open and perfectly configurable. Thus one makes decisions that affect just how flexible the application will be.
The closer the application development is to the deployment choices the less flexibility needs to be built into the application. For example when a Hospital has their internal IT develop a mobile application, they already know the deployment architecture and organizational policies. Thus they can hard-code some of these choices and policies. For example: These developers can know they will be using normal HTTPS, users will be authenticated to one directory (not federated), and the clients will always be devices that internal IT has endorsed as meeting their mobile-device-policy which includes mobile-device-storage-encryption. One can see how knowing this makes the Application development easier. I however do caution even these developers, as things change far too often and when they do there is usually little time to ‘fix’ the application.
Application being designed to be distributed broadly; such as in the Apple App Store, or Android Play Store; clearly need to be more configurable, robust, and defensive. They don’t know if users are going to use HTTP Authentication, oAuth, or SAML; and clearly don’t have any idea which resources will be authorized.
It might be a very good idea for a Healthcare Application to force the use of HTTPS. It surely is a good idea that this Application design do everything possible to prevent data from being stored onto the mobile-device. Any data that does need to be stored onto the device should be somehow protected, might be through encryption but might not.
Some good resources, again NIST based are:
- SP 800-53 - Catalog of Security and Privacy controls - technical, operational, physical, and management
- SP 800-30 - Security Risk Assessment
- SP 800-144 - Guidelines on Security and Privacy in Public Cloud Computing
- IR-7497 - Security Architecture Design Process for Health Information Exchanges (HIEs)
- The rest of the NIST 800 Special Publications
Balancing Security Controls with Operational Deployment Choices.Ultimately Security Risks need to be addressed as soon as they can, but not sooner than they should be addressed. Any Security/Privacy Risk not addressed fully need to flow down to the next design level. That is any risk that can be addressed in software design should be addressed there, but many risks tend to need operational choices and possibly physical controls. Transparency is important: Describing the assumptions that were included in the design, what controls does the design enable, and what residual risk must the next design handle.
See Also: Security/Privacy Risk Assessment/Management
- IEC 80001 - Risk Assessment to be used when putting a Medical Device onto a Network
- More Webinars on Basics of IEC 80001
- IEC 80001 - Security Technical Report presentation
- How to Write Secure Interoperability Standards
- How to apply Risk Assessment to get your Security and Privacy and Security requirements