Monitoring your Computer by WhiteListing
WhyWhiteList?
The opposite of saying what you don't want is to say what you do want. What you do want in a working and safe Computer Community is a relatively known configuration. It includes how your computer was originally set-up, what applications you have installed and what programs and applications that you have created. It also includes how you want these to work together and the paths that you allow or prepare. What you don't want in your Computer Community is a much tougher specification. It has to include all the malicious things that any hacker can imagine and possibly create.
Anti-Virus Software (AV) has been our collective "Black" attempt to specify what we don't want. It uses discovered patterns, heuristics and indicators to attempt to spot malicious attack methods that have been seen before and stop them from happening again. This constantly places our commuity computers in the position that we hope we are not the target of a Day 0 (First time seen) attack approach. We are relying on the hope that someone will be hit first long enough in advance that our AV suppliers can spot the patterns and include those into the next release of AV pattern download. With the explosion of the number, complexity and routes of attacks happening against the world computer environments this approach is being stressed and stretched like never before.
Whitelisting is one "White" approach to detail and specify what we do want. While being able to list files by name is part of it, knowing the file name and knowing that its is actually the correct file contents under that name are two different things. The concept of a file hash (mathematically calculated value based upon the contents of the file) tied to the name goes a long way towards making and confirming that link. Putting together a list of filenames with file hash values that are "Good" allows us a baseline from which to review our Computer Community. This review can be periodically or it can be in real-time. Note that if you are doing reviews of this periodically then between reviews you are susceptable to Day 0 attacks. I submit that before you can handle the Real-time activity load of Whitelisting you need to learn what and how it will affect your day to day work.
WhiteList Toolkit
The Whitelisting toolkit linked above provides a set of functions and tools to allow you to prepare these baselines, monitor and capture the changes inserted by application installations or development and then perform reviews. From these reviews various actions can then be decerned as to what has to be done to maintain the baseline and investigations and actions on specific machines to keep them "Healthy".
Building/Maintaining a WhiteList Baseline
Building a whitelist baseline initially sounds like a daunting task. It consists of recording a snapshot of every executable and configuration file and calculating a file hash so that each one can be uniquely tracked. I submit that a good starting point for your baseline is a full machine scan of new "clean configuration" machine with standard software installed. You should do this for each of the models of machine in the organization. An alternative approach is to start with one and incrementally adjust and add as other acceptable variations are discovered. Know that as patches come in for OS, core software and specialized software then these too need to get added to the accepted baseline. Typically this is done by applying these patches to a "static clean" machine and making adjustments and adds from that to your baseline. You can expand your baselines to have different user/usage profiles based upon what roles and configuration are necessary. When I takl of adjustments here they are a series of flags to previous versions of a file or executable that indicated a particular version is still accepted but on its way out, not longer desired, should be gone or needs deletion because it is a present danger.
I warn that the maintenance of these whitelist baselines gets exponentially larger as a result. Know that a typical windows server profile with just core OS (W2008) and modules is over 230,000 entries and W10 is in excess of 140000 entries. Installs of utility tools like SQL, .NET, Visual Studio, Office 365, Application Clients,... all add to the whitelist baselines. Anything added to the profile will need to be
Adjustments are highlighted above because this is not a strightforward process in itself. New files will be added. Files that have been superceded will be identified but it is a decision if they should be flagged for immediate removal if spotted later or if they can co-exist and if so for how long. On servers it may be possible to quickly shift versions, but it may also be necessary to accept older versions in order to support older dependancies that do not operate correctly with newer versions. These are just some of the learning points that come with putting together a WhiteListing service.
WhiteListing with and internal Development Team
If you have a development shop then the results of your build process deployment (CD/CI) is the perfect place to get a folder based profile of the build components that are being deployed into your Computer Community and should be added and adjusted directly into your basline just like COTS software and their updates. The internal Build process is the perfect location to spot hash calculate and provide the instructions for the proper update of appropriate whitelist baselines. As part of any DEVSECOPS interactions this information ties in directly to Change Management, Release Management, Deployment Management considerations to meet operations, security, QA and audit requirements.
Doing WhiteList Reviews
Doing a periodic machine review requires a current Machine Profile from the machine being assessed. This detailed file and filehash profile is then processed this against the whitelist baseline prepared and maintained above with matches of both name and hash. When a match is found on both criteria then the usual action is `No Action`. Sometimes it is to trigger patches, trigger software updates, or just do an investigation. If a match is only by one criteria, either name only or hash only then investigation is necessary. Potentially this is a new file to be added (a Hash collision), or a older version of a file, but could also be a `Black Trojan' file attempting to masquarade as a legitimate file. Where no match of either name or hash is found then again this needs investigation to either add it to the baseline or reject it as something unknown.