App Security Related Rules and Considerations

Owned by Andrea Dennis
Last updated: Mar 09, 2021 by christopher cannaday
4 min read



All end user businesses will need to make considerations as to the use of mobile devices, examples being:

In general the topic of Mobile Device Management (MDM) will be considered differently depending on the type of and size of the business the Noah end user works for.


Minimum Computing Device Security 

At the very minimum Noah end users need to take responsibility to:


  • Enable drive/storage encryption

  • Take steps to regulate immediate access to the device (e.g. lock screen with authentication).

For commonly used mobile devices using the iOS or Android operating systems both points above are implemented by enabling the lock screen with password/pin code/biometrics.  When this is enabled then the drive/storage is encrypted and immediate access to the device is also regulated.

For Microsoft PC’s the user will need to enable MS BitLocker (or other similar product) to encrypt the drive/storage.  The user will also need to enable the lock screen with password/biometrics as well.

Q: Is an App developer required to ensure that the end user has taken the above precautions?
A: No, but the developer is strongly encouraged to help promote at least these minimum settings.  Most modern systems do support  methods for checking to see if these tools have been enabled.  If the App is able to make a determination then the App can, and is encouraged to, alert the user to the potential risks they are taking.

HIMSA will also dedicate resources to provide information as well as provide marketing on this subject.

Monitoring for Inactivity

In addition to the minimum device security settings and additional MDM features that should be set by a Noah user HIMSA requires that apps automatically log off a user if the session is deemed to be inactive.  This requirement is in place to provide another fairly standard security approach to safeguard the Noah database

HIMSA’s  requirement is that all apps are responsible to monitor for an inactive session.  If the user is deemed to be inactive then the app will be responsible for logging the user off of Noah.  Inactive means that the user has not performed actions within a number of minutes such as: 

  • Moved their mouse or touched the screen

  • Entered data

The default number of minutes used to determine an inactive session will be 20 minutes.

Q: Can the app fix the number of minutes lower than the HIMSA set 20 minutes?
A: Yes.

Q: Can the app display a preemptive message before the session expires?
A: Yes, and the user can respond as long as the session time has not been exceeded.  For example, at 19 minutes of inactivity the app could display a message “Your connection to Noah is about to end due to inactivity, would you like to continue?”, if the user indicates “yes” then the user can continue without needing to be authenticated.

Q: Can the app allow the user to change this default behavior?
A: Yes, the app can allow the user to set the number of minutes to be 1 to unlimited.  However, the access token that is granted when first logging in will only, as currently set, be useable for 4 hours so at some point the user will be asked to log in no matter if their session is deemed active or not by the app.
 
If a hearing care professional wishes to take advantage of an apps optional offering to allow the session timeout to be longer than 20 minutes, then setting up the minimum computing device security features will become even more important.

Q: What should the app do in the event that session is expired and there is unsaved data?
A: HIMSA’s suggestion is that the app save the data to Noah and then indicate that the data was saved due to session inactivity (e.g. add helpful text to the action description or other means). 
 

Q: Can the default inactivity timer be set to 30 minutes or more?
A: No, the default inactivity cannot be changed to 30 minutes or more.

Web Browser Autocomplete Considerations



Before an app can interact with Noah it must receive an access token and this process is facilitated by the app asking the Noah authentication server login GUI to be made available to the HCP.  This GUI is implemented as an HTML page and will be shown to the user by a web browser installed on the device.

Depending in the web browser and other possible browser settings the HCP may or may not be able to save the user name and password.  

The HCP will need to take responsibility as to whether the passwords should be remembered or not.  

HIMSA and member companies will both need to promote the use of good security choices so that HCP's can set their balance between ease of use and appropriate security.

If a HCP is to allow auto completion to occur then it would be recommended that it only be allowed when the computing device is only used by 1 HCP, or the device supports individual logins for HCP's, and, that a screen locking tool is in place and activated. 




Apps are also required to provide the following authentication related items:

  • A GUI item to log off.  When selected by the user the app will not be able to interact with Noah until being authenticated again.  It is, of course, O.K. to confirm with the user first (e.g. check for unsaved data).

  • As currently implemented Noah System does not require a “strong password” be used to gain access to Noah mobile functionality.  HIMSA does have plans to change this in a near future release where a strong password will be required for a Noah user to use the relay service.  HIMSA feels that it is very standard practice today to require this type of password on any typical web site.