Considering application whitelist tryst? NIST will help you clear the mist The US National Institute of Standards and Technology has published a guide to whitelisting that can help organisations deploy one of the most important defensive security technologies. Application whitelisting is chief among the Australian Signals Directorate's much-lauded Top 4 Strategies to Mitigate Targeted Cyber …
An application whitelisting technology might be considered unsuitable if, for instance, it had to be disabled in order to install security updates for the operating system or particular applications.
If set up properly, it should in fact block whatever does not fit a predefined pattern of behavior (including information about the installing user ID, source of install files, target of the install, temp directory used, et cetera). Unfortunately, the people who put together patches have a habit of changing many things a signature may be based upon from version to version which cause the white listed app's update to fail. This can be avoided by implementation of proper dev and test environments and verifying each new application and patch in them. Unfortunately, the need for setting up said environments in shops that do not have them prior to implementing white listing typically will lead to less than desirable outcomes.
Also, there will always be one-off applications in any organization. Rather than set up rules for all aspects of these, it is typically acceptable to turn off blocking, run the installation, turn logging on to make sure the app can run and then go back to blocking as normal*. This is in contrast to enterprise standard applications that should have rules created for both installation and patching.
* Based experience with McAfee's HIPS.
In theory, theory and practice are the same. In practice, they are not: Albert Einstein.
Application whitelisting may work in strict government networks where no one cares if there is downtime and no one is responsible for saving the pennies. Business though? No chance.
Surely it is more business friendly to conduct 'continuous application risk assessment', where all running executables are assessed for their 'normalness' (i.e. what, only one machine has this running?), risk indicators (small file, new, no signature, encrypted - oh dear), and behaviour (a new file, never seen before, and now trying to scan internal IPs - really?).
Hey let's call it Continuous Application Cyber Threat Intelligence (CACTI), seeing as it's a prickly area.
I have the feeling this will not be used much. I mean, look at "obvious" use cases where it isn't.
, and the sole
Slot machines? They're very secure, and the sole device type I know of that most definitely does use whitelisting among other security. I've seen one boot (it's very verbose so, in theory, the casino owner could watch for irregular boot messages); the BIOS was mildly customized to check the bootloader for tampering before loading and running it; the bootloader checked the BIOS and the stage 2 loader for tampering; stage 2 checked the bootloader and Linux kernel and initramfs. The Linux kernel initramfs verified everything it ran was on some list, and the slot machine software was on that list. The slot machine software ran some further self-checks to check for tampering.
ATM machines? Obviously don't do this, or (even if it were running Windows) the ATM malware that Windows-based ATMs seem to get again and again would not be able to run. Those crappy electronic voting machines they had a few years ago? Nothing. Signage computers? Nothing. Those PC-style cash registers typically net-boot, but then aren't actually prevented from running other software. Various PLC systems, and other single-use systems, you've read about them on El Reg every now and again getting waves of viruses over them -- which is partly on Windows just running things just because, but also indicates they don't use a whitelist either.
I'm just saying, if a vendor of a single-purpose device (that uses a PC) can't bring themselves to use a whitelist, I doubt this'll be used widely, even though it's a good idea.
Cannot install handy open source tool because not whitelisted.
Process of getting something whitelisted is borderline impossible in many orgs.
Goes to github (if not blocked by net nanny).
View source.
Copy - paste many source files.
Compile and run.
Mwaahahaha, increase productivity 14%.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
