Tom Olzak

Posts Tagged ‘internet’

Executive Order: Improving Critical Infrastructure Security

In Control Systems, Critical Infrastructure, Cyber Espionage, Cyber-warfare, Government, Regulation on February 15, 2013 at 21:03

President Obama issued an executive order (12 Feb 2013) addressing the need for a cybersecurity framework to protect the critical infrastructure of the United States.  You can read the order here...  In theory, it’s what we need.  In practice, how long will it take before politicians weaken the order’s intent to the point that it becomes a meaningless script for staging a ” We really do care” position?

The order includes a directive for information sharing but leaves it to the various departments to decide who to notify, what to declassify, etc.  Based on how slowly our bureaucrats move on anything, an attack will be long over and China will be manufacturing the stolen designs before a notice goes to the potential targets.  Nothing in the order specifies process or technology needed to give timely notifications.  Given how long it has taken the government to understand it has a security problem, the delays in achieving the president’s expected outcomes will likely last far into the next administration… where its eventual demise is highly probable.

The administration is looking for incentives to encourage critical infrastructure owners and operators to carry out recommendations the NIST is requested to formulate.  Incentives?  Incentives for public utilities, for example, will need to be a kick in the pants and the threat of jail time.  If the operators of critical infrastructure really cared, we wouldn’t find ourselves in this mess.  It wasn’t yesterday that security became an issue for anyone with a computer.  There is no excuse for our current situation except heavy lobbying and political career survival practices.

I do hope there is progress on the president’s plan, but I’m not hopeful.  My faith in business and government doing the right thing left the station long ago.

 

 

Facebook employees should know better

In Business Continuity, Cloud Computing, Computers and Internet, Data Security, Insider risk, Java on February 15, 2013 at 20:27

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.

Twitter hacked. So what’s new?

In Access Controls, Password Management, Social Networking on February 3, 2013 at 16:31

Twitter reported last week that about 250,000 customers might have had their usernames, email addresses, session tokens, and password hashes stolen.  This is just one more instance in which the social networking world is shown as having a humongous target on its collective back.  Anyone believing anything is safe when posted on Facebook, Twitter, or any other social network is just kidding themselves.  This doesn’t mean that Facebook, for example, doesn’t care about your information.  What it means is that cyber-criminals are attracted to social networking sites like Trekkers to a George Takei book signing.  (In the interest of full disclosure, I fall into the Trekker category.)

Caution about the credentials used to access these sites is just as important as what not to post: maybe more.  However, the normal user likely uses the same password for Twitter as he does for BYOD devices, bank logins, etc.  Twitter gets it and has tried to inform its customers.  An entry in Twitter Blog reads,

“Make sure you use a strong password – at least 10 (but more is better) characters and a mixture of upper- and lowercase letters, numbers, and symbols – that you are not using for any other accounts or sites. Using the same password for multiple online accounts significantly increases your odds of being compromised.”

If you have users who don’t get it yet, gently help them see the light.

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?

%d bloggers like this: