As I’m sure you’re all aware, there was another vulnerability advertised to the general public over the Christmas new year period, and if you’ve been following the details, the patches to fix this specific vulnerability have been recalled. The advice from Intel and other vendors currently is, “don’t deploy the patch as it can cause system instability and in some circumstances cause data loss or corruption”. Good stuff!
Protecting against vulnerabilities like this and many other security threats is a multi-layered approach, if you’ve got these layers of protection in place, then the risk of your computers being impacted by any of these vulnerabilities is greatly reduced.
Removing Admin rights
First and foremost, to protect your network and computers, you should be granting user’s with sufficient rights to do their job, nothing more. In our opinion, users very rarely need Administrative rights over a computer. Users in an Enterprise environment shouldn’t be installing software as they please, not only does this prevent system changes from being made, intentionally or otherwise, it also allows the IT department to maintain control of your software licensing.
One issue we tend to face when suggesting or implementing the removal of Admin rights, tend to be those joyful applications that sing out in protest. Most of these well written applications may simply require write access to the local machine registry hive, or write access to the application install location. You can use tools such as ‘Process Monitor’, system instability can in some circumstances cause data loss or corruption troubleshoot these applications and then granting the users write access to the require locations. This is far more secure than granting blanket Admin rights of the entire computer, or computer fleet!
Not all vulnerabilities or malicious code require administrative access, a user accidentally running a crypto locker application will cause more than enough headaches when all the network shares they have access to become encrypted. This is where Application whitelisting comes in. Using Group Policies AppLocker we can ensure that only authorised applications (e.g. programs, software libraries, scripts and installers) can be executed. The default rules you can create with AppLocker, allow applications installed in the ‘Program Files’ and Windows directories to run without hindrance. You can then extend these rules to allow additional applications to run as needed for your environment, and as you’ve removed Admin rights from your users, they wont have write access to these locations.
By far the most common distribution of malware I’ve experienced has been via E-mail attachments. I’m sure, like me, you’ve lost count of the number of times you’ve told friends, family, users, don’t open emails or attachments you don’t know, but let’s face it, that’s a losing battle, especially when one of these people get infected, and then start sending out emails unknowing to their address list containing a malicious payload. Most malware I’ve seen attached to emails has been either
an executable or script directly attached to an email, or in a zip file attachment, there are very few reasons a standard user would be sending these types of attachments via email, I’d even argue that IT users should also be using alternative methods for transferring these files. It may simply be a case of changing the script file extension to txt, which then at least requires the users interaction before it will run. In the enterprise environment, I strongly suggest setting up rules in your email system to block or quarantine any email with an executable attachment (including scripts) or any zip file attachments that include executable files.
If you’d like any assistance or guidance in implementing any of these measures in your environment, feel free to contact us, we’d be happy to help.