The death of text CAPTCHA? I hope so…

In a Yahoo article posted yesterday (Internet advertisers kill text-based CAPTCHA – Yahoo! News), Mike Wehner writes about possible changes to text CAPTCHA hell.  Yes, I said hell.  I am nearing my sixth decade of life on this planet, and I sometimes have to give up and make a phone call when trying to use some of the inane CAPTCHA  implementations I encounter.  I am willing to suffer a second or two with ads to select.

I am not alone in my journey through the CAPTCHA quagmire.  According to Wehner, negotiating a CAPTCHA takes an average of 14 seconds.  Some take much, much longer.  This is leading some companies out of the swamps and toward ad-based verification.

Solve Media is the big player in this space, and the graphic below demonstrates how ad-based CAPTCHA works.  Instead of typing meaningless drivel, she enters text related to the displayed product.  Easy and designed to drill product messages into our heads.

From Solve Media Video

I know.  Just one more way to commercialize the Web… but I don’t care.  If I can cut CAPTCHA frustration while helping vendors carry out Turing tests, I’m OK with this.  How about you?

 

 

YAWN!!!!

Another article from AP today about the U.S. vulnerability to cyber attacks.  No longer news, this kind of information is simply depressing.  Mike Rogers, a member of the House of Representatives, believes that 95% “of private sector networks are vulnerable and most have already been hit.”  Maybe, but nowhere does the article offer actual statistics or source research.  Further, no mention is made of the porous security protecting government agencies.  Figures…

Rogers contends that all the government has to do is share classified threat information and all will be well.  What is he smoking?  Everyone already knows what is needed to protect our national infrastructure.  This looks like a good copout by Republicans: protecting business by doing something useless while convincing the gullible they are doing something worthwhile.  Compromising national security isn’t necessary; all we have to do is start forcing the slackers to meet minimal security requirements.  The Feds should start with their own minimal security guidelines included in FIPS PUB 200.

In my opinion, this grandstanding by legislators needing another law passed to prove their value (God knows something has to) is not helpful.  What is helpful is applying meaningful efforts to identify weaknesses–can anyone say public utilities–and apply the necessary pressure to remove them.  This must happen without whining about cost to affected businesses and industries.  My MBA helps be understand the business side, but my common sense and sense of insecurity drive me to scream, “ENOUGH!!”

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.