X-Charge issues I've come across

[alkhaef]

Hi guys,

Just wanted to report a few issues I've had in regards to X-Charge / its bridge. I'm not sure if much of this is probably stuff that should be reported to them, not you guys, but I thought I'd mention it here anyway, in case you have any pointers / workarounds.

1. Permissions - underprivileged users configuration
The X-Charge bridge apparently requires the ability to write two files to the program path (XResult.txt and some other one - I forgot). I'm having all the staff log into windows as an underprivileged user, which means they can't write to Program Files (for good reason).
So the only way I got this to work without opening a gaping security hole was by setting the advanced NTFS permissions (specifically, write new files to a directory) to the X-Charge program path. It works I guess, but letting ordinary users write to Program Files defies usual convention. Is there another way? Am I overcomplicating this?

2. Mixed 32-/64-bit environment
I just tried adding a swiper and X-Charge to my first 64-bit machine in the office, and it looks like the bridge isn't designed to allow a mixed environment. I tried hitting the little X-Charge button and got the familiar "Program path invalid" (or however it's worded) dialog. Naturally, the path was "C:\Program Files\X-Charge". Since this is stored on the server, if I change this to "C:\Program Files (x86)\X-Charge", the 32-bit machines won't work.

3. 64 bit
Actually, I tried it anyway just for fun, and the 64-bit machine didn't seem to work just by itself. X-Charge seems to work, but then the XResult.txt file wasn't being created, and an exception is thrown. I was logged in as an administrative user too. I didn't try to probe further though, because I thought maybe I'm doing something wrong, using an outdated version, or hitting a known pitfall. The installation file I used was called XC7.1.5OIsp5.exe ... Maybe there's a newer version that adds 64-bit compatibility? Oh, this is under Windows 7, by the way. Any pointers?

Thanks again! I'm loving all the new features these days!!!

-Al

[jordansparks]

1. Why not give users local admin for each workstation?
http://www.opendental.com/manual/networkusers.html
It doesn't open up any security holes that I can think of since they don't actually get any domain admin privileges.

2. You can either install X-charge to something like C:\xcharge. Or you might be able to refer to the exe without any path info, like xcharge.exe; Windows can usually find it just fine.

3. Don't know. Just make sure your Xcharge version isn't more than a few months old.

[packets]

1. Why not give users local admin for each workstation?
http://www.opendental.com/manual/networkusers.html
It doesn't open up any security holes that I can think of since they don't actually get any domain admin privileges.

Actually, user(s) with administrative privilege(s) on the local machine can install software and/or change system files on that machine…this is how malware gets installed on system(s) and will have the same privilege/permission as the user it was installed from (i.e., admin) and therefore has the ability to disable/neuter/bypass locally installed security software and touch any data (i.e., PHI) accessed by that machine. Yeah, scary and many employ workgroups and not server/client and share protected resources to "Everyone". D'oh!
Unfortunately, this is a huge security issue, but in order to use todays Practice Management and Imaging software(s) most vendor support recommend configuring users with local admin privileges to avoid the problematic configuration issues which arise. Power User is more desirable on the local machine but doesn’t get even a simple mention in today’s software installation documentation…this industry and securing its digital assets are still far apart and will make for a very interesting next couple years...

[shvercer]

Very interesting observation indeed. Unfortunately "Power User" has been deprecated with Vista/Windows 7 and as such it's really not recommended in an Active Directory domain or workgroup environment. With the Power Users group in Windows 7 and Vista, the elevated privileges have been removed. The Power Users group is maintained only for compatibility with legacy applications. Therefore, if you require elevated privileges, you'd still have to do a "Run As Admin" option in order to get those elevated privileges. The best thing to happen would be for the software developers to adopt Microsoft's security principles as soon as possible, because the longer they wait the harder it will be to make the adjustments later on.

[packets]

Very interesting observation indeed. Unfortunately "Power User" has been deprecated with Vista/Windows 7 and as such it's really not recommended in an Active Directory domain or workgroup environment. With the Power Users group in Windows 7 and Vista, the elevated privileges have been removed. The Power Users group is maintained only for compatibility with legacy applications. Therefore, if you require elevated privileges, you'd still have to do a "Run As Admin" option in order to get those elevated privileges. The best thing to happen would be for the software developers to adopt Microsoft's security principles as soon as possible, because the longer they wait the harder it will be to make the adjustments later on.

I don't believe the Power Users ever had full root privileges (thus its recommended use) and agree with you, with the current software configuration requirements security & control of protected assets is basically impossible and HIPAA/HITECH compliance a very interesting endevor indeed...

[jordansparks]

HIPAA compliance is very easy using our suggestion. Your only complaint was malware, which can be addressed by many effective means. For example, centrally monitored antivirus software will help prevent someone from uninstalling their antivirus without management knowing about it.

[packets]

HIPAA compliance is very easy using our suggestion. Your only complaint was malware, which can be addressed by many effective means. For example, centrally monitored antivirus software will help prevent someone from uninstalling their antivirus without management knowing about it.

Understand malware is not a complaint but a concern. The discovery of malware on any resource within the domain (which includes any device(s) or resource used to remotely access the system) is simply evidence of a lack of control which goes back to my main problem of allowing users administrative privileges on the local machine. Providing any user(s) such a privilege allows a more serious concern, system compromise and the obvious loss of control of digital assets and more importantly protected content while it clearly demonstrates the 'easy' compliance unattainable. Like I've stated before, the convenience of EHR's is going to be costly, some in the end won't be able to afford it and may just choose just to do something else...Isn't IT becoming fun?
Below are a couple recent articles for your reading pleasure:

Verizon Security Report: 97 Percent of Attacks Were Avoidable
"As for the types of attacks used, Verizon found that incidents that utilized a hacking tool or skill constituted 81 percent of attacks, with 69 percent of those attacks employing the help of malware to pull off the breach."
http://tinyurl.com/88detnb

Data breaches increasingly caused by hacks, malicious attacks
"More than two-thirds of malicious attacks were achieved through some sort of electronic exploit—only 28 percent involved the physical theft of data storage devices. Trojans, botnets and other malware were at the root of half of criminal and malicious data breaches reported by the companies surveyed."
http://tinyurl.com/6qzxba3

[packets]

This problem of requiring administrative privileges on the local machine is not unique to Open Dental for it is an issue across the entire dental industry…regardless of platform.