Facebook employees should know better

While I believe that posting any private information to a social networking site is… well… nuts, I also believe we should have a reasonable expectation of privacy.  This means companies like Facebook must do a good job of protecting themselves from potential attacks.  So why were laptops used by Facebook employees targets of a recent zero-day attack?

Yes, it was zero-day.  We can’t foresee all possible attack vectors.  The threat agent used a hole in Java to infect the laptops.  Further, the Java exploit was setting on a developer site.  Doh!  Didn’t see that coming, Facebook?  You should have.

Java is full of holes.  It is an exploit waiting to happen, and it is not the first time attackers circumvented the Java sandbox to get at the underlying platform.  Some, like Andrew Storms at nCircle Security, believe Java needs a complete overhaul (via Gregg Keizer, Computerworld).

 “Oracle should just take a mulligan and redesign Java before everyone completely loses faith in it…”

Apparently, Facebook didn’t get the memo.  Why would a social network company allow its employees to visit risky sites and then connect back to a network where customer and other sensitive data reside?  Why would any organization?

For more information on end-user device security, see Chapter 6 – End-user Device Security.

Home users create security gaps: Fill them

In Phishing attacks target home workers as easy ‘back door’ – Techworld.com, John Dunn writes that users fear becoming targets when working at home.  This should surprise no one.  With the rapid growth of BYOD (bring your own device), organizations struggle to close security gaps as they attempt to meet new business requirements of anywhere/anytime delivery of information and business processes. (See The BYOD Trend.)

Smartphones, tablets, and privately-owned laptops are not adequately controlled in most organizations.  Traditional access controls, especially authorization constraints, fail to mitigate risk sufficiently.  One important change organizations can make is to context- or policy-based access controls.  (See Securing Remote Access).

 

 

The Internet is Broken, Part II: NetFlow Analysis

Last week, I introduced the broken Internet, with SIEM technology as a way to help identify bad things happening on your network.  This week, I continue this theme by looking at a technology often deployed with SIEM: NetFlow analysis.

NetFlow is a protocol developed by Cisco.  Its original purpose was to provide transparency into traffic flow for network performance and design analysis.  Today, however, NetFlow has become a de facto industry standard for both performance and security analysis.

Over time, security analysts found that event correlation alone might not be enough to quickly detect anomalous behavior.  NetFlow, in addition to a SIEM portal, allows quick insight into traffic flow.   It helps detect network behavior outside expected norms for a specific network.

NetFlow compatible devices, as shown in Figure 1, collect information about packets traveling through one or more ports.  The collected information is aggregated and analyzed.  If supported, alerts are sent to security personnel when traffic flow through a switch port, for example, exceeds a defined threshold.  (See Figure 2 for a portal example.) This is a good way to detect large data transfers or transfers between a database server and a system with which the server doesn’t usually communicate.

Figure 1: Cisco NetFlow Configuration

Figure 2: NfSen Screen Shot (Retrieved from http://www.networkuptime.com/tools/netflow/nfsen_ss.html)

For example, assume an attacker gains control of a database administrator’s (DBA) desktop computer.  All access by the DBA’s system will likely look normal: until a NetFlow analysis alert reports large amounts of data passing from a database production server, through the DBA system, and to the Internet.  (Granted, other controls might prevent this altogether… humor me.)  The alert allows us to react quickly to mitigate business impact by simply shutting down the DBA computer.

It isn’t just external attackers NetFlow helps detect.  The infamous disgruntled employee is also detectable when large numbers of intellectual property documents begin making their way from the storage area network to an engineer’s laptop located in his or her home office.  NetFlow analysis can be particularly useful when two or more employees collude to steal company information.

NetFlow analysis is a good detection tool.  It helps support prevention controls we rely on to prevent connections to unknown external systems.   In addition, NetFlow alerting can call our attention to an employee defecting from policy compliance and violating management trust.

Next week, I conclude this series by examining incident response in support of SIEM and NetFlow analysis.

Policies are not enough to protect mobile data…

Policy is not enough.  Ensuring sensitive information is handled in accordance with internal policy and regulatory constraints requires monitoring of all activities associated with it.  In other words, inspect what you expect… continuously.  Further, too much reliance on human behavior is a recipe for security disaster.

This week, we learned that the University of Michigan Health System, via a vendor, lost about 4000 patient records.  The vendor, apparently authorized access, copied patient records from a database to an unencrypted device.  The device, left unattended in a vehicle, was then stolen.  Sound familiar?  It should.  This scenario appeared many times in news articles over the last several years.  While the players differed, the gaps leading to the losses were largely the same.

This set of conditions is growing more common.  They are strengthened with an increasing number of devices filling the role of insecure mobile data storage, as the BYOD (bring your own device) phenomenon continues to complete its hold on business operations.  Managers and business owners who believe they can simply write a policy, train employees, and move on to the next challenge are kidding themselves.

(For a detailed look at how competing interests apply pressure every day to employees trying to do the right thing, see Bruce Schneier’s Liars and Outliers.)

So what can we do to protect ourselves from becoming the topic of yet another subject in an article about mobile data loss?  Plenty.

For traditional access control environments…

First, ensure your policies have teeth.  For example, what are the sanctions for a vendor or employee who fails to follow policy?  Next, implement reasonable and appropriate technical controls to monitor traffic (e.g., IPFIX data) and aggregated logs (i.e., SIEM).  IPFIX, for example, provides near real time information about anomalous data flows: like a vendor copying 4000 records from a database.  Finally, implement a process whereby IPFIX and SIEM alerts prompt an immediate review of who did the copying, what they copied the data to, and whether the target device is in compliance with policies addressing data on the device category into which it falls.  For example, if security sees a data transfer to a mobile device, they should confirm that the device is encrypted and the user authorized to carry the data out of the building…

For policy-based organizations…

As BYOD expands the corporate attack surface, policy-based access controls augment the steps listed above.  By default, do not allow anyone to copy data to a mobile device that does not meet policy requirements for data protection.  Policy-based controls authorize user access based on user role, the device used, the location of the user/device, the data and processes accessed, day of the week and time access is requested, and the device’s compliance with security policy.  All of this is automated, preventing reliance on human behavior to protect data.

(For more information on policy-based access controls (also known as context-based access controls), see Chapter 9: Securing Remote Access. )

Again, policies are not enough.  Without technical controls, they rely on human behavior to protect data.  This is a bad idea.  Instead, implement technical controls as far as is reasonable for your organization, and then monitor for compliance to ensure people, processes, and technology are producing expected security outcomes.

Permissions Creep: The Bane of Tight Access Management

Organizational role changes are common.  People are promoted, move from one department to another, or responsibilities change for the roles they’re in.  The result over time, commonly known as permissions creep, is a bunch of user accounts for which least privilege and segregation of duties no longer apply.  The solution is a documented and aggressively followed job change process.

First, let’s look at the issue of job changes.  A job change process should use an authoritative source, such as your human resources system, to track role changes.  If you assign a job code to each employee based on his or her position, then this is pretty easy.  One approach is to compare a nightly extract, including employee ID and job code to the previous night’s run.  A difference in job code indicates a change in position.  If your HR system produces a report listing job changes, then you already have what you need.

For organizations with an automated provisioning system, the next step is easy.  Feed the changes to the provisioning server and let it do its thing.  Otherwise, hand it off to a system administrator for manual changes to directory services and all relevant applications.  Whether automated or manual, the process is the same.  For each affected account, remove all current access and replace it with the approved access for the new job role.  This assumes you’ve defined access by application, AD group, etc. for each job code.  If you haven’t, this is a big job so you’d better get started…

Some admins might simply reverse access based on the original role.  This is not effective, especially for an employee who’s been around a few years.  Exceptions to base access settings may have been added over time as the employee’s manager added additional responsibilities not commonly given.  Changing responsibilities causes problems, particularly when an employee’s job never changes and the job change process isn’t invoked.

If you have employees who have worked for your organization for many years, especially those who demonstrate the ability to perform a wide variety of tasks, they have probably been given special permissions in addition to those approved for their organizational role.  These exceptions were likely approved by a data owner and are on file for the auditors.  So far, so good.  However, the dynamic nature of business inevitably shifts these responsibilities around, removing the need for access but not the actual access itself. 

Dealing with permissions creep caused by variable responsibilities over time requires actual reviews of employee access.  Schedule periodic reviews by data owners, managers, etc.  Use the results of these reviews to adjust access to reflect employee job responsibilities today.

Finally, there is the question of location.  For non-healthcare organizations (HIPAA free), this might not be a problem.  However, when you have to manage patient information visibility based on role and location, access reviews take on an additional dimension.  Make sure reviews and job changes take into account where the employee is working and adjust need-to-know controls accordingly.

Managing permissions creep isn’t exciting, but it is a necessary part of securing information assets.