Tom Olzak

Archive for the ‘Data Leak Prevention’ Category

The Internet is Broken, Part II: NetFlow Analysis

In Application Security, Computers and Internet, Cybercrime, Data Leak Prevention, Data Security, Forensics, Insider risk, Log Management, NetFlow, Network Security, Policy-based access control, Risk Management, Security Management on January 13, 2013 at 21:52

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 1: Cisco NetFlow Configuration

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

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.

Three controls to deal with a broken Internet…

In Application Security, Business Continuity, Computers and Internet, Cybercrime, Data Leak Prevention, Data Security, Log Management, Network Security, Risk Management, Security Management, SIEM on January 4, 2013 at 17:24

The Internet is broken.  Browsers are gaping holes in our security frameworks.  Certificates are becoming a liability as cyber-criminals or certificate authority negligence weakens our trust in the process.  If we continue to see defense only in terms of preventing the bad guys from getting to our end-point devices, we will surely lose the security war.  The answer is to shift perspective.

First, it’s important we assume that every end user device is potentially infected.  Further, we must assume that one or more of the servers in our data center are infected at any point in time.  This might not be true for all organizations, but it is a smart baseline assumption.  Once we accept that we are vulnerability and likely infected, it is easier to begin supporting preventive controls with comprehensive methods to identify, contain, and manage inevitable breaches of security: SIEM, NetFlow, and response.

Over this and the next two articles, I will take a high-level look at each of these breach-control methods.  Further, I will provide links to resources providing detailed information about how to design and deploy them.

SIEM

SIEM (security information and event management) is a comprehensive approach to assessing system and network behavior.  It requires collection of logs from various devices across the network, including firewalls, IPS/IDS, servers, and switches.  The graphic below depicts a very simple SIEM architecture.  Logs collected by each device are sent near-real-time to a Syslog server.  “Syslog is a standard for computer data logging. It separates the software that generates messages from the system that stores them and the software that reports and analyzes them” (“syslog”, 2013).  This is known as log aggregation.

SIEM Architecture

SIEM Architecture

Aggregated logs are sent to a correlation server for analysis.  The correlation server looks at all events received from across the network and attempts to mine attack patterns or other anomalous behavior.  Anomalous behavior identification is only effective if the SIEM solution is properly tuned.  In other words, the correlation server must know what patterns are normal for your network and which fall outside alert thresholds you set.  For more information about correlation in general, see event correlation at wikipedia.org.

All relevant information is usually available via a portal.  For example, a SIEM management server might post updated correlated results every five to 10 minutes.  Events meeting criteria set by you can also cause alerts to be sent to administrators and security personnel via SMS, email, etc.

Logs can tell us a lot about behavior, but they fall short of providing insight into how data is actually moving across the data center or across our network segment boundaries.  This is the topic of the next article in this series: NetFlow (IPFIX).

References

Syslog. (2013) Wikipedia.org.  Retrieved January 4, 2013 from http://en.wikipedia.org/wiki/Syslog

Policies are not enough to protect mobile data…

In Access Controls, Application Security, Content Filtering, Data Leak Prevention, Data Security, Mobile Device Security, Policies and Processes, Policy-based access control, Risk Management, Security Management on December 29, 2012 at 12:27

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.

Ready for the Hordes? You’d Better Be…

In Access Controls, Business Continuity, Data Leak Prevention, Data Security, Mobile Device Security, Policies and Processes, Risk Management, Security Management on November 3, 2010 at 10:35

The battle rages as users fight to get their smartphones connected to your network.  As many have written, it is futile to fight against the hordes beating on your door.  So whether the user currently demanding access uses an iPhone, a Blackberry, or an Android device, there are a few basic principles to follow before opening the gate.

First, make sure you can centrally manage all handheld devices that connect.  Yes, this includes user-owned devices.  If you allow them to connect to company email or the company’s internally facing WiFi network, then you have some additional rights.  The most basic of these is the right to wipe lost or stolen devices.  This also includes wiping any user-owned device in the possession of a departing employee.  They don’t get to take data along to the next employer…

RIM provides this in its enterprise server offering.  iPhone and Android phones are manageable via Microsoft Exchange.  It doesn’t matter how you do it, but place a policy in place, wrap some processes around it, and enforce central management across all devices–including those owned by C-level managers.  Yes, they lose their phones, too.

The other must-have security control is central policy management.  Again, if data for which you’re responsible is on a device, you have the responsibility to protect it.  So creating mandatory password or PIN policies is a necessary part of handheld device security.  No, your users won’t like this.  But, hey, it’s sensitive data.  They need to compromise a little.

Next, if you allow handhelds to connect to your network, you have to protect yourself from slowly emerging malware threats.  No, there aren’t a lot now.  But there weren’t a lot of viruses around when PCs first started appearing on desktops.  Maybe if we’d paid more attention then, we’d have less problems how.  In any case, it is never too early to start looking at packages available from all the major anti-malware solution vendors.  And make sure whatever you select is centrally manageable.  Not all vendors get this yet.

Finally, consider encrypting sensitive data on the phones.  Yes, I understand that many encryption solutions for handhelds are easily cracked.  So does that mean you do nothing to protect your data?  Let’s face it, the password or PIN protection isn’t much either.  The best way to prevent data breaches caused by compromised phones is to follow a very basic rule–don’t put allow it to be put there in the first place.

There are other things you can do, but these are the “absolutely must-haves,” in my opinion.  Hold off the hordes until you have the right infrastructure in place and broad support for your efforts.

Blank SQL Password? Are you kidding me!?

In Data Leak Prevention, Data Security, Hacking, Insider risk, Risk Management on April 14, 2010 at 10:22

Ok.  Maybe the properly validating input would cost the brokerage more than the $375K settlement and the loss of business due to loss of customer confidence.  I doubt, but who knows.  And the cost of an intrusion/extrusion prevention system might be outside their budgetary constraints, while encryption is not always practical.

But actually assigning a strong default password is FREE.  Simple negligence?  Lack of proper change management processes?  Security team on vacation?

Brokerage coughs up $375,000 for website breach • The Register.

%d bloggers like this: