Wednesday, July 1, 2015

Improving Windows Desktop Security - Patch Management (Part 2)

In the first post of this series (last week), I discussed how to define your patch management process. You need to know what you will and won't patch, who will do the patching and testing, when patching will occur, which machines get patched when (and identify those that won't be patched), and so on.

At this point, I'll assume you've figured the details of your patch process and you're about to look into tools that can help you do the job.

There are lots of patch management systems on the market.  I've worked with two of them professionally, evaluated a third, and heard stories about others.  All have their good and bad points.

Most patch management systems work something like this:

  • An agent is installed on the PC.  This agent scans all the OS, applications, and registry to determine what the machine's current patch state is.
  • The agent transmits this information to a central server, where it's available to administrators for reporting and monitoring purposes.
  • The agent receives periodic updates from the central server, telling it what vulnerabilities or patches it should look for when it scans the PC.  When those vulnerabilities are found on a PC, the agent notifies the server.
  • The agent downloads the patch installers from the central server, and installs them on the PC.
  • At an appropriate time, the agent reboots the PC to complete the patch application.
  • The agent re-scans the PC and reports that the patches are no longer missing (if they applied correctly) or that they are still needed (if the installation failed).
  • Administrators decide how often machines are scanned, when they are patched, which patches are to be applied (and which are not), etc.  The agents take their cues from this.
  • Administrators use the data on the central server to create reports showing current patch status, vulnerable machines, etc., and may "push" patches out to specific desktops to get them current.
Not every patch management tool works this way, but it's usually a variation on this basic process.

Based on my experience using a couple of different patch management tools, here are some of the things I would look for (or think about) when choosing one:
  • Does it have a central repository that I can use to report on patch status, patch availability, vulnerable machines, etc.?  Management and security personnel like it when you can produce reports on-demand showing current patch status.
  • Can you identify whether a specific PC has received a specific patch?  There are times when you will discover incompatibilities after deploying a patch.  Users may report a problem similar to the one caused by the patch, but if the patch isn't installed on that PC, the symptoms have another root cause.
  • Can you group machines into different categories and apply patches differently to each?  For example, maybe you have a sensitive line of business application that can't accept updates to the Microsoft .NET Framework.  If so, you may want to create a group of machines that never receive .NET updates, but receive all other update.  
  • Can you separate the reboot process from the patch process?  You may want to patch laptops during the business day while they're likely to be powered on and connected to your LAN.  You probably do not want to reboot those machines during the business day, however. You may not even want to reboot them at all.  Make sure your patch tool supports that.
  • Can your patch tool wake up machines that have been powered down (Wake on LAN)?  Many companies and employees try to be environmentally responsible, powering off systems at the end of the work day.  If you need to patch them, you'll want to be able to power them on without having to run all over the building to do it.
  • Can you define your own custom patches to the system?  None of the patch tools I've worked with provide patches for every application in use in the organization.  It's good to be able to incorporate patches for other software right into the same system you're using for all other patches.  Similarly, the custom patch mechanism might allow you to run scripts or tools that perform non-patch functions (like checking that system settings are correct, running disk defragmentation tools, backups, or other activities). This can be very handy for general administration work with the PCs.
  • Can you provide the reports and statistics you need to show your management team that a particular patch is fully applied, partially applied, etc.?  Can you show all machines that have, or don't have, a particular patch?
  • Can you run vulnerability scans on-demand to ensure that one or more machines is patched to current levels?
  • Can you place certain patches in an "auto fix" mode so that any machine that checks into the server will receive the patch immediately?  (This can help in situations where machines sit in a closet for weeks or months before being suddenly powered on.)
  • How easy is it to get details (from within the patching tool) about the individual patches, what issues they're intended to fix, etc.?  Links back to vendor knowledge base articles or release notes can be helpful.
  • Are there gateway options that allow you to patch corporate PCs that may be on the Internet but not directly connected to your LAN/WAN at the time?
  • How often does the vendor update, upgrade, and patch the patch management tool itself?  If updates are frequent, will this add to patch workload?

In an ideal world, your patch management tool will also integrate with your hardware asset inventory, software asset inventory, software distribution, and other client management functions.  This will allow you to answer ad hoc questions that will come up like "How many machines have Adobe Acrobat XI installed and received patch MS15-052?"

When you first deploy a patch management tool, you'll probably be overwhelmed by the number of missing patches it finds in your environment.  Don't be.  Realize that these patches have been missing for a while and you had no idea.  Now that you have a clue, start prioritizing the patches and pushing them out.  Before long, you'll be looking at a bunch of well-patched desktops.

Wednesday, June 24, 2015

Improving Windows Desktop Security - Patch Management (Part 1)

Disclaimer:  In this post, I'm sharing what I've learned and done in my own career.  Your needs, and those of the organization you work for, could be quite different.  You may be operating under regulatory requirements that I am not, corporate policies that differ from mine, or knowledge and experience that vary from my own.  In these cases, you should feel free to build on, alter, or ignore anything that doesn't work for you or your organization.  In other words, if doing what I suggest will get you into trouble or cause problems for you, you should ignore me and do what is right for you.

Malware authors make use of flaws in Windows and Windows applications to infect PCs.  One way to reduce the number of flaws available for malware to exploit is to ensure that your OS and software is kept current with service packs, updates, and patches.  If you don't currently have a patch management process in place in your organization, this post should help you design and implement one that will meet your organization's needs.

Through experience, I suggest considering the following things when designing your organization's patch management process:

  • Patching Goals:  You need to know where you're going, and how to tell if you've gotten there. Establishing goals for your patch management activity is the starting point of all the other activity.
  • Patch Process Coverage:  You may decide that you are going to patch and update every piece of software used in your entire environment.  You may decide that you'll only keep Windows, Office, Internet Explorer, Adobe Reader, and Adobe Flash Player current.  The more things you patch, the more effort it will require, and the greater the likelihood of compatibility issues.  On the other hand, the more things you patch, the more secure you'll be.
  • Patch Availability Monitoring:  You can only deploy the patches and updates you know about.  Your patch monitoring process should notify you immediately when there is an update available for the software you use.
  • Patch Testing:  Most of the time patches can be deployed without causing any disruption, incompatibility, or problems for the staff in the organization.  Unfortunately, that's not the case 100% of the time.  A testing process can reduce the odds of deploying a patch that breaks dozens or hundreds of systems.
  • Patch Scheduling:  Where your organization's rules permit it, spreading patch deployment out across a number of days can further reduce the chances of bringing down entire departments or divisions.
  • Patch Exclusion:  You may learn that a particular patch or update breaks one or more applications in your environment.  For example, I've seen Java Runtime Environment (JRE) updates break mission-critical desktop and web applications.  I've seen Microsoft Office patches render Office plugins inoperable.  When you identify these problems, and assuming that you have the option, you want to be able to exclude certain machines from receiving certain patches.
  • Rebooting:  Many patches require a reboot to finish their installation.  End users hate when their systems are rebooted without their consent.  Perhaps this causes them to lose work, or simply means they need to go through many steps to reconfigure their work environment (opening right windows, placing them where needed, etc.).  Unfortunately, reboots are a necessary evil in patch management and you'll want to decide how you're going to handle them.  Will you let the users decide?  Will you force the machines to reboot at a specific time every day, week, or month?
  • Patch Deployment Tool:  As an administrator, you need to know which machines on your network need a particular patch.  You need a tool to deploy that patch to the machines which need it.  You need to track the vulnerabilities in your environment so that you can correct them.  Tools like LANDesk, Altiris, and SCCM can help.

Let's discuss each of these topics in a bit more detail.

Patching Goals

In an ideal world, we would instantly patch every PC for every known vulnerability instantly.  Ours is unfortunately not an ideal world.  

Some PCs may be locked in a closet for weeks on end, where we can't patch them.  Some may be connected to the LAN for minutes or hours at a time, making patch application difficult.  Our tracking system may "remember" machines that have been retired or refreshed (muddying our metrics).  We might apply a patch to a system, but not have a chance to scan the system to prove that the patch has been applied.  In other words, applying 100% of the patches to 100% of our fleet of PCs is probably not a realistic goal.  You'll need to determine what does constitute a realistic goal for your organization.

A good way to come up with the right goals for your organization is to consider:
  • Which machines will be patched?  Are we patching every machine, or are there some machines we will leave unpatched for some reason (e.g., to replicate customer problems)?
  • Which machines "count" and which can be "ignored" for patching purposes?  If there are machines sitting on a shelf, powered off and disconnected from the LAN/WAN, is it necessary for us to power those on and patch them since they aren't a threat until they connect?
  • Is it OK to exclude some machines from our totals, like PCs in other countries that don't connect to the network often enough to be patched, or PCs that are only used during trade shows?
  • If we have to remove a patch from a machine for some reason, how do we account for that in our goals?  Do we count the machine as patched or unpatched?
  • From the moment a patch is released, how long do we have to completely deploy it?
  • Are we concerned only with Critical severity patches, or only Critical and High severity patches, or are we required to deploy every patch no matter its severity or security implications?
  • How will we identify and track patched and unpatched systems?
  • Are there applications we'll patch but not consider part of our goal?
  • Will we deploy patches in a phased manner (e.g., alpha, beta, production)?  Will we deploy them randomly to avoid bias in our approach?
You need to know what you'll patch, when you'll patch it, how you'll track patch applications, and how you'll determine success and failure related to patching.

To give an example, I know an organization which considers a patch "deployed" when its vulnerability scanner says that it's needed on fewer than 7% of their PC fleet.  This gives the organization flexibility in their metrics to handle machines that have been retired, kept offline for a long time, lost/stolen, etc.  Some machines have been exempted from patching for business reasons, and don't count toward the 7%.  Critical severity patches with known exploits in the wild require patching within hours, while low severity patches can be deployed over a period of two or three weeks.  The organization patches only applications which are generally considered to be significant malware targets, such as Windows itself, Internet Explorer, Firefox, Chrome, Office, Java, Adobe Flash Player, and Adobe Reader.  Other software may or may not be patched.

Patch Process Coverage

Part of creating a patch management process is to determine what will and will not be patched.  Depending on your corporate policies or regulatory requirements, you may not need to patch every application in use.  Deciding which applications to patch and which to ignore requires considering and weighing factors such as these:
  • Likelihood of Exploitation:  Malware authors seem to frequently target Windows, web browsers, popular plugins like Adobe Flash Player, Microsoft Office, and other software like Oracle's Java environment.  Software like desktop backup tools or accounting programs might be targeted rarely, or not at all.  If you can't keep everything up to date, it makes sense to focus your efforts on the software that is most likely to be exploited.
  • Risk of Successful Exploitation:  While an accounting program might be an unlikely exploit target, the risk of financial loss to the organization might be huge.  If malware could leverage your accounting software to rob your business of its cash, that risk may outweigh the effort associated with keeping the software current.
  • Frequency of Compatibility Issues:  If applying updates to a particular package frequently causes a large number of staff to be unable to work until the update is removed, you may conclude that the cost of those support incidents to the organization outweighs the security benefit of applying updates to that software.
After evaluating the applications in use in your organization, you should document the items you intend to patch, the items you don't, and the reasoning behind these selections.  This will give you the information you need to determine the next part of the process - Patch Availability Monitoring.

Patch Availability Monitoring

Knowing when patches become available to the software included in your Patch Coverage list is the next piece of the puzzle.  Patch management tools may provide this feature, but it may not cover every software package you use.  In these cases, you'll want to identify an alternate method of finding those updates when they're released.  Some ways you can do this include:
  • Vendor Email Lists:  Many vendors will send you an email when they release security patches and updates to their product.  These emails can be your trigger to download the updates and begin applying them.
  • Secunia PSI:  The Secunia PSI software monitors patch and update releases from many vendors and lets you know when updates are available.
  • Web Page Monitoring:  The Google Chrome extension Page Monitor is an example of this.  The extension can monitor a web page (such as a vendor's downloads page) and notify you when it changes.  This notification can trigger you to download the latest patch.
  • Patch Management Tools:  Your patch management tool may contain functionality for monitoring and downloading the latest patches and updates.
  • Security Web Sites:  There are a number of great security blogs out there which can often notify you when a patch or update is available that addresses security problems.
Ideally, you'll be able to find a way to be notified when a patch is released for every product in your Patch Coverage list.  If you cannot find a way to automate the notification, you may need to manually monitor that vendor's web site on a regular basis to look for patches and updates.

Patch Testing

Testing new patches and updates before widespread deployment is a key piece of the puzzle.  For example, despite Microsoft's best efforts at testing patches, there have been occasions where the infamous "Blue Screen of Death" has been associated with a patch to Windows or another product.  You do not want to find yourself in a situation where many of the computers in your organization can no longer boot, or which blue-screen when a mission-critical application is used.  Patch testing can help you reduce the chances of something like this happening, and can reduce the number of staff affected when it happens.

Once you've determined what you're going to patch and how you're going to identify new patches, the next step is to identify how you're going to test those patches.  Things to keep in mind when designing your testing methodology include:
  • Who will do the testing?  IT staff, end users, or a combination?
  • What tests need to be performed?  Is launching the application enough, or is it necessary to run through all the major functions of the software being patched?
  • Where will tests be performed?  Will you deploy the patch directly on user desktops and let them test on their own PCs, or will you deploy the patch to a virtual machine or shared PC and let the users test there?
  • When will testing be performed?  When will it end?  
  • What will be tested for each application?  Is it enough to see that the application launches?  Will it be necessary to do a complete test of every feature and function in the application?
  • What constitutes a problem severe enough to warrant skipping, delaying, or halting the deployment of a given patch or update?
  • Does the software being patched use plugins, add-ons, or interfaces with other installed software?  Should those plugins, add-ons, or other products be tested as well?
  • How will you determine that a problem reported by an end user is caused by the patch, versus a problem caused by some other issue (such as file corruption, a bad registry key, or permission issue)?
  • How should users report problems with a patch?
  • What happens when a problem is identified with a specific patch?  Is it deployed anyway?  Is it deployed only to users who don't have the affected software?
For example, you might decide that the desktop administrators will test all patches first.  If no issues are seen within the first 24 hours, patches are deployed to a "beta group" of users from across the major functional areas of the organization.  If no issues are reported during the next 24 hours, the patches are deployed to all machines in the organization.

Patch Scheduling

Assuming that your organization has no policies or regulatory rules governing how quickly a patch must be deployed, your next decision is how to schedule patch deployments.  

For example, you might decide that patches identified as critical or high priority should be deployed to as many PCs as possible within 48 hours.  Patches identified as medium or low priority might be deployed over a one-week period.  Patches deployed without a priority rating, or non-security patches, might be deployed over a period of two or three weeks.

Things to consider when determining your patch schedule:
  • Should critical and high-priority patches be deployed more quickly than others?
  • Should patches with known in-the-wild exploits be deployed more quickly?
  • Are there some PCs which should be patched first?
  • Are there some PCs which should be patched last?
  • Should PCs be patched in any particular order?
  • Are there PCs that require a unique schedule (e.g., only quarterly)?
  • Can the schedule be interrupted if serious compatibility issues are identified?
  • Are there applications which we can take longer to patch?
  • Are there applications which should be patched as quickly as possible?
You may also have other patch scheduling concerns, such as avoiding patches during trade shows or avoiding patching during important company events.

Patch Exclusions

Depending on applicable policies and regulations, you are likely to have exclusions to the normal patch process.  For example, you may be able to update the Java Runtime Environment on all PCs except those where Application X is used.  You'll need a mechanism in place to ensure that you never update Java on machines where that application is used.  Things to consider when developing a patch exclusion process:
  • Who makes the call when a machine or user must be excluded from a particular patch?
  • What constitutes a valid reason not to patch a specific machine or application?
  • Where are these exclusions recorded?
  • When are the exclusions reviewed?
  • When are the exclusions lifted, and under what conditions?
  • How will exclusions be implemented to avoid accidental patching?
  • Will exclusions be tracked by specific patch, by application or OS, by user or machine, or by some combination of these?
  • How often are the exclusions reviewed or re-tested for validity?
You may have additional criteria and points to consider.


I don't think I've ever met a PC user who likes to reboot their computer.  At the same time, I doubt I've met any computer users who haven't found that rebooting has at one point or another solved a problem they were having.  In my experience with Windows 7, a PC that has received a patch but has not yet rebooted often exhibits unusual problems or symptoms.  Once the PC has rebooted and the patch is completely applied and activated, the problems go away.  For this and other reasons, you should incorporate a reboot strategy into your patch management strategy.

Things to consider when creating a reboot strategy:
  • Will all PCs be rebooted at the same time, or will only a certain subset be rebooted at one time?
  • Can staff request to have their reboots happen at only a specific date and time?  If so, how is this communicated, recorded, and implemented?
  • Will some machines be excluded from the reboot schedule?  Which ones?  Why?  How will they be tracked?  What if they've been "up" for several months between reboots?
  • Who is authorized to reboot PCs for patching reasons?
  • How will the reboots be performed?
  • When will reboots be performed?
  • Will users have the option to cancel a reboot if they're using the PC at the time?  How will they do this, if so?
  • Will applications be forced to close when the scheduled reboot occurs?
  • Will PCs only be rebooted if necessary?  How will this be determined if so?
This may seem like overkill, but I can tell you that my experience doing patch management for several years in a company showed that people hate having their PCs rebooted.  They will complain of lost work, lost productivity, and any number of other issues.  Similarly, there are staff who will abuse the opportunity to cancel reboots.  Having a documented, consistently-applied reboot strategy will help you to ensure that patches are not only deployed but active on your PCs.  It will also ensure that you can point at a published procedure when someone complains about being rebooted.

In Part Two, Patch Management Software

In the next installment, I plan to discuss patch management software.  I've had the opportunity to work with two different systems during my career, so I have some thoughts about them.  We'll discuss what they are, what they do, how they work, and some of the benefits and problems of automated patch management.

Wednesday, June 17, 2015

Improving Windows Desktop Security - Privilege Management

Where I work, we made the conscious decision when moving from the "everyone's an administrator" days of Windows 95 and 98 to a more locked-down desktop with Windows NT, XP, and beyond.  While it's fair to say that there were some ruffled feathers in the early days of the lockdown, in time everyone adjusted.  Those who had a documented business need for administrator access were granted separate administrator accounts, and those who had no such need were not.

The benefits to a locked-down desktop were many:
  • Malware Damage Reduction:  Before the lockdown, if malware wanted to alter system files, change OS configurations, modify the boot sector, etc., it had no problem doing that.  We often had to reimage systems after an infection got past our other defenses.  Now, with restricted user accounts being the norm, malware very rarely gets further than the profile of the user logged in when the infection occurs.  Reimages because of malware are fairly rare.  Often, we can clean up malware by having the user log off, then removing the files and registry keys it creates.
  • Better License Compliance:  Before the lockdown, staff could pretty much download and install anything that caught their fancy.  Adware, spyware, infected applications, unlicensed software, etc., could easily be installed and run.  While this still happens in Windows 7 when an application installs into a non-standard location, it's far less common.
  • Fewer Configuration Problems:  Before the lockdown, staff could reconfigure the OS anytime, for any reason.  Security settings could be overriden, antivirus software might be disabled or removed, etc.  Between Active Directory Group Policy and the lack of administrator access in Windows 7, staff can't change important settings and compromise the security of their systems.
  • Easier Tech Support:  Because users generally can't alter system configurations, disable security restrictions, or otherwise significantly modify their systems, troubleshooting becomes easier.  Generally speaking, you know how systems are configured.  You know where applications are installed and how they are configured.  You know that the right drivers are loaded for the hardware on that system.  Configurations tend to be standardized and predictable, which can't be assumed when users have the ability to modify things.
  • Reduced Support Calls:  Because users can't "muck up" their systems, there is less chance that they'll do something to cause problems, like install inappropriate drivers, install software that modifies system components, or install conflicting applications.  This reduces the number of problems that less tech-savvy staff can cause for themselves.
But there are drawbacks to a locked-down desktop:
  • More Service Requests:  While the number of problem calls is reduced with a locked-down desktop, the flip side is that there are things staff can't do for themselves.  For example, a salesperson in another time zone can't change his or her system clock.  Users cannot apply automatic updates to application software (e.g., Adobe Reader) when the software prompts them (but this can also reduce problems if an update causes compatibility problems).  Tech savvy staff can be frustrated by the loss of control in a locked-down environment, but in time most will adjust.
  • Support Frustrations:  There are times when the locked-down desktop can make support more complicated. For example, if an employee's VPN software is corrupted or damaged while traveling, the employee can't reinstall it.  Because the machine isn't VPN-connected, support staff can't reach out to it to reinstall it either.  This requires workarounds like having "emergency administrator accounts" defined on the machine.  When a user needs administrator access to solve a problem, you provide the password to this account and then change it after the issue is resolved so that it can't be abused.
  • Software Deployment and Repackaging Issues:  Some software developers assume that everyone using their product has administrator access to the machine.  When running in a restricted user account, this software will misbehave, crash, or fail to work at all.  In some cases, you need to repackage the software so that it installs into an area unprotected by Windows (i.e., not in Program Files or Program Files (x86) directories).  In others, you may need to change file or registry permissions to allow a restricted user to modify these items.  There are some cases where the only solution is to give a user administrator access.
Privilege Management software can help to overcome these drawbacks while still maintaining the benefits of a secure, locked-down desktop.

What is Privilege Management Software?

Privilege Management software runs on the desktop under the direction of policies configured on secure servers.  While the exact features and functions vary depending on the Privilege Management product in use, below are some of the common capabilities:
  • Automatic Privilege Escalation:  The software recognizes that there are certain applications, control panels, etc., that you allow users to run with administrator privileges.  When a restricted user runs one of these items, the Privilege Management software injects an administrator token into the process so that it runs with administrator privileges (even though the user does not have those privileges).  The user doesn't see a UAC prompt.  The software "just works" as though the user was an administrator.
  • Privilege Escalation Request Handling:  If a restricted user wants permission to run something with administrator privileges (e.g., to install a software update), the Privilege Management software allows the user to request permission from administrators.  Administrators review the request and accept or reject it.  If the request is accepted, the user is able to run the application with administrator permission.  If not, they cannot.
  • Auditing of Privilege Usage:  While Windows does log some information on the PC about the use of escalated privileges, it doesn't always log a lot of detail about what the privilege was used to do.  Privilege Management software can often provide much more detailed logs of when, why, how, where, and who made use of administrator privileges.  This can be helpful when investigating problems or security breaches.
  • Reduction in the Need for Administrator Accounts:  Because Privilege Management software can automatically elevate appropriate programs and control panels, it's possible to eliminate some administrator accounts in the environment.  This improves the security of the environment and makes auditors happier.
  • Elimination of Most UAC Prompts:  Because the software adds an administrator token to a running process, there are no UAC prompts generated by Windows. This adds a to tiny bit of productivity and slight reduction in user frustration.
  • Removal of Administrator Privileges in Risky Scenarios:  When an administrator logs into a machine, it can be tempting to launch a web browser to check for information around a problem being experienced or to download an update that is needed for a system.  With so many infections being hidden in legitimate web pages, running web browser with administrator permissions is a significant risk.  Privilege Management software can detect this situation and remove the administrator token from the running process, reducing the potential damage from a web-borne infection.
Features like these make Privilege Management tools an excellent companion to a desktop lockdown effort.  They allow you to grant administrator privileges where they are needed and allow users to do the things they need to do without giving them so much power that they create problems for themselves or the company.

It's common for vendors to bundle Application Control and Privilege Management functionality into a single product.

Privilege Management Products

Following are some of the Privilege Management products on the market.  This is not meant to be an exhaustive list but only a starting point for your research.
You'll notice some overlap here between the Application Control products discussed in the previous post and the Privilege Management tools discussed here.

In the next post, we'll talk about Vulnerability Scanning and how it can be used to improve desktop security.

Wednesday, June 10, 2015

Improving Windows Desktop Security - Application Control

In the introductory post last week, I talked about the Council on Cyber Security's "Five Quick Wins."  These are a set of five security controls that provide the most bang for the buck.  The first control that the CSC recommends implementing is Application Control.  Application Control, from the perspective of a Windows Desktop Administrator, includes the following functions:
  • Inventorying the applications installed on your desktops
  • Preventing malicious software from running
  • Preventing unauthorized or unlicensed software from running (that isn't malware)
  • Tracking software usage
  • Eliminating obsolete and unused software from the environment
These functions make Application Control products a valuable component of your desktop security plan.

Solving or Reducing "Zero-Day Malware"

Even the very best antivirus software on the market isn't perfect.  The bad guys have a very large bag of tricks to help them slip malware in past your defenses and onto your PCs.  The key to preventing a serious security breach is to be able to stop as much of it as possible, and to detect anything you miss as quickly as possible.  The longer a given unit of malware is resident on one of your systems, the more time the bad guys have to gather intelligence about your network, spread the infection, or do any number of other things.  You want to eliminaet this "zero-day" malware as quickly as possible.

I built a tool which scans the processes running on our company's fleet of PCs, comparing them to known and acceptable software.  Anything unrecognized is flagged for review.  The good news is that this has helped us catch at least a dozen items already this year that slipped past our other defense measures.  The downside is that it found over 1,000 other items that weren't malware, but still had to be analyzed and whitelisted or removed.  Each of these had to be examined, scanned, and listed.

This is an area that Application Control software can help with.

The Role of Application Control in Dealing with Malware

Application Control software generally offers both whitelisting and blacklisting functionality.  Whitelisting identifies the applications that you have authorized for use in the environment.  Blacklisting identifies those items that should not be allowed to run in your environment.  Blacklists can include malware, but can also include things that violate your corporate policies, such as games, streaming music software, or cloud data synchronization.

Application Control sits between the user and Windows.  Before any application is allowed to run, the Application Control software intercepts it and compares it to the whitelist and blacklist.  Blacklisted applications are (or rather "can be") prevented from running.  Whitelisted applications run normally.  

Applications not on either list are usually subjected to some kind of evaluation.  The different Application Control products handle this evaluation in any number of ways including:
  • If the application is digitally signed, and the signature is from an authorized source, the application would be allowed run even though it does not appear on the whitelist.
  • If the application isn't digitally signed, but matches certain other criteria, it is allowed to run.
  • The user is allowed to run the application anyway, but the usage is recorded for later investigation by administrators.  No blocking takes place, only logging.
  • The user is shown a "challenge response" prompt and must call the help desk to get a code which enables them to run the software.
Which options are available depends on the product you select and the settings you choose in that product.  It's common to operate in a "log only" mode for a while as you build a whitelist of accepted software, then flip on the application blocking functionality to provide protection.

When a zero-day malware item is launched where Application Control is active, the malware should fail the whitelist evaluation process and be prevented from executing.  Even when the configuration allows the malware to run, its execution will be recorded in a log somewhere and can be investigated by administrators.

Once an item of zero-day malware is identified, it can be blacklisted and prevented from running in the future.  This can provide protection in cases where antivirus software hasn't yet been updated to block the threat.

Other Benefits of Application Control Software

While Application Control software can help you prevent zero-day malware, it has other benefits:
  • Prevent users from running unauthorized software, like streaming media players, BitTorrent clients, hacking tools, insecure versions of applications, and portable applications
  • Prevent users from running unlicensed software, like legitimate applications brought in from home or downloaded from the Internet
  • Prevent the installation of unwanted software
  • Restrict access to applications based on a variety of criteria (such as time of day)
  • Improve software license compliance
Many Application Control products also include Privilege Management functionality, which we'll talk about in the next post in the series.

Available Application Control Products

Following is a list of some of the Application Control products on the market.  This is not meant to be an all-inclusive list, and the appearance (or omission) of any product on the following list should not be seen as an endorsement by me.  The list is provided as a starting point to assist you in your own evaluation activities.
In the next post, we'll talk about Privilege Management Software... what it is, what it does, and how it can help you improve the security of your desktops.

Wednesday, June 3, 2015

Improving Windows Desktop Security - Introduction

The organization I work for has begun expanding its operations outside the United States, into some of the countries known for experiencing a lot more malware than we tend to see here at home.  This planned expansion has given me pause, as a Windows desktop administrator, to think about our existing security measures and how those can be improved.  A third-party audit conducted last year provided some recommendations.  I discovered many more in the Council on Cyber Security's (CSC) document "The Critical Security Controls for Effective Cyber Defense Version 5.0" (hereafter the "CSD document").

Before I continue, understand that this post focuses strictly on Windows desktop issues.  In my organization, and I suspect in many of yours, desktop administrators do not have the authority to mess with the perimeter firewall, change network router settings, web filtering systems, etc.  Those things are all critical parts of a "defense in depth" strategy.  Omission of those items is not meant to imply that they have no purpose in your security architecture, but rather that they are outside my sphere of influence and experience on the job.  If you are concerned about them, refer to the CSC document for recommendations in those areas - as well as other qualified resources.

The CSC document lays out 20 controls that will greatly improve security in an organization.  Five of these controls are described as "Quick Wins" which deliver the most security improvement relative to their cost (financial and staff time).  
  • Application whitelisting
  • Use of standard, secure system configurations
  • Patch applications within 48 hours
  • Patch system software within 48 hours
  • Reduce the number of users with administrative privileges
Our existing environment and experiences necessitated some modification to the CSC recommendations.  For us, the first five controls to address were:
  • Application Control software (whitelisting, blacklisting)
  • Privilege Management software (allowing a more granular granting of privileges, enabling a reduction in the number of administrator accounts, and being able to audit when and where privileges were being used)
  • Reduction of our patch window to 48 hours for the most critical software
  • Shortening of the patch window for less critical software
  • Implementing regular vulnerability scanning
The reason our list varies a bit from the CSC advice is that we'd already handled some of their first five.  That enabled us to bump a couple of items up that we thought offered significant value.  For example, our software development teams have long lamented the lack of administrator privileges.  Privilege Management software would allow us to grant them more freedom than they had, while also allowing us to improve security and auditing around privilege use.  

For obvious reasons, I'm going to have to be vague in many places in this discussion.  Sharing the internal security details of your organization online is in itself a security risk.  Suffice it to say that we have a solid "defense in depth" strategy in place already, with coordinated efforts from a dedicated IT Security group and a variety of administrative areas.  All the protections you probably imagine us having, like firewalls, antivirus software, and the like, I can assure you... we do.  This effort has been about improving the existing security, not implementing security where none existed before.

In the next post, I'm going to talk about Application Control software.  We'll cover what it is, what it does, how it works, why you would want it, and how it improves your security.  In future posts, I'll cover Privilege Management, application patching, and vulnerability scanning.

Wednesday, May 27, 2015

Implementing a Locked-Down Desktop

When my organization used Windows 95/98 systems, there wasn't a good solution for locking down the desktop.  Because of that, we had all kinds of problems.  Our users would things like:
  • Download and install software they shouldn't (e.g., trial versions, products from home, unsupported tools, drivers).
  • Get malware infections that spread from one machine to another.
  • Uninstall or disable their antivirus software because they thought it slowed down the PC.
  • Uninstall or disable their firewall.
  • Modify security settings for Windows itself, making malware infection more likely.
  • Bring devices and drivers in from home that crashed the company PC.
We made the decision when we switched to Windows NT 4.0 to lock down the desktop and not grant users administrator access.  This implied a number of changes to things:
  • Users would have to call us for things that they might have done for themselves in the past.
  • We would have to install all software, updates, and drivers for the users.
  • Some staff would need to be granted power user or administrator access due to job specific needs.
  • Some staff would complain that they no longer had the freedom they had enjoyed with Windows 9x.
At the same time we implemented the lock-down, we also implemented remote control software to allow our help desk staff to actually see the customer's problem and help them without having to run to their offices.  In the end, fewer than 10% of the staff could justify the need for administrator access for business reasons.  A few of the remaining 90% complained about a loss of flexibility, but most were happy to be able to just call the help desk and get things fixed for them.

Some of the benefits we've accrued from the lockdown include:
  • Fewer malware infections overall
  • Because staff run from standard user accounts, malware is typically confined to a single user profile when it does infect a system, making cleanup easier
  • Certain infections, like the Conficker worm that spread from one machine to another, barely registered on our radar.  (I think maybe one or two systems got the infection, but it didn't spread.)
  • Since users can't change security settings, systems retain their secure default configuration
  • License compliance improved significantly, since users could not install "any old thing" anymore
  • Although the number of help desk calls went up briefly as users adjusted to the situation, the locked-down configuration actually reduced help desk calls by eliminating some of the sources of past problems (such as users downloading the wrong drivers and installing them, or applying incompatible software updates)
  • Support became easier, because you could assume (within reason) that every machine was configured to the corporate standard, used a consistent set of drivers, etc.
When I talk with colleagues at other companies, I'm often forced to shake my head in sympathy.  They tell me how a user installed infected software off the web that corrupted the machine so badly it had to be reimaged.  They talk about how a software audit left them in trouble because users installed things the company wasn't licensed for.  They talk about hackers getting in because someone opened an infected attachment that gave the hackers administrator control over the box.  They tell me about long nights spent cleaning up any number of problems.  I don't have many stories to share with them, because we don't have those kinds of problems.

A locked down desktop isn't a panacea.  You do still wind up with issues you have to deal with:
  • Although Windows 7 prevents standard users from installing software into the Program Files directories and Windows itself, users can still install software into their own user profiles.
  • Software that may require licensing, but is delivered in a zip file, can be used without installing it.
  • Malware still gets in, and gets past antivirus - it's just (usually) easier to cleanup
  • Some staff need applications that require administrator access, and you have to work around those, sometimes by adjusting file/registry permissions, sometimes by providing ways to launch the application with administrator permissions
  • Some staff try to fight the lock-down by bringing in devices from home (e.g., Macs or personal laptops), and you have to be prepared to deal with this - especially if the devices are connected to the corporate LAN
  • Despite corporate policies to the contrary, staff will still bring in USB devices with portable applications, portable hard drives, and other peripherals from home
  • No matter how flexible you try to be and how much power you offer users short of administrator access, there will always be some staff who complain that they would be "much more productive" if they had administrator access.  If they can demonstrate a true business case for it, our IT Security people will usually approve the request, so this is more a nuisance than a real problem.
If you are considering locking down your corporate desktops, here are some things you'll want to think about and do:
  • Determine the process and criteria for justifying the need for administrator access.  Under which conditions will you provide this access to your staff.  Who will approve the requests?  How will you create and name administrator accounts to distinguish them from standard accounts?  How, and how often, will you review the accounts and the need for them?
  • Consider disabling auto-update features in applications, as users may no longer be able to apply the updates.  If they are unable to apply the updates, this can cause annoyance (from the constant alerts to update) and frustration (at the inability to apply the updates).
  • Test all of your applications under a standard user account to ensure that they run properly.  You may find that you need to adjust file, folder, or registry permissions to get them working. You might even have to install them outside the Program Files folders.  Failure to properly test the software is something that could quickly kill your lock-down effort.  (Sysinternals Process Monitor can be a big help identifying where permissions changes may be needed.)
  • Test all of your standard peripherals and devices to ensure that they work properly.  Few devices trigger a UAC prompt for administrator credentials, but they do exist.
  • Establish a policy that administrator accounts should only be used as needed.  Web browsing, reading email, and other mundane activities should be conducted from a standard user account to avoid system-wide infection.  Decide how your organization will handle violations to this policy.
  • Consider implementing application control and privilege management software, such as Arellia, Avecto, or Dell Privilege Manager.  This products can prevent users from installing and using unauthorized software, and can also eliminate the need for many administrator accounts by automatically elevating sensitive applications to administrator (for users who have only standard accounts).
  • For users who will be granted administrator accounts, how will you audit what those users do with the accounts?
  • How will you implement the lockdown?
    • Will you give users a standard account and an administrator account, then expire the administrator account after some period of time?
    • Will you deploy the lockdown in conjunction with an operating system upgrade (e.g., Windows 7 to Windows 10)?
    • Will you implement the lockdown gradually across the organization, or all at once?
    • How will you notify the users about the lockdown?
    • How will you identify and troubleshoot application problems resulting from the lockdown versus those occurring normally because of issues with the software?
You may identify other issues specific to your organization that you want to test or document before implementing a lockdown.

Wednesday, May 20, 2015

Should you use software auto update features?

A lot of security advice I've seen recently urges companies to enable auto-update mechanisms built into the software they use, such as the auto-update services for Adobe Flash Player and Oracle's Java Runtime Environment.  The reasoning behind this advice is sound.  It tends to be along the lines of "Once you turn on this mechanism, you won't have to worry as much.  The service will keep your PCs on the latest release, with all the latest bug fixes and anti-exploit technology, so you'll be much safer."  While I agree with this thinking in principle, I'm not sure that I'm as comfortable with it in practice.

Every few days, we hear about another security breach.  The web servers at Company X have been hacked, and the bad guys have stolen account information, passwords, credit card numbers, or personal data.  Sometimes the bad guys break into a site, like a popular blog or new site, not to steal anything from the site but to spread malware onto visitors' computers.  It's this point that makes me leery of auto-update tools.  Why?

Imagine that you're the system administrator responsible for 2,000 PCs.  You decide to make your job a little easier by allowing Adobe Flash Player to update itself as new releases become available.  With all due respect to Adobe, we've all seen how frequently the bad guys have been able to find exploits in Flash Player, Adobe Reader, and other products.  This is the same company that's maintaining a web site and/or FTP site to distribute Flash Player updates.  If the bad guys find a chink in Adobe's armor and manage to get their garbage into the auto-update repository, what happens next?  Your 2,000 PCs reach out to Adobe's site, find a new "update" and deploy it immediately.  Suddenly, all 2,000 of your PCs are infected and doing the bidding of that malware author.  That's a cleanup job none of us wants to tackle.

Now, let's imagine that the vendor's security is rock-solid and no one ever breaks into their update sites.  You're still managing that network of 2,000 PCs.  Let's imagine we're looking at the Oracle JRE now.  You've turned this on to allow automatic updates.  Overnight, Oracle releases a new JRE.  Your 2,000 machines dutifully download and install this update.  This time it's a perfectly malware-free update.  The problem is, you've got critical internal applications written in Java that are broken by a security fix contained within this new JRE.  Staff who don't use that application are still having trouble, because it's blocking certain Internet sites they use from running Java applets.  The help desk is flooded with calls and you're looking like the bad guy.  Yet again, you have another mess to clean up.

Even when both of the above situations don't happen, these mechanisms present some other issues:

  • There are probably a hundred different applications in use at our company which have some kind of auto-update option, including products from Adobe, Mozilla, Google, Microsoft, and others.  If all these were enabled and running, PCs would be constantly polling for updates, consuming some amount of CPU, disk, and network resources.  All of this would in addition to the components in our patch management system.
  • If you're following good security practice, your end users generally don't have administrator access.  Some of these auto-update mechanisms assume that the user does have administrator permission.  If you enable auto-updates for these users, they'll have to call your help desk every time an update comes out, so that it can be installed for them.
  • Although many of these auto-update mechanisms randomly disperse their update-checking times (e.g., PC1 might check at 3:00am, PC2 at 3:05am, and PC3 at 3:06am), some do not.  This means that all of your PCs will reach out at once to the vendor's site to check for, download, and apply the update.  If this happens during work hours, your network bandwidth could take a sizable hit.
  • We've all seen stories about how one update or another has caused a problem.  A Windows Update might cause a blue-screen at reboot.  An antivirus update might cause the AV product to crash or classify itself as malware.  A bug in the update might cause the application to stop working.  When this happens to a few of your users, it's a nuisance.  When it happens to 2,000 at once, it's a crisis.

I'm not suggesting that no organization, under no set of circumstances, should ever turn on auto-updating.  All I'm saying is that you want to analyze and weigh that decision carefully.  Some of the factors you might want to consider include:

  • Do I think it's likely that this vendor's web or FTP sites could become compromised and used to distribute malware?  If so, it may be wise not to enable auto-updates.
  • Are the vendor's auto-update installers digitally signed and encrypted or hashed, so that even if a malware operator gets access to the update distribution point, it won't do them any good because their code will be unsigned or will provide a bad hash to the update mechanism?
  • How are update checks scheduled in the product?  Can we stagger them out so that the entire fleet of PCs isn't trying to update the software at one time?
  • Do the update installations require administrator access?  Do our users have that access?  If they don't, do we really want to field the calls this will create?
  • Is the risk of infection from an exploit of the product (e.g., Flash Player) greater to us than the risk of the distribution point being compromised by the bad guys?
  • Do I have the necessary tools, resources, and procedures to handle updating this software in a timely manner already?  If so, it may be better to use my existing tools.  If resources are limited, the potential risks of using auto-updates may be less than the costs of distributing the updates myself.
  • Are there corporate policies or regulations that require me to enable auto-updates, or require all updates to be applied to systems within a certain timeframe?  Can I meet that requirement without auto-updating?
  • How often are you seeing malware infections that exploit this particular software?  If you're seeing such infections daily, auto-updating might help reduce the frequency.  If you're rarely seeing the software exploited, you might disable it.  (Note that this isn't always easy to know because malware vendors don't always share information about the vulnerability that malware is exploiting - and they may not even know for sure.)
  • How often do updates appear for this product?  You may decide that, over time, the effort involved in deploying all the updates for a given product is outweighed by the possible effort involved in a cleanup of a hypothetical infection distributed through the auto-update mechanism.  Perhaps the updates are so infrequent that you don't want to be bothered with deploying them yourself?
  • Do you have large numbers of machines that are frequently disconnected from your LAN?  If so, auto-updating may be a valuable way to keep them current.  If all your machines are always 

You may have other criteria you wish to consider in your evaluation.

It's also important to note that auto-update mechanisms usually aren't an "all or nothing" or "every PC or no PC" option.  You might conclude that it's better to enable automatic updates for your overseas staff and remote workers, to ensure that the updates go to them in a timely manner - while turning them off for the bulk of systems inside your headquarters.  You might decide that it's worthwhile to have auto-updates enabled for Flash Player because it's a common infection vector in your organization and the risk of a problem is low, while disabling them for Java because you have too many applications that are dependent on specific older releases of the software.

In my organization, we have a centralized patch management tool which can deploy patches for any software we use.  We use that patch management tool to deploy updates to our entire fleet of PCs and virtual machines.  The most serious patches are deployed as soon as possible after release.  Slightly-less-critical patches are deployed within 48 hours of release.  Patches with low criticality are deployed gradually over a period of a week or two from release.  We disable most auto-update mechanisms by default, to reduce the incidence of software compatibility, infection, or crash problems, but do enable some auto-updates.  For example, sales staff, remote workers outside our main offices, and machines not joined to our Windows domain have auto-updates enabled for certain software that is often exploited.  These machines are typically harder for us to patch with our normal tools and processes, so the auto-update mechanisms enable us to keep those machines current even when we can't reach them.  Antivirus updates are automatic, too, to maximize the protection they provide.

My point isn't that auto-update mechanisms are inherently bad or good, or that they should always or never be activated.  I'm only suggesting that before you enable one, you take a serious look at the potential risks, costs, and benefits of enabling it.  If you decide that risk and cost is low relative to the benefit, then by all means enable it.  If not, turn it off.