Note: We are using the term whitelisting and blacklisting in this post because it’s still the preferred terminology used by Microsoft. There is an even newer tool in the arsenal as well, called Microsoft Defender Application Control (MDAC). The older version (which shipped with Windows XP) is called Software Restriction Policies (SRPs), and its slightly newer, more updated cousin is called Application Control Policies (AppLocker). We will discuss later on about certain third-party tools that can extend the functionality of these core Microsoft offerings, but for now, we will concentrate specifically on these built-in tools. However, if you are using an enterprise version of Windows and/or Active Directory, there are two options that will always be available to you at no extra cost. There are many application whitelisting solutions out there available from third parties. There are also differences in deployment and management that you will want to consider. Each one of these options has pros and cons attached to them. You can block by path, by certificate/publisher, by network zone, or even by file hash. There are nuances within the whitelisting approach that we will discuss. If a new tool is identified that you want to prevent users from running, there is no update required – a whitelist blocks unknown executables by default. Instead of listing out the “known bad” executables, whitelisting operates by blocking *everything* except applications you specifically know that users need to execute in their day-to-day jobs – a “known good” list instead. Whitelisting, on the other hand, removes a lot of the overhead from this by using the opposite approach. You become tied into a game of whack-a-mole, an arms race of constantly updating the list of threats to be kept at bay. But the problem with blacklisting is pretty obvious – you are reliant on knowledge of every possible executable that a hacker might use, and need to then add it to your blacklist. For instance, you could blacklist executables such as PowerShell, the Registry Editor, known exploit tools like Metasploit or utilities that hackers might leverage such as the PSTools suite. Simply put, blacklisting is where you stop users running “known bad” applications. So not only does effective application control protect you, it adds a further layer of alerting that can spot an attack in its early stages. But if you are strictly controlling what users can execute, not only do you block the attacker from escalation, but you can also identify possible indicators of compromise simply by the very action of attempting to run these items. In an “open” environment, an attacker within your network can introduce their own executables and scripts, opening up possibilities for further compromise and move closer towards the Holy Grail of accessing all of your data and infrastructure. All breaches involve some form of pivoting which generally involves running utilities which shouldn’t be allowed to run in hardened environments.Ĭontrolling what a user can execute is a pivotal part of this approach. Ensuring that an attacker cannot move laterally through a compromised network is crucial – if penetration occurs, we need to make sure that it is as difficult as possible for the attacker to broaden the scope of their attack and gain a deeper foothold into your environment. Whereas we have all for a very long time concentrated on maximizing performance – looking at how we create the best possible “user experience” – security is another big concern for consultants, architects and administrators. Securing your environment is a huge deal these days. Of course, this might change depending on the security requirements.This article is aims to be a comprehensive guide to creating a secure Software Restriction Policy and is quite a long read – we recommend you bookmark it now so you have it to hand when you need it. You could also just give out Its not a great practice, but I think its slightly better than giving them full administrator access or gimping SRP. In the worst circumstances, I have given local administrator account access via a script that executes runas (packaged as an executable to obscure the password). There are a few mitigations, like using a hash rule or whitelisting the exe (as you mentioned). Its very frustrating to try and secure this type of thing when you really don't want to relax restrictions on the users. It requires write access to folders in the Windows directory (god knows why), along with write access to its folder in Program Files, along with the temp directories as well. I have some Italian CAD/machining software that is the absolute worst. The problem with whitelisting the temp folders is that most malware ends up residing in there.
0 Comments
Leave a Reply. |