Ask HN: Encryption and Security in MUMPS

#1

Post by tcpipcowboy » Wed, Feb 01, 2017, 5:44 PM UTC

I am curious to hear from anyone working in the Healthcare Industry who programs in MUMPS how they secure and encrypt data. Electronic Health Record applications such as Epic who use MUMPS and/or subsets of the language may not have inherent MUMPS-based security. How do you approach security and encryption in your MUMPS environment?

I did see this note in the MUMPS help and will be digging into ANSI M to see if I can get more information:

$TRANSLATE() provides a tool for tasks such as changing case and doing encryption.

For examples of case translation, refer to the ^%LCASE and ^%UCASE utility routines.

Re: Ask HN: Encryption and Security in MUMPS

#2

Post by whitten » Wed, Feb 01, 2017, 7:47 PM UTC

The first line of defense and encryption is provided by the MUMPS system itself. Both Cache and GT.M provide encryption of the database on the disk. I am not as familiar with Cache's methods recently, but as I recall, GT.M has stated they are encrypting the dynamic data in memory as well. GT.M also allows changing the encryption key for a database and re-encrypting the whole database with a new key dynamically. (i.e. while the system is actively being used (read and write) for financial or healthcare data.)

Other common issues in healthcare involve using ssh and TLS to encrypt TCP/IP data being transmitted over the network, as well as use of PGP or one-way encrypting for login passwords, such as VistA's ACCESS CODE and VERIFY CODE.

Re: Ask HN: Encryption and Security in MUMPS

#3

Post by tcpipcowboy » Wed, Feb 01, 2017, 8:00 PM UTC

whitten wrote: post #2

The first line of defense and encryption is provided by the MUMPS system itself. Both Cache and GT.M provide encryption of the database on the disk. I am not as familiar with Cache's methods recently, but as I recall, GT.M has stated they are encrypting the dynamic data in memory as well. GT.M also allows changing the encryption key for a database and re-encrypting the whole database with a new key dynamically. (i.e.…

A hypothetical example would be a routine that calls another routine and passes information to the child process. Can one programmatically encrypt that information to make sure it retains PHI security? This is asked understanding that at the server level the information should technically be secured (as you noted, including transmitted data), but with the desire to work in "paranoid mode" and ensure extra layers of patient confidentiality at the code level. Just in the tutorials for MUMPS and M I've reviewed so far I've not seen any clear examples I could test out.

In reviewing $TRANSLATE()closer, it's not exactly what I'm looking for, either, although this and $ZTRANSLATE() may be as close as I can get for my example from what I've read thus far. Appreciate the reply!

Re: Ask HN: Encryption and Security in MUMPS

#4

Post by whitten » Thu, Feb 02, 2017, 11:14 PM UTC

tcpipcowboy wrote: post #3

whitten wrote: post #2

The first line of defense and encryption is provided by the MUMPS system itself. Both Cache and GT.M provide encryption of the database on the disk. I am not as familiar with Cache's methods recently, but as I recall, GT.M has stated they are encrypting the dynamic data in memory as well. GT.M also allows changing the encryption key for a database and re-encrypting the whole database with a new key dynamically. (i.e.…

A hypothetical example would be a routine that calls another routine and passes information to the child process. Can one programmatically encrypt that information to make sure it retains PHI security? This is asked understanding that at the server level the information should technically be secured (as you noted, including transmitted data), but with the desire to work in "paranoid mode" and ensure extra layers of p…

So, calling another routine in M doesn't create a child process. Nor does calling a routine in M create a new thread. The "MP" in MUMPS is "Multi-Processing" and you expresses that you can start another "JOB" that calls another bit of code that starts in another process using the JOB command rather than the DO subroutine call command. (I'm trying not to be pedantic, but rather to increase knowledge about this obscure programming language)

You can pass data to this other process, but the ANSI MUMPS standard does NOT require that the data passed by inter-process communication channels be encrypted.

Since GT.M is open source, it is an interesting idea to encrypt this data and decrypt it when receiving it. I'll bring it up to some friends.

Another idea worth examining might be to use the Foreign subroutine interface both in Cache and GT.M systems. Thanks for suggesting this.

Re: Ask HN: Encryption and Security in MUMPS

#5

Post by tcpipcowboy » Fri, Feb 03, 2017, 10:45 PM UTC

whitten wrote: post #4

tcpipcowboy wrote: post #3

Earlier quoted context omitted.

A hypothetical example would be a routine that calls another routine and passes information to the child process. Can one programmatically encrypt that information to make sure it retains PHI security? This is asked understanding that at the server level the information should technically be secured (as you noted, including transmitted data), but with the desire to work in "paranoid mode" and ensure extra layers of p…

So, calling another routine in M doesn't create a child process. Nor does calling a routine in M create a new thread. The "MP" in MUMPS is "Multi-Processing" and you expresses that you can start another "JOB" that calls another bit of code that starts in another process using the JOB command rather than the DO subroutine call command. (I'm trying not to be pedantic, but rather to increase knowledge about this obscure…

Thanks for the terminology clarification. Still getting used to M so please bear with me here. I'm using GT.M-amd64-Linux/V6.3-000A.

Just in the research I've done so far, I'm looking at something along the lines of the below, but I would love to see more advanced and complete snippets.

  ;--
  ; New, define variables
  ;--

  N cryptKey,derivedKey,cipher,plainText
  S cryptKey="Private Encryption Key"
  S derivedKey=$$zderiveKey(cryptKey,1,1)
  S plainText'"Hello, Crypto World!"

  ;--
  ; Encrypt plainText
  ;--

  S cipher=$$zaesenc(plainText,derivedKey)

  ;--
  ; Display decrypted text
  ;--

  W #
  W !,"Encrypted: ",cipher
  W !!,"Decrypted: ",$$zaesdec(cipher,derivedKey)
  Q

I'll look into the Foreign subroutine interface. Anything like Haskell's FFI?