Wednesday, July 29, 2015

Leveraging Your Own Paranoia to Improve Security

My employer has recently begun expanding its sales operations into countries known for their sensational computer security issues.  We're talking countries accused of large-scale hacking, theft of millions of dollars, theft of trade secrets, telephone based scams to bilk consumers, wire fraud, spam, and lots of other crimes.  There is always the potential that our new salespeople, through no fault of their own, might have their computer compromised by someone in their nation intent on breaching our security.  In turn, that computer might compromise our network.

Some of my coworkers think I'm unnecessarily paranoid.  Perhaps I am.  I read stories like those about the breach of Sony Pictures Entertainment, where "insiders" allegedly helped the attackers get into the Sony network.  Once there, they expanded their operations until they had reportedly compromised every significant business system in the place.  The hundreds of gigabytes of stolen Sony information are evidence of their success.  Whether these alleged insiders intentionally cooperated with the attackers or were duped by the attackers in some way is irrelevant.  A sufficiently motivated and skilled attacker could leverage your remote workers without their knowledge, and use their systems as a jumping-off point into your network.  Paranoid or not, that's a potential risk.

I find that it's a worthwhile exercise to read the details of every reported security breach, and then to ask myself several questions, like:

  • How did the attackers get into the network?  
  • Could attackers use that same approach to break into our own network?  
  • If so, what measures can we implement to stop it?
  • If attackers got in this way, how could we detect it?
  • If they get in, how can we limit the damage they do?
  • If we were already breached, how would we be able to determine forensically where they got in?
  • How should we respond as an organization if a breach like this takes place?

I will also ask other questions based on the specific details of a security breach.  For example, attackers in the attack on Sony Pictures Entertainment allegedly had help from an "insider" there. Based on this piece of information, I'm inclined to ask questions like:

  • Are we monitoring for the use of administrator accounts from outside our LAN?
  • Should we have two-factor authentication on administrator accounts?
  • Should we have it on every account?
  • When employees leave the organization, are we identifying all the accounts they might have had access to and disabling them or resetting the passwords on them?
  • Should we be building profiles of user behavior (e.g., administrator account 1 only ever logs in between 8am and 5pm - so flag it for follow-up if we see that account used at midnight)?

In fact, if you're considering any kind of security improvements in your organization, I'd encourage you to read as many published reports of the Sony breach as you can find.  It's a great learning exercise.  I'd also suggest reading the Council on Cybersecurity's Critical Security Controls document.  It provides good framework for evaluating the controls you have in place, identifying those you might need, and prioritizing them.

This paranoia of mine has served me well.  I've developed a few tools based on the details of published attacks, malware analyses, etc., that have helped us avoid a few disasters already.  One tool caught a Cryptolocker process that slipped past our antivirus software, within minutes of it infecting the user's system.  We were able to terminate it and clean up the mess before it damaged anything important.  We've also caught several other "zero-day" malware items.

The trick in leveraging your paranoia as I do is to always balance the level of effort and expense against the amount of risk and damage a potential weakness represents.  The CSC document linked above can be a big help here.

Wednesday, July 22, 2015

It's Not What You Know, But What You Share, That Matters...

Many years ago, I started a new job.  As my new co-workers introduced me to others around the office, they would occasionally tell me something "extra" about that person as we walked away.  They would tell me this one had a tendency to snap at people for asking beginner questions.  That one didn't seem to get along with people who didn't listen to Queen.  More than a few of them were tagged as people who didn't share what they knew.  That's such a basic part of who I am that I could never understand others who didn't share their knowledge.

Yes, on some level I get it.  If you're the only person who knows Technology X, or the only person who's ever maintained "Important Script Y", or who knows the problems with Server Z intimately, then you have value to your employer.  They need X, Y, and Z to work.  The fact that you're the only one who can make them work means that they value your expertise.  If you're worried that they're going to lay you off, maybe you'll keep that knowledge close to your vest to prevent it.  But the problem with this kind of power is that it lasts only as long as X, Y, and Z do.

When Technology X becomes obsolete, as it will do eventually, your special knowledge is worthless to the company.  When there's a better way to do something than Important Script Y, or an off-the-shelf tool for it, you've lost that power base.  And when it's time to refresh Server Z, you can be sure that the people in charge are going to spread that work around to share the knowledge.  All your carefully curated power evaporates.  Worse, by hoarding what you know, you've branded yourself with the unflattering tag of "Not a Team Player" because you haven't shared your skills with your team.

Sharing what you know with others, and teaching co-workers to do what you do, can have many benefits:
  • You are seen as an expert, mentor, and "go to" person for that skill set.
  • You'll be less likely to have your vacations interrupted, since others can fix the problems while you're away.
  • You can add teaching and mentoring to your resume, with specific examples. (In the past, I've had recruiters tell me they were specifically looking for people with a history of mentoring.)
  • You might find that your company asks you to investigate new technologies first, because they know you'll share what you learn with your co-workers.  This will make you more marketable if you do lose your job.
  • There are psychological and social rewards to teaching others.  There is a satisfaction to seeing others learn to do something with your help, and they can sometimes offer insights that help you learn new things, too.
  • When you share knowledge with others, they're more willing to share it with you.  This increases your value to your employer (and future employers).
Sure, there can be downsides.  If you've had a long history of annoying your coworkers, clashing with your management team, etc., your manager may be looking for the right time to get rid of you.  But as noted earlier, sooner or later the technologies your "safety" is based on will become obsolete or marginalized.  New hires might have learned the skills at a previous job.  When that happens, your carefully hoarded skills are no longer protection.  I'd argue that you're much better off working on relationships with your co-workers (and mentoring them can foster such relationships), developing better rapport with your manager, and developing additional useful skills.

In the end it isn't what you, and only you, know that matters.  In IT, technologies become obsolete.  Products change and improve.  People and their skills sets come and go.  Those who share what they know develop better relationships with co-workers, have better opportunities, and quite likely have much longer and more successful careers.  At least, that's how I see it.

Wednesday, July 15, 2015

Silent Uninstall of Certain "Potentially Unwanted Programs"

There are certain programs a user may install on their corporate PC that may be in violation of corporate standards, corporate policy, or acceptable computing guidelines.  When these are found on a user’s system, IT staff will typically either ask the user to uninstall the software or will uninstall the software on the user’s behalf.

While there is not necessarily anything “wrong” with any of the following packages, it’s possible that they violate the organization’s policies and need to be removed.  This document provides instructions for removing this software silently and with minimal user interaction.  Where possible, command lines are given that allow for immediate, unattended, silent removal of the software listed.  Where this isn’t feasible, we’ll list the files and registry keys you can manually (or via a script) delete to get rid of the software in question.

Silent Uninstall Command Lines

Below are known command lines for some potentially-unwanted programs I’ve encountered (these are all single-line commands unless otherwise noted):
  • Amazon Music:
    "%userrprofile%\AppData\Local\Amazon Music\Uninstall.exe" --mode unattended
     
  • BeFrugal:
    "%userprofile%\AppData\Local\Programs\BeFrugal.com\Unins000.exe" /VERYSILENT /NORESTART
     
  • Dropbox:
    "%userrprofile%\AppData\Roaming\Dropbox\bin\DropboxUninstaller.exe" /S
     
  • PriceFountain:
    "%userrprofile%\AppData\Local\PriceFountain\Uninst.exe" /silent /uninstall
For the above, note that "%userprofile%" is the base directory of the user's Windows profile, such as "C:\Users\Fred".  In a batch script, this % value would resolve to the correct path.  In other solutions, you may need to specify the exact path of the user profile.

Ways to Use These Command Lines

If you are logged into the PC with the account that originally installed this software, you can use the command lines to remove the software from the PC by launching a command prompt and running the command line (with the placeholders replaced as discussed above).

If you are an administrator on a PC elsewhere on the network, there are a number of ways you might run these commands.  You’ll need to determine which of these you are comfortable with and which ones are permitted within your organization:
  • Batch File:  Create a batch file that runs the uninstaller command line given in the list above.  You could have the user launch this batch file manually.  You could also place it in their Startup folder to run automatically as they login.
     
  • HKCU RunOnce Key:  If you place the command in the following registry key, it will run one time, automatically, at the user’s next login:
     
    HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce 
    Simply create a new string value here, name it something like “UninstallDropbox” and place in the “Data” or “Value” for the key the command line listed in the previous section.
     
  • Remote Control:  If you use remote control software, you could take control of a user’s session, launch a command prompt, and run the uninstall command that way.
     
  • Client Management Software:  If you use a package like LANDesk to manage
    clients, you may be able to leverage that software’s ability to run things as the user.  In this example, LANDesk would run the uninstall command as the logged-in user and remove the application.
Depending on the tools in use at your organization, you might have other methods not listed above.

Wednesday, July 8, 2015

The Value and the Perils of Consistency and Standards

In general, I'm not a person who craves too much consistency or ritual.  You're not likely to find me doing exactly the same thing every night.  I don't like eating the same food too many meals in a row, taking the exact same route to work every morning, or playing the same music constantly.  I like to shake my brain up by keeping it from getting too comfortable with a routine.  When it comes to my job in desktop administration, though, consistency is important.

Consistency and standards are critical in system administration.  Knowing that things are always configured or installed a certain way, placed in a certain spot, etc., will make your job much easier.  Following standards may not be very fun, but it can keep you out of trouble.  This was something that was drummed into me by two of the original team members, one who moved on and another who retired.  Five years ago, I was the young one on the team.  Now I'm the old guy, trying to teach those same lessons.  Why?

Imagine that you are creating a script to deploy software within your organization.  It's important that you only deploy the software to machines that are currently assigned to a given department within the company, perhaps because it's only useful for certain staff.  Let's also imagine that you keep a field within Active Directory or in the registry of the PC itself that specifies the department to which that machine belongs.

In a world where everyone practices consistency and standardization, your script can check that field in Active Directory or that value in the registry at installation time.  If the machine's assigned to the right department, you do the installation.  If not, you abort.  But what happens in a world where some of your co-workers, maybe on the same team, maybe not, don't practice that consistency or follow those standards?

If you are operating under the assumption that all your co-workers use the standard value "Finance" for this field, you may be in for a surprise.  You might find that the field is blank in some cases, "finance" in others, "fin" in a few, and perhaps even a typo like "fniance"... Maybe some of them don't update the field if a machine switches departments from "Marketing".  Whatever the circumstance, your script is going to miss some machines and possibly even deploy to some it shouldn't.

(This also points out the danger in making assumptions without checking the data.  Chances are good that you have an inventory system which collects that value somewhere.  Before starting your scripting or deployment, it would be wise to check the real values stored in that field or registry key.)

This came to mind recently when I was preparing to deploy some software at work.  There were certain employees who used web sites that were incompatible with the item I was deploying .  Knowing that consistency in system administration is a virtue and not a requirement, I quickly checked my assumption that the ownership information we record in the registry is always accurate.  Imagine my surprise to find that 234 of our systems had missing, incomplete, or totally wrong information about the assigned user of the system.  Had I deployed the software without checking, I'd have caused trouble for potentially dozens of co-workers (which leads to what we administrators refer to as "a very crappy day").

The point here is that administrators need to keep a few things in mind:
  • Never assume everyone is following the standards, or following them consistently.
  • Never assume everyone knows the standards.  Be sure to share and refresh their memory.
  • Before making a significant change, make sure you identify and verify your assumptions. Otherwise, you could wind up with egg on your face.
  • If you notice an inconsistency while working, try to take the time to correct it immediately. Even if it doesn't affect what you're doing, it may help keep a coworker out of trouble or save you trouble in the future.
Have any stories about how inconsistency led to a bad day on your job?  Post them in the comments for others to learn from.


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.

Rebooting

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.