MIT Report Troubling

In a recent report (MIT Report: U.S. Manufacturing Hits a Wall When It’s Time to Scale), Curt Woodward writes that a group of MIT researchers discovered an almost impassable chasm when looking for investment dollars.  The investment dollars were for needed for 150 production companies wanting to move to full-scale production, and they were only available from foreign investors or if moved off-shore.

Why is this a security issue?  Because it has been clear for a long time that no one wants to build manufacturing plants in the US.  I’m not talking about steel mills; rather, the 150 companies (many started or supported by MIT students, professors, etc.) focused primarily on hi-tech products.  Just what we need… move all hi-tech production–the kind of production that is crucial to our economy and our national security–off-shore or make it vulnerable to the whims of foreign investors.

I don’t care whose fault this is; we spend far too much time in this country pointing fingers when we should be sitting down together to solve problems.  China is laughing is collective butt off as it steals our intellectual property and increasing builds our technology.  I just don’t think it’s that funny…

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).

 

 

Controls: The absolute minimum

Lulled into false security by years of being told anti-malware is the best way to protect networks and devices, many network administrators  leave their networks wide open.  Using only anti-malware software a firewall, and an IPS leaves gaping holes in the security controls framework.  Attackers with limited experience can locate and exploit attack vectors with little regard for these venerable controls.  While firewalls and IPS devices help, they were never intended to provide a complete prevention/detection/response solution.

SANS provides an up-to-date list of 20 critical security controls (now at version 4.0).  The downloadable documentation provides guidance on in depth, layered integration of controls necessary to fill gaps left by traditional approaches to minimal security.

The Internet is Broken, Part III: Response

This is the final post in a series about the broken Internet.  In the first, we looked at SIEM.  Last week, we explored the value of NetFlow analysis.  This week, we close with an overview of incident response.

When evaluating risk, I like to use as reference the following formula:

Basic Risk Formula

Probability of occurrence, broken into threats x vulnerabilities, helps us determine how likely it is that a specific threat might reach our information resources.  Business impact is a measure of the negative affects if a threat is able to exploit a vulnerability.  The product of Probability of Occurrence and Business Impact is mitigated by the reasonable and appropriate use of administrative, technical, and physical controls.  One such control is a documented and practiced incident response plan.

The purpose of incident response is to mitigate business impact when we detect an exploited vulnerability.  The steps in this process are shown in the following graphic.  Following the detection of an incident (using SIEM, NetFlow, or some other monitoring control), the first step is to contain it before it can spread or cause more business impact.  Containment is easier in a segmented network; segments under attack are quickly segregated from the rest of the network and isolated from external attackers.

Response Process

Following containment, the nature of the attack is assessed.  Failing to follow this step can result in incorrectly identifying the threat, the threat agent, the attack vector, or the target.  Missing any of these can make the following steps less effective.

Once we understand the who, what, when, where, how, and why of an attack, we can eradicate it.  Eradication often takes the form of applying a patch, running updated anti-malware, or system or network reconfiguration.  When we’re certain the threat agent is neutralized, we recover all business processes.

Business process restoration requires a documented and up-to-date business continuity/disaster recovery plan.  Some incidents might require server rebuilds.  Business impact increases as a factor of the time required to restore business operation.  Without the right documentation, the restoration time can easily exceed the maximum tolerable downtime: the time a process can be down without causing irreparable harm to the business.

Finally, we perform root cause analysis.  This involves two assessments.  One determines what was supposed to happen during incident response, what actually happened, and how can we improve.  The second assessment targets the attack itself.  We must understand what broken control or process allowed the threat agent to get as far as it did into our network.  Both assessments result in an action plan for remediation and improvement.

The Internet is broken.  We must assume that one or more devices on our network is compromised.  Can you detect anomalous behavior and effectively react to it when the inevitable attack happens?

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.