WIXLIB

SECURYIN MIRTHCONNECTBest Practicesand Vulnerabilitiesof Mirth ConnectAuthor:Jeff CampbellTechnical Consultant,Galen Healthcare SolutionsDate:May 15, 2015galenhealthcare.com 2015. All rights reserved.

Best Practices and Vulnerabilities of Mirth ConnectTable of ContentsOverview3What is Mirth Connect?3Securing Mirth Connect Interface Engine3Certificates for Mirth Connect Server4Securing the Mirth Connect Frontend5Users and Permissions5Enforcing Security and Policies for Passwords5Auditing Mirth Connect Users6Securing Interfaces in Mirth Connect6SSL Manager (Connectors)7SSL Tunnels7Encrypting Message Content Sent from Mirth8Conclusion28

Best Practices and Vulnerabilities of Mirth ConnectOverviewWhat is Mirth Connect?Whether trying to comply with HIPAA, SOX, FIPS orany other federal regulation regarding the robustnessand integrity of data, security is a paramount concernwhen it comes to an interface engine that too often hasbeen underemphasized. When talking about securingan interface engine, most organizations are aware ofand take steps to ensure the data entering and exitingthe application is secured in some form, usually a VPNas many legacy systems are only capable of traffic overTCP\IP or directly to file. This is often seen as enough asthese applications often reside on internal servers whereorganizations feel they are safe and protected by their ownor contracted IT staff and it is only the data leaving thepractice that must be secured.Mirth is a cross-platform interface engine that enablesbi-directional sending of messages over numerousprotocols including TCP/MLLP, directly to database(MySQL, PostgreSQL, Oracle, Microsoft SQL Server, ODBC),file, JMS, FTP/SFTP, HTTP, SOAP, or SMTP.This is not enough in most cases however as there are amyriad of places where sensitive data is left unsecured onthe appliance, creating the possibility where a maliciousperson could breach the integrity of the interface engine.What about the storage of the messages itself as theypass through the application? How is the applicationfor the interface engine accessed and how granular areits permissions? Is there the possibility of interceptingtraffic as it leaves the server via a packet sniffer? Many ofthese areas of concern may have options in the interfaceengine to be secured, either through global settings onthe application or the interface handling the traffic itself,but enabling those options may very well have their ownconsequences which must be taken into consideration.As an example of hardening an interface engine andcovering many different points of failure for the integrityand security of its messages, I will be highlighting securityoptions for the Mirth Connect interface engine (v3.1.1) inorder to promote Healthcare IT best security practices.3Securing the Mirth ConnectInterface EngineBy way of default installation, there are several areas thatare left extremely vulnerable and/or encryption is left eitherat a lower strength than recommended or disabled entirely.Many of these areas can be configured or added to themirth.properties file found at the installation path Mirth/conf/mirth.properties for the Mirth installation. Howeverfor most default installations these are not added orconfigured, allowing for potential vulnerabilities tobe left exposed.For example, the Mirth Connect server service itselfconnects to a database through the use of connectionsettings held in the mirth.properties file. From a defaultinstallation, even for Mirth-installed appliances, theseare often stored in an unencrypted plaintext form,allowing for any and all with access to that file to viewpotential admin passwords and usernames to the Mirthdatabase. This could potentially expose other databaseson the same server as the account the Mirth Connectservice is configured to use to may also have accessto other databases.

Best Practices and Vulnerabilities of Mirth ConnectFigure 1.3: Mirth.properties file after encryption settings have been set.The database.password property is now properly encrypted.Figure 1.1: (Top) Database connections settings in the MirthConnect Server Manager and (bottom) how they are stored inplaintext on the server.To correct this vulnerability, an additional encryptionsetting can be enabled in the mirth.properties file thatwill prompt the mirth service after a restart to rewrite allplaintext passwords from then on to an encrypted, nonhuman readable format.Figure 1.2: After setting the encryption property shown here to 1, allpassword fields will be encrypted.4Other Mirth security settings (such as specificcryptographic algorithms, key length, and passwordcontrols such as minimum/maximum length, number ofspecial characters, numbers, expiration, etc ) must beenabled or configured from the local mirth.properties file.All of those settings by default are left to the minimumallowable values, which in most cases would not meet mostorganizations security policies.Certificates for Mirth Connect ServerIt is important for connecting agent, whether they beanother interface server or remote application, to be able toverify the integrity of the Mirth server by way of certificate.Depending on your network configuration, this can eitherbe enabled on the appliance itself to present its owncertificate or may be enabled on an intermediary devicesuch as a load balancer. If the certificate is configuredon the load balancer, with traffic passing back afterpresentation, configuring it on the Mirth server is onlyapplicable for persons connecting to it internally(by appliance page or otherwise).If you do need to configure a third party certificate onthe Mirth appliance, this can be done from the appliancehome page by going to Systems- Certificates in the menubar, generating the Certificate Signing Request, and thenuploading it to the certificate authority (CA) of your choice.

Best Practices and Vulnerabilities of Mirth ConnectOnce the CA has authorized the certificate and you’vepurchased the private/public SSL cert, this can beuploaded into the Mirth appliance configuration on thesame certificates screen as the CSR was generated.Optionally, the locally-signed Mirth appliance CA couldbe installed on agents that needed to connect so it wouldtrust the self-signed cert. However, I would advise thisonly for connecting locally (for those persons needing toconfigure and manage the appliance) rather than externalorganizations as that will likely not pass muster for integrity.Securing the Mirth ConnectFrontendUsers and PermissionsOne of the substandard features of Mirth lies in the lackof granularity of permissions for users of the application.When configuring users through a Mirth Appliance,you have the option of provisioning users as a ControlPanel User or a Mirth Connect User or both. Permissionsadministration is limited to those roles; no morepermissions beyond that can be set.A Control Panel user can log into the appliance homepage where they can view the current resource statistics,download upgrades, restart services, and otherwiseconfigure the physical or virtual appliance for Mirth itself.A Control Panel user cannot log into Mirth Connect, butthey can however access areas of the appliance wherethey can affect the running operations of the appliance.This role would likely be perfect for an IT staff memberwhom is likely responsible for ensuring the uptime ofthe appliance, but not for the interfaces running acrossit. Depending on your interface setup however, anyconfiguration or restart of services might require closecoordination with someone who can directly interact withChannels using the Mirth Connect frontend itself, whichleads to Mirth Connect users.5A Mirth Connect user can log into the Mirth Connectapplication where they can create, edit, view, start, stop,deploy, and undeploy channels (interfaces).They can viewthe logs of messages coming across each channel andremove or reprocess them. There is no way to assign rolesor permissions for a Mirth Connect user beyond assigninga user login, so it is extremely important to ensure that ifthere is someone who needs read-only access (such asonly needing to view or troubleshoot messages) that theyare careful about not modifying or changing settings for theinterface engine itself or any of the channels as they couldinadvertently break functionality of the engine or Channels.Enforcing Security Policies for PasswordsOne of the most common security policies an organizationhas to enforce surround the passwords used to gainaccess to sensitive systems. Mirth is fully configurable toenforce these policies by altering the password relatedproperties found in the mirth.properties file. There wecan set restrictions on the contents of the password suchas a minimum and maximum length, number of specialcharacters and/or numbers, expiration of the passwordbefore requiring it to change, number of retries beforelockout, etc Once these properties have changed, it willrequire a restart of the Mirth Connect service in order forthem to take effect.Figure 2.1: Password-related configuration settings in the mirth.properties file.

Best Practices and Vulnerabilities of Mirth ConnectAuditing Mirth Connect UsersIn the event of an audit or security inspection, it may berequired to validate that user interactions through the MirthConnect application did not cause a breach. It is possiblethrough the Events view to filter through Mirth Connectuser interactions with the interface engine by severaldifferent relevant fields.For example, to ensure that the message content storedby Mirth is only written in an encrypted manner to thedatabase, you must check the box on the Channel’ssummary page for “Encrypt Message Content as seenbelow. This has the double-edged implication of not beingable to search free text through the message itself, butmost fields you would be interested to troubleshoot oncan be placed in alternative locations such as ChannelMappings or Metadata columns where it will be muchfaster and easier to troubleshoot with.Figure 3.1: Checking the box highlighted in this Channel’s summary pagewill encrypt the message content it stores for it in the logs.Figure 2.2: The event viewer as seen in the Mirth Connect application.Seen at the top right as indicated by the number 1, various logs forindividual user actions are shows in a dashboard list. At the middle-rightnear the number 2, it is possible to filter these down to a specific userand/or server.The settings for the encryption algorithm used, key length,and hashing protocol used for the one-way hash can all beconfigured and set through the mirth.properties file, but bydefault these settings are not present and must be addedand the service restarted to take effect. In the image below,these settings have been configured to:Securing Interfaces inMirth Connect1. Use the AES encryption protocol.While many organizations are concerned with ensuringend-to-end transport of messages between interfaceengines or other applications are secure, it is just asparamount that any messages or message logs storedby the interface engine are just as secure. For Mirth,many of these encryption or storage settings arecontrolled on a per Channel basis rather than ona global interface engine-wide one.62. Use a key length of 256 (Maximum for AES)3. Encrypt anything exported from Mirth such as MirthConnect server configuration backups, channels, codetemplates, transformers, and filters.4. Use the MD5 hashing algorithm for one-way hashing.5. Use the BouncyCastleProvider as the security providerto use for all encryption and hashing. This is thestandard security provider used by Mirth.