I work in a software-development company where we have a lot of tech-savvy people. For ISO27001 certification we need to maintain list of approved software. And I'd like to understand how in practice this list is maintained and enforced?

The problem is that, we can define the list of the main tools used in the company there. But besides these big products like MS Office, Visual Studio etc there is a whole bunch of small tools like tools from Sysinternals, rootkit finders, browser plugins, plugins for VSCode, 3rd party libraries used by developers, scripts which are written internally or downloaded form the internet etc. For linux servers, there are also thousands tools available from the official repos. On windows people can run any portable tool even without admin rights.

Another aspect is how to practically enforce this list on laptops and on servers. The portable tools don't require admin rights to run, quite a few users have admin rights as they need for work.

For me it looks impractical to maintain list of all these small bits and pieces and I'd like to understand where to draw the line. The systems need to be secure but usable at the same time and we should not slow down work for the employees as well.

I'm thinking of:

  1. defining list of the main categories of the tools and ask users to use only approved tools from defined categories. And for all small tools - state that users are responsible for security validation of the tool (antivirus check, download from trusted/known source, review of the script before execution etc).
  2. For linux servers - allow everything from official repositories
  3. For windows servers - allow installation only to admins (in place) and on terminal servers - use whitelisting for the programs by hash.
  • What are the best practices to implement and enforce the list of approved software?
  • How do you make sure that the list is valid?
  • How do you enforce the list?

1 Answer 1


There are really two questions here. If you're looking at how to actually enforce the use of approved software only, you need to application whitelisting (using something like AppLocker) to only allow binaries with specific hashes to be run. You then need to test and verify every update or new version, and have monitoring in place to detect admins doing things they shouldn't and overriding your rules. Unless you're operating at TOP SECRET, this is probably impractical overkill.

If you're looking to put something in place that will let you pass ISO 27001, you can be a bit more open, but need to support it with policies. A common approach here would be to:

  • Ensure that your users don't have admin rights
  • Use AppLocker (or something similar) to only allow them to execute binaries from C:\Program Files and C:\Windows

You then need a policy to say that your admins won't override the rules (except in edge cases where this is allowed and documented), and to have processes to:

  • Review software and decide whether it's "approved" based on some criteria you define.
  • Allow users to request new software be added to the list
  • Maintain a list based on the above
  • Install this software on users' computers (or have a self-service platform like SCCM)
  • Deploy patches and updates to users
  • Handle exceptions and edge cases where users (or more frequently administrators) need to run something that's not on the approved list based on a risk assessment of the software.
  • Carrying out regular reviews to identify policy breaches (such as vulnerability scanning, asset/inventory scanning, or random auditing)

In terms of how you decide what is approved, that will depend on the requirements of the business. But it would often include things like:

  • Is it fully patched?
  • Are there any known vulnerabilities?
  • Is it still supported? Is commercial support available?
  • Can we legally use it (commercial licenses, compatible open source ones, etc)?
  • Is it written by a trusted company/developer?
  • Is it from a hostile nation?
  • Has it undergone security testing?
  • Does the developer follow secure development practices?

You can also look at outsourcing some of the work to reduce the overhead of managing software versions. This could be doing something like certificate-based validation (e.e, everything signed with the "Microsoft" code signing cert is allowed), or through "trusted" installation methods (e.g, everything in the app store is allowed).

It's not 100% bulletproof, but you should be able to find a balance that your auditor will be happy with, and that doesn't cause too much overhead and disruption.

  • 1
    You mentioned AppLocker in passing, but I think it's worth pointing out that this is by far the best practical security control you have for application approval in a domain environment. Broad path-based restrictions like `C:\Program Files` are a bad approach, but maintaining an AppLocker policy that allows the use of software on a per-usergroup basis is an excellent security control that offers real protection beyond just ticking the ISO27001 checkbox.
    – Polynomial
    Commented Oct 14, 2021 at 19:39
  • Allowing paths like that certainly isn't ideal - but I've seen very few people who've managed to actually implement and maintain anything much more granular in an enterprise setting. I'm sure it's possible, but given OP's question I think they're a long way away from that.
    – Gh0stFish
    Commented Oct 14, 2021 at 19:44
  • Agreed - it isn't easy. But if you've already got buy-in for iso27k, you might as well make an attempt!
    – Polynomial
    Commented Oct 14, 2021 at 20:26
  • Thanks a lot, guys! We'll try to find a balance :) How do you manage same thing on Linux/MacOS ?
    – Dmitry
    Commented Oct 15, 2021 at 11:42
  • @Dmitry for Linux you could look at SELinux (not technically application whitelisting, but can sort of be used that way), or something like fapolicyd. You could also look at mounting all the writable areas of the filesystem with noexec, so only root can run untrusted stuff (given that root can bypass your policies anyway). Never tried to do it on OSX, but I imagine they have something similar.
    – Gh0stFish
    Commented Oct 15, 2021 at 13:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .