Thursday, February 25, 2010

A dissection of Koobface

There is a very informative analysis of the social network trojan Koobface at abuse.ch. The analysis details the four stages of the victim infection, which involves malicious shorts links, registering false Blogger accounts and hijacked web sites serving out malicious javascript. At the time of writing (early December last year), there were just over 34,000 malicious blogposts and short URLs, directing victims to over 500 hijacked websites. Ultimately code is downloaded onto the victim machine to make it part of the Koobface command & control infrastructure.

A CAPTCHA breaking infrastructure is used to register new accounts with Blogger, as shown below.

image 

According to the post, the infrastructure is very sophisticated:

  • The time between grabbing a CAPTCHA and breaking it is less than three minutes (most of the time just a few seconds!)
  • Due to the way how Koobface’s infrastructure works, it’s possible to break hundreds of CAPTCHA per minute!
  • In this way it’s possible to register thousands of fake bit.ly/Blogspot accounts per day

The author wonders if the security industry is placing too much faith in CAPTCHAs.

Tuesday, February 23, 2010

Major Risks in the IT Industry

Researchers at the University of Wisconsin, from the Actuarial and Insurance department, conducted a study on risk terms in 2007. The study involved comparing notions and definitions of various terms in risk across several sectors and industries, including Information Technology (IT). The IT respondents listed the following major risks for their industry (click to enlarge)

image

The researchers noted that the IT sector had the largest number of risks. By way of comparison, the major risks for the energy industry looked like this

image

Notice that IT Failure risk is on the list but very much towards the bottom.

Metrics for Managing Project Risk

I was in a bookstore over the weekend and saw of copy of Identifying and Managing Project Risk by Tom Kendrick from HP. The book was published last year but I know of his work on project risk metrics from an earlier whitepaper that really showed how to get a handle on measuring and managing project risks.

Here are some examples of predictive risk metrics which serve as a distant early warning system for project difficulties.

Project size/scale risk

  • Project duration (elapsed calendar time)
  • Total effort (sum of all activity effort estimates)
  • Total cost (budget at completion)
  • Size-based deliverable analysis (component counts, number of major deliverables, lines of non-commented code, blocks on system diagrams)
  • Staff size (full-time equivalent and/or total individuals)
  • Number of planned activities
  • Total length (sum of all activity durations if executed sequentially)
  • Logical length (maximum number of activities on a single network path)
  • Logical width (maximum number of parallel paths)

Schedule risk

  • Activity duration estimates compared with worst-case duration estimates
  • Number of critical (or near-critical) paths in project network
  • Logical project complexity (the ratio of activity dependencies to activities)
  • Maximum number of predecessors for any milestone
  • Total number of external predecessor dependencies
  • Project independence (ratio of internal dependencies to all dependencies)
  • Total float (sum of total project activity float)
  • Project density (ratio of total length to total length plus total float)

General risk

  • Number of identified risks
  • Quantitative (and qualitative) risk assessments (severity analysis)
  • Adjusted total effort (project appraisal: comparing baseline plan with completed similar projects, adjusting for significant differences)
  • Survey-based risk assessment (summarized risk data collected from
    project staff, using selected assessment questions)
  • Aggregated overall schedule risk (or aggregated worst-case duration estimates)
  • Aggregated resource risk (or aggregated worst-case cost estimates)

And the last example, the Dilbert Correlation Factor: collect 30 recent Dilbert cartoons and circulate to staff. Have people mark each one that reminds them of your organization. If the team average is

  • under 10: Low organization risk.
  • 10-20: Time for some process improvement.
  • Over 20: Hire a cartoonist and make your fortune….)

Sunday, February 21, 2010

Simplified implementation of the Microsoft SDL

Microsoft has announced a new 17-page whitepaper that presents a simplified version of their Security Development Lifecycle (SDL). From the announcement

One of the common misconceptions about the Microsoft SDL is that you have to be an organization the size of Microsoft in order to be able to implement it. Another misconception is that the SDL is only appropriate for Microsoft languages and Microsoft platforms, and that you need to use some other methodology if you’re writing code with Ruby for OS X. The Simplified SDL white paper helps address these misconceptions by explaining how the SDL can be implemented with limited resources and applied to any platform.

image

Why use SSL?

Here is a short introductory post on the advantages of using SSL, and a nice FAQ as well. Cost and performance are listed as the main disadvantages. However you may want to also check out How to Render SSL Useless from Ivan Ristic and the additional comments here at Pat’s Daily Grind.

image

When to use Pie Charts

image

from Emergent Chaos.

Saturday, February 20, 2010

Lew's Law: IT expenses converge to the cost of electricity

Interesting:

Last week I heard Sun Microsystems Cloud CTO Lew Tucker predict that IT expenses would increasingly track to the cost of electricity. “Lew’s Law” (as described to a room of thought leaders) is a brilliant theorem that weaves a microcosm of IT trends and recent reports into a single and powerful concept.

Lew’s Law is a powerful idea whose time has come, with profound and far reaching impacts, including the automation of the network.

Full story here from Gregory Ness with some additional remarks here.

image

Friday, February 19, 2010

An Anonymity computation using R

Back in August 2008 I posted on some research I did on traffic confirmation attacks. Traffic analysis is a collection of techniques for inferring communication relationships without having access to the content that is being communicated. Traffic confirmation is a special sub-case that attempts to infer communication relationships amongst users whose communications are mediated through an anonymity system.

The graph below shows two curves representing the observed frequency of recipients from a MIX anonymity system. The attacker is targeting a particular user Alice, and the red curve represents the minimal number of times her communication partners are observed, while the blue curve represents the maximal number of observations for all other recipients. The graph is created from an anonymity system with N = 20,000 users, using a MIX of batch size 50 and assuming Alice has 20 communication partners.

image The graph shows that after the attacker has observed about 250 messages from Alice, each of her recipients has been observed more often than any of the other recipients. Therefore an attacker can conclude that the 20 most frequently observed recipients are the recipients of Alice, and the anonymity of her partners has been broken. The details are explained in the previous post.

What surprised me was how easily the data for this graph could be programmed in the R programming language. The native vector operations of R makes this all very simple, and the code is below.

b = 50
N = 20000
m = 20
Nset = c(1:N)
mset = c(1:m)
N.plot = 0
m.plot = 0
m.min = 0
N.max = 1
s = sample(N, b, replace=T)
s = c(s, sample(mset,1,replace=T))
for ( t in c(1:500) )
{
    s = c(s, sample(Nset, b, replace=T), sample(mset,1,replace=T))
    ts = table(s)
    m.min = min(ts[c(1:m)])
    N.max = max(ts[-c(1:m)])
    N.plot = c(N.plot, N.max)
    m.plot  = c(m.plot, m.min)
}
plot(m.plot, type="l", col = "red")
lines(N.plot, col = "blue")

FSA Security Controls for protecting Customer Data

In April 2008 the Financial Services Authority published their recommendations for protecting customer data. From the Executive Summary

This report describes how financial services firms in the UK are addressing the risk that their customer data may be lost or stolen and then used to commit fraud or other financial crime. It sets out the findings of our recent review of industry practice and standards in managing the risk of data loss or theft by employees and third-party suppliers.

At just over 100 pages, the report details controls and best practices in the following areas to protect customer data

  1. Governance
  2. Training and awareness
  3. Access rights
  4. Passwords and user accounts
  5. Monitoring access to customer data
  6. Data back-up
  7. Access to the internet and email
  8. Key-logging devices
  9. Laptops
  10. Portable media including USB devices and CDs
  11. Physical security
  12. Disposal of customer data
  13. Managing third-party suppliers
  14. Internal Audit and Compliance monitoring

Thursday, February 18, 2010

How to write an Information Security Policy

Nice 9-page advice from the UK Department of Trade and Industry.

image

Six Myths in Assessing Risk

Great 1-page summary with graphics from business advisory firm Corporate Executive Board

  1. The biggest risk my company faces is financial risk
  2. My company is safe because we review risks and
    prioritize mitigation efforts annually
  3. We are good at risk-sensing because we have invested in
    3 enterprise risk management (ERM) systems
  4. We are well protected because we have a strong
    quantitative model to measure risk
  5. Our risk assessment is comprehensive because we
    account for likelihood and impact
  6. We can sense and protect business better because we manage risks at the business unit (BU) level

Friday, February 12, 2010

AON 2010 Political Risk Map

Here on Scribd.

image

Another source of USB Randomness

Back in December I posted about a new USB device with dedicated hardware for producing a continuous stream of high entropy bits based on sampling P-N junctions. Another lower tech randomness source with a USB interface is described at this site, and is shown below

image The device has a small hourglass, and as the sand falls from the upper to the lower chamber, the pattern of grains is sampled against a light-sensitive detector at a rate of 100 times per second. The site claims that each sample yields about 9 bits of entropy based on statistical tests. The device detects when all the sand has passed to the lower chamber and then rotates the hourglass 180 degrees, so the sampling process can continue. The samples can be accessed through a USB interface.

The device is a prototype, and as yet not for sale, but costs about $100 to produce. The advantage of the hourglass method over other more sophisticated and higher yielding devices is simplicity and transparency. Perhaps so, and you can read more about the design here, and the entropy of the output here. Finally

While the hourglass is not precise, accurate, or repeatable as a timekeeper, and has been almost completely supplanted by better devices, it is a good source of random entropy. It is still manufactured in quantity at low cost, and it is clean, compact, durable, and uses little energy. The source of the random entropy can be easily understood, and observed to be functioning correctly without instruments. An off-the-shelf photointerrupter can be employed to electronically observe the random entropy, and an open-source, standardized microcontroller can be used to control the process and interface it with a host computer.

Monday, February 8, 2010

How to Render SSL Useless

This is the title of a recent talk from Ivan Ristic of SSL Labs on common mistakes in the deployment of SSL. This talk expands upon his SSL Threat Model that I posted about a few months ago. The main deployment mistakes Ristic sees for SSL are
  • Self-signed certificates
  • Own CA certificates
  • Mixing SSL and plain-text
  • Not using secure cookies
  • Using incomplete certificates
  • Not using EV certificate
  • Not using SSL
  • Mixed page content
  • Different sites on 80 and 443
  • Using SSL for “important”bits
  • Inconsistent DNS configuration
This is a great presentation which really gets to the heart of why SSL security has lately been the focus of much attention.

(via SSL Shopper)

Saturday, February 6, 2010

Get your Faraday Bag

Get your Faraday bag here. This is not a gimmick site, as these people are aiming at UK law enforcement, who need to shield mobile phones after seizure. You can view testing results here.

image