Tom Olzak

Archive for the ‘Hacking’ Category

The Internet is Broken, Part III: Response

In Application Security, Business Continuity, Disaster Recovery, Hacking, Log Management, malware, NetFlow, Network Security, Policies and Processes, Risk Management, Security Management, SIEM on January 20, 2013 at 23:12

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

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

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 Kinect Hack Compendium

In Hacking, Hardware, Microsoft on March 6, 2011 at 20:16

See The Kinect Hack Compendium! – Yahoo! News.  Maybe this is a reason for Microsoft to try some approach to open-source for these products.  The base technology seems capable of so much more…

Android security…?

In Application Security, Certificates, Cybercrime, Data Security, Hacking, malware, Mobile Device Security, security, Security Management on March 6, 2011 at 20:09

A recent blog, Frequency X Blog, examines the latest Android malware, DroidDream.  The hole that allowed this is as big as they get.

Government Dysfunction Strikes Another Blow for Insecurity

In Access Controls, Business Continuity, China, Cyber Espionage, Government, Hacking, Network Security, Password Management, Policies and Processes, Risk Management, Security Management, Vendor Management on October 12, 2010 at 12:51

For many years, even before the Internet, changing default access codes, passwords, and other vendor assigned information was considered a basic no-brainer.  And I understand normal people (non-IT) not getting it.  After all, if it wasn’t a good password, why would a vendor assign it…?  And who wants to argue with a support guy on the phone who can’t understand why you changed it?  I get it.  However, when our government doesn’t see the value in the change, we have a big problem.

According to an article last week in the New York Times,

[University of Michigan researchers] infiltrated the District of Columbia’s online voting system last week. They changed all votes for mayor to Master Control Pro and elected HAL 9000 the council chairman. The blaring University of Michigan fight song played whenever a new ballot was successfully cast” (Wheaton, 8 Oct 2010).

To be fair, this is a pilot project by the District’s Board of Elections.  However, I always thought “pilot’” meant seeing how it works in the real world.  So it should also mean setting security for testing system trust.  One reason why this is necessary was included in the same article:

“[Professor J. Alex Halderman] said he also saw signs that computer users in Iran and China were trying to crack the system’s master password — which his team obtained from an equipment manual. (Network administrators had never changed the four-character default password.) He said that the foreign hackers were probably not specifically trying to break into the District’s voting system, but that they represented a threat nonetheless” (ibid.)

In addition to immediate attempts by our “enemies” to hack into the system, we decided to practice global good will by leaving the vendor password in place for anyone who wanted into our system.  What a novel idea regarding how to meet the cyber-crime and warfare challenges we increasingly face.

In case you haven’t yet gotten the message across to your network engineers or internal support personnel, this might be something you can use as an attention-getter (instead of the bat you’ve placed strategically next to your filing cabinet.

This is just one more example of the dysfunction of our government information handling capability.

Emergency patch for ASP.NET vulnerability

In Cybercrime, Data Security, Hacking, security, Security Management on September 29, 2010 at 14:28

According to H Security, this ASP.NET vulnerability should be patched as soon as possible.  The patch, MS10-070, is available from Microsoft as of 2/28/2010.

The vulnerability can be remotely exploited to read specific ViewState values and cookies and to download files from a server without possessing the necessary authority. The Padding Oracle Exploitation Tool (Poet) is able to take advantage of this kind of vulnerability. Affected products include Microsoft SharePoint 2010, SharePoint Foundation 2010, Microsoft Office SharePoint Server 2007, Windows SharePoint Services 3.0 and Windows SharePoint Services 2.0.

via Emergency patch for ASP.NET vulnerability on its way – The H Security: News and Features.

%d bloggers like this: