Playing Catch-up, Again

A heap of blogs and articles popped up recently about the shift attackers are making to attacking applications instead of operating systems—Windows especially.  Why?  Ostensibly because operating systems are more secure today, due to vendor design decisions and user/organizational patching efforts.  So the reasoning is that this leaves applications as the weak security link.  Is this really news?  Not really.

In our rush to fight the criminal assaults against our operating systems and LAN/WAN devices, we have typically overlooked applications running on servers and other endpoint devices.  Organizations which tried to assess their ability to patch other applications found themselves hampered by the lack of effective, centrally managed tools.  This is better today—at least for Windows-based organizations—with the introduction of Microsoft’s SCCM solution, but there is still a gap—a big one.

The average medium- or large-sized business might have hundreds of applications spread across hundreds or thousands of end-user devices.  The problem is propagated by the unwillingness of many organizations to remove local administrator access from users who don’t absolutely need it to do their jobs.   Exacerbating the problem is the tendency for IS teams to ignore desktop application patching because it is just “too hard.”

This set of conditions creates a big opportunity for people like Henry B. Hacker (fictional character I made up…).  In the past, Henry focused on Windows to gain access to data he could sell to the highest bidder.  Now, however, Windows is getting harder to crack.  Not because it is completely hardened, but because Microsoft and its customers have gotten smarter about patching and general device hardening.  So Henry, looking for an attack surface with a lower work-factor, is beginning to go after installed endpoint application vulnerabilities.  The general lack of application-level processes and tools deployed across Henry’s target industries results in a rich target environment. 

The application vulnerabilities have always been there.  And no, I’m not just talking about Adobe products or Java.  These high profile applications are typically addressed.  It is the other applications, which are typically not managed by IS, which present the biggest problem.  For example, an entire department might have decided to download and install a cool freeware application they just can’t live without.  A satellite location may have purchased an application, comprised in part by commonly used and potentially vulnerable components, to process protected health information.  On top of all this, many vendors don’t bother issuing patches.  If an organization hasn’t locked down endpoint devices, applications like these have been infiltrating its network for years. 

The effect is the need to once again play catch-up.  As we’ve largely ignored problems associated with “user approved” applications, Henry has been working hard to come up with ways to exploit them.  So I recommend two solutions to the current, well-publicized shift to attacking applications.

1. Deal with existing applications.  If your organization still provides users with local administrator access, you have to assume they’ve installed a large number of applications unknown to you.  Further, you have to make sure those applications IS actually installed and supports are protected.  So the first step is deploying a solution, like SCCM, which can identify and report on installed applications.  Applications like SCCM probably cannot identify all third party applications, but it’s a good start.  Second, develop processes to identify vulnerabilities or patches as they’re announced.  Once of the best resources for this is the National Vulnerability Database.  Another excellent resource, which includes whether patches are available for specific vulnerabilities, is SecurityFocus.  In other words, know what’s installed and deal with it.
2. TAKE AWAY LOCAL ADMIN ACCESS.  It’s doubtful you can track all applications users install on their systems.  The only way to control this problem is to take away their ability to install anything not approved and packaged by the organization.  And let’s not forget that taking away privileged access helps keep bad stuff from installing surreptitiously.