Eagle Software Dental Tutorial

Overall: As the Chief Security Officer and Director of IT for a mid-size dental practice, and as someone who manages Product Management for delivering enterprise security products for some of the largest organizations in the world, for all the good that Eaglesoft potentially provides to a practice, there is no way in good conscience I could / would recommend the product based on its inability, and the company's lack of desire, to address basic issues that contribute to poor security. Our practice has spend multiple thousands of dollars and increased network complexity, in order to mitigate, to our risk assessment satisfaction, and address both our HIPAA HITECH and PCI compliance obligations ariybd these basic issues. EagleSoft did take steps in version 18 to improve the security of its database and protect patent data at rest which was both commendable and expected under HIPAA HITECH. However, other basic security best practices, Patterson has demonstrated absolutely no desire or willingness to address. Prior to posting this review, I reached out to Patterson notifying them of these issues, and offering to partner with the organization to address. I was politely told 'no thank you' and that 'they had no intention of addressing the issues in the near future.' That was in Oct 2017. The basic issues are:1. The product forces you to have your practice users have local administrative privileges on the workstation - This runs completely counter to the 'least privilege' principal of security that states that a user should have the absolute least amount of privileges required to perform a set of tasks. As a result of this requirement - we cannot sufficiently lockdown our computing environment to sufficiently address Change Management. Further, if a practice user shoul inadvertantly stumble upon something from the internet that our Symantec Endpoint protection should miss, this single issue creates a condidiotn where the malicious code can propogate across the network faster then we could contain it. That is because our staff move between 11 treatment rooms. Wev've been forced to do heavy network segmenting as a mitigation tactic so that we could contain an outbreak or other malicious code providing us sufficient time to detect and respond. There is absolutely no reason, except for lazy coding practices, that in 2018 and Windows 7 and higher platforms that Eaglesoft cannot easily adapt their Win32 UI to run without fear of error when the user is logged onto the workstation as nothing more then a local system or domain User. 2. The second security flaw is that it is predicated on an idea that all users are using a shared credential at the workstation. While I understand that this is normal behavior in historical practices, and even today in smaller practices who choose simplicity vs. other risk, the product can be and should be able to easily adapt to an environment where each practice user has their own unique network login. It is already a requirement in PCI, and expect that in future HITECH updates that multi-factor authentication, i.e. OTP will become increasingly required. This inability to cleanly address multiple user profiles results in:2.1 Violation of security best practices because it obscures tracability of action on the network. 2.2 When each user has their own system login, Eaglesoft forces you to go in and make sure that each person is individually setup to leverage common resources like X-Rays, Oral Cameras, etc. This makes moving from room to room difficult because for less technical users it makes it impossible to seamless work in any room where they may have never worked before because configurations cannot be set at a workstation level and traverse all profiles. 2.3 Eaglesoft does not provide the ability to integrate natively with Active Directory. I can understand, and fully accept Patterson's decision for Eaglesoft itself to be its own standalone Authentication and Authorization mechanism. It makes perfect sense because Patterson does not want to have an inherent mandate that AD be a prerequisite. In small practices that would too much. However, with that said, I know for 100% sure that it is not brain surgery to equip a product with its own authentication and authorization schema to leverage AD authentication and authorization if AD is present. I've done it multiple times in multiple enterprise scale products. I would expect that it should be possible if AD is present that I should be able to map an AD account to an Eaglesoft account. Today my users have to sign on twice. Once to the workstation and then to Eaglesoft, when once would be sufficient. To be blunt, these security issues above make it very hard for those of us with an information security background we are hard pressed to not look negligent if / when a security breach occurs and someone evaluates our due diligence against established security best practices.In summary, for all of the wonderful capabilities of Eaglesoft that in many ways makes it a 'must have' for our practice. But in truth, If it wasn't for the fact that it was easier and cheaper to incur the additional network complexity and operations costs then it would be to detangle the practice's operations from Eaglesoft and migrate to an alternative platform we would have replaced Eaglesoft over a year ago.