For the Sysadmins: Software Compliance Tool
So I figured I’d formally unveil something I’ve had in development for quite a while. This has nothing to do with video encoding so, unless you’re a CTO or network administrator struggling to remediate application licensing issues and crack down on unwanted and potentially harmful applications installed across your userbase, you can safely skip this :)
So, the Software Compliance Tool is a small application designed to reduce the overhead in managing unwanted applications in a business environment. While Windows Vista and Windows 7 have made a lot of headway in easing reduced user rights into the Enterprise, it’s still very common that Local Administrator rights are given to end users. The reasoning for this is usually to work around application compatibility (both external and in-house). However, this introduces the ability for end users to install whatever they want on their computers, including games, peer-to-peer software and security vulnerable applications. It is the company’s responsibility to ensure that copyrights are not infringed, and that their network is secure. This is where SCT comes in (I love my acronyms don’t I?).
When implemented in your environment, SCT starts as a hidden application, scans the Windows Installer DB and the registry for application details. It then compares the found applications to the blacklist policy. If no matches are found, the application closes without any notification to the end user.
If a match is found, SCT displays a dialog to the end user and tries to remove the application automatically. For Windows Installer applications, this is generally fairly straightforward. For non-MSI based installs, the default uninstall string is used (from the registry) which can be further augmented with additions (ie, “/s” for a silent uninstall) or completely replaced with a custom action string.
Here’s what the end user sees if something is in breach of the policy:
So with regards to the policy, it can work in a number of ways:
- Firstly, an exact name match whereby you say ‘iTunes’ is not allowed.
- Secondly, you can specific that a partial match can occur. This is important for applications that write version information as part of the installation, for example, Firefox 3.5. With a partial name match, you can blacklist ‘Firefox’ and catch every version. This is also useful to blacklist types of applications, for example ‘Poker’ :)
- Thirdly, you can blacklist against the previous two types, but also have a version restriction. So let’s say that you allow, but don’t support Adobe Flash for Firefox. Flash is notorious for having security issues, so you could have a version restriction to the latest patched version and all previous versions will be automatically removed.
- Lastly, you can apply a blacklist but also allow exclusions through Active Directory groups. Just specify the group name in the application policy, populate the group with users, and they will be automatically excluded from the automatic removal of the application. This is especially convenient for administration applications, that you KNOW your standard user shouldn’t have on their workstation.
In order to prevent against tampering with the policy, it’s encrypted on first run, changing from an XML file to a .ECF file (encrypted compliance file, told you I loved my acronyms). This prevents the more technically adept users from modifying it.
In addition to this, it’s also possible to log all policy deviations to a SQL database, which can be tracked internally for repeated breaches, and subsequently actioned by IT or HR depending on your policies.
Since this is a standalone application, it can be deployed and rerun with whatever mechanism you want, ie. login script, SCCM, or a simple script that pushes it down to each users workstation and puts a HKLM\Software\Microsoft\Windows\CurrentVersion\Run key in place. Updating the policy is as simple as replacing the .ECF file.
So, I have this pretty much completed, and testing has been going extremely well. I’d like to gauge whether this is of interest to people though, to release and maintain.
Thoughts, questions and feedback would be most welcome!
Last but not least, although this tool has been built from the ground up, it’s been heavily inspired by something that two colleagues of mine in the Netherlands produced a few years ago (Yury Dijkhuizen’s idea which was developed by Erik Zalm), and I owe them both a lot of credit!
Dan
Good to see that you have mentioned Erik his name as being the programmer of the Harm tool (SCT). However I have to bring up that the inital concept was mine and not Erik.
Erik did work out this concept into a full and stable application.
Good idea to use AD groups in your version, but does this also work well in a disconnected environment?
Kind regards.
AD groups get checked, cached and encrypted when a connection to AD can be detected. This means that the application can still work offline, and again, the list of groups can’t be tampered with.
Cheers, Dan
Would love to get a copy of this to try. I’ve used your other tools and am well impressed.
Shane
Dan
Cheers, Dan
Chris
It’s actually pretty stable right now. I haven’t gotten a huge amount of interest in it though so I figured there wasn’t much point in releasing and then having to do ad-hoc support.
I’m happy to share with you what I’ve done though. And it’s already been tested extensively in a corporate environment with extremely positive results.
Dan
Cheers, Dan
I only came back to check if you had updated the WMA ( you DO love your acronyms don’t you? ) and discovered that you’ve created this tool also. Sounds great, I’ve worked at a few sites where admin rights were everywhere and therefore all manor of unmanaged, unpatched software was installed. I’d appreciate being able to test this, possibly at my next location if possible. Out of interest, what language do you create your apps with?
Cheers, Ben
I’ll send you on a version to test with. Let me know how you get on.
All of the tools available here are done in VB.NET
Cheers, Dan
I’ll start off by noting that in addition to having another Dan posting a response, you now have a second Ben posting one. :)
I would very much like to put this tool to use on my home network, specifically on the family computer. My family isn’t very tech savvy, and sometimes make some bad decisions about what kind of software he installs on the system. I’ve tried to talk to them about this, but my brother has been deaf to my warnings in the past. (He used to have a PC computer of his own. Before a faulty PSU bricked it, I ended up having to reinstall Windows three times.) I make a point of logging into the system every so often and checking what’s listed in the Add/Remove Programs control panel, but like many people these days, he knows just enough about computers to get himself into trouble.
The last time I logged in to check the list, free disk space was incredibly low, so I browsed around the file system and found a folder located at “C:\Program Files\Copy of Shareaza\”. P2P applications are great if you’re careful about which files you download. However, they aren’t something I want present on the family computer. (This is how he infected Windows with viruses on his old computer. He would download what he thought were songs, but were in reality executable files. I told him time and time again to look at the file extension, but he never listened.)
So, my question is this: can SCT check for the presence of a blacklisted application by executable name? In my opinion, such a feature would be incredibly valuable, especially with all of the “portable” versions of applications being released that simply extract themselves.
Even without this kind of functionality, I’d still be interested in giving this tool a whirl. I also have a mock-corporate environment of 6 networked virtual machines (one Server 2008 system, three Windows XP, one Vista, and one Windows 7). I set them up for my own testing purposes, but would be happy to introduce SCT into the mix and put it through its paces.
Actually, I initially prototyped blacklisting based on executable files and even specific file versions. The problem was, scanning local drives for these executables took forever, and chewed up a lot of CPU usage. One of my primary goals was to keep the tool really snappy, so that it could even be run in a login script without stalling forever – so I ended up cutting this feature.
If you want to test it, just drop me a message on the contact page.
Cheers, Dan