Monthly Archives: December 2004

The Intent of a Tank

Posted on by

“We used to talk about the intent of a tank,” Colonel Thomas explained in an interview. “If you saw one, you knew what it was for. But the intent of electrons – to deliver a message, deliver a virus, or pass covert information – is much harder to figure.”

Ian Grigg points out an interesting article in the New York Times on the difficulty of gathering data to monitor the net.

The article mentions spammimic and draft messages and how to use an ATM to send messages. (The article doesn’t mention that you can create a reasonable codebook of up to about a thousand messages by using deposits, or 100,000 messages if you deposit coins as well as bills.) And as long as we’re discussing clever steganography, has anyone investigated how many spare bits are in those Hallmark musical cards? It should be possible to add a little data in there, or even replace the chip with a smarter one. Who could tell the difference?

All reasons why bulk surveillance is going to have to be replaced by messy, difficult, targeted infiltration. Of course, if John Walker Lindh can do it, the CIA and FBI should be able to, too.

Database Flaws More Risky Than Discussed

Posted on by

Rob Lemos has an article in CNET about NGSSoftware. On Thursday, they
released
a
slew
of
advisories
about
Oracle
products
with
flaws NGS had discovered 3 months ago. Now, it turns out that the problems may be more risky than thought. Alternately, the release of the exploit code may have cause SecurityFocus to raise its threat estimate.

Now, on the one hand, these issues, and their patches, have been known for a while. Anyone really interested could use binary diffing tools, by folks like Halvar Flake (400k PDF), or Todd Sabin. So a company attempting to use risk management techniques for patching has had quite a bit of time to test, wait for a patching window, and then apply the patches. In the meanwhile, they’ve been vulnerable to a small number of competent attackers and their associates who’ve known since the patches came out how to exploit. Anyone who waits for an exploit to become public in a case like this is likely to become a victim.

However, it’s also possible that the vendor’s choice of how to characterize the risk was either incorrect, or chosen to put them in the best light. Without the technical data about the exploit being easily available, there’s no check on the vendor’s assessment. So the risk management numbers may well have given the wrong result: A ‘high’ risk vulnerability that should have been patched may have been labeled ‘medium,’ and a customer with a low cost of downtime may have decided to accept the risk of being attacked, rather than the risk of system change.

On a closely related note, folks who release a fully automated compromise of XP SP2, or IE overflows on Christmas eve are being poor sports. Whatever you think of Microsoft’s security practices or of full disclosure, there’s little reason to put millions of people at risk by releasing an advisory when people who would write the fix are presumably on vacation, as are the people who would install a fix.

[Update: Put in link to Todd Sabin's work.]

Keynote can’t Export to Web?!?

Posted on by


I was just playing with Keynote, working on some slides for Shmoocon, when I realized that I couldn’t get my slides onto the web! Now, I’ve griped about how Powerpoint makes its slides for the web, but at least it makes them.

It seem that Tim Bray figured this out a while ago, but I missed it. Others comment that it should be possible to move from XML to HTML, but it’s still just a wishlist item.

Do any of the free software packages have a solid presentation creator, with good export to powerpoint and web?

Winning the Battles, Losing the War

Posted on by

A historian, Isaiah (Ike) Wilson III, Ph.D, gave a talk a few months ago at Cornell, entitled “Thinking Beyond War: Civil-Military Operational Planning in Northern Iraq.” His basic thesis seems to be that, in contrast to a carefully planned and executed war campaign, there were no definitive plans for what to do after the Iraqi army collapsed. “In short, there was no operational plan for the post-offensive because the postoffensive phases were viewed as someone else’s mission” is how he summarizes his thesis. This is all made more interesting because he’s not some bleeding-heart peacenik, but a Major in the US Army:

From April to June 2003, this author chronicled the war effort as a researcher and a primary writer for the Chief of Staff of the Army’s (CSA’s) Operation Iraqi Freedom (OIF) Study Group. This assignment offered great opportunity to view the execution of combat operations from a frontline vantage point, to conduct formal interviews with soldiers of every ground unit (US Army, US Marine Corps, and UK Forces) engaged in the march up country to Baghdad and record their experiences and lessons gathered. From July 2003 to March 2004, this author participated more intimately in the war effort, serving as the chief of plans (chief war planner) for the 101 st Airborne Division (Air Assault). In this capacity, this author participated in and led the planning of combat (offense; csupport, and civil reconstruction efforts in northern Iraq.

He characterizes the state of affairs on the ground today:

The lack of an endstate-driven campaign plan prior to the commitment of combat forces in Iraq has contributed to the present state of civil-military affairs in Iraq: a Coalition Provisional Authority (and now a “sovereign” interim Iraqi government) lacking long-range vision and the know-how to put into action those goals and objectives its has figured out thus far, and a combined and joint military force with the expertise in getting things done – be it destruction or reconstruction – yet hobbled by a lack of resources, a lack of a winning plan and strategy, and an over-abundance of misdirected bureaucratic “assistance.”

His report is in two major parts, the pre-war planning, and the experience of the 101st Airborne division in Northern Iraq. That Northern Iraq hasn’t fallen into disarray is actually impressive: The Kurds would like nothing more than to secede and start their own country. There’s a substantial Baathist regision. Turkish special forces were scattered throughout. He explains why, and proposes ways to improve things, both in the rest of the country, and in US military doctrine and training.

I feel a little bad in that he asks we not cite his work without permission. But these are important policy questions, and the document was on a public web site. The entire report is worth reading if you care about why we are where we are.

Now all of this was drawn to my attention by an article in the Washington Post, Army Historian Cites Lack of Postwar Plan:

Army Gen. Tommy R. Franks, who as chief of the Central Command led the war planning in 2002 and 2003, states in his recent memoir, “American Soldier,” that throughout the planning for the invasion of Iraq, Phase IV stability operations were discussed. Occupation problems “commanded hours and days of discussion and debate among CENTCOM planners and Washington officials,” he adds. At another point, he states, “I was confident in the Phase IV plan.”

A rank amateur in the art of reading statements written by media consultants would think that the Major and the General are contradicting each other. But they’re not. Wilson argues that the planning was insufficient, chaotic, and missed important factors for organizational reasons. Of course Franks, as a participant in the system, didn’t see these flaws at the time. Of course he was confident: If he wasn’t, the plans would be revised until he was. But were the plans critiqued, and did those critiques reach his ears? Wilson says no.

[Update: James Fallows has a long piece in the Altantic on the war, and post-war planning process.]

Banks issue 2 factor auth

Posted on by

There’s a story in today’s CNET about banks issuing authentication tokens (like SecurID cards) to customers to address customer authentication issues.

While these are useful, insofar as they will make phishing harder, they won’t stop it. Phishing will transform into an online, at the moment crime, which will be easier to catch, but work by Amir Herzberg and Ahmad Gbara or Ian Grigg demonstrates how to solve the problem. (Having the browser remember certificates could also help.) For what banks will spend to ship and support these id tokens, they could fix the browsers, and require upgrades, like they used to for 40-bit SSL.

If you’re going to use a token, its worth considering something like the WikID ones, which are mobile-phone based.

Oh, wait, I’m repeating myself. Dang.

More on SSNs and Risk

Posted on by

In writing about Delta Blood Bank earlier today, one of the issues I was thinking about was the unnecessary use of social security numbers, and how it’s an industry standard. One area where this is particularly evident is in the bifurcated market for cell phones. At one end are providers like Virgin and MetroPCS, who sell low-end, no-roaming plans. (Although, really, if you don’t need to roam, and can accept their poor network, MetroPCS’ $40 all you can eat nationwide is quite a deal.) At the other end are the nationals, such as AT&T or Tmobile, all of whom insist on doing a credit check and using your SSN as a password after they’re done. Now, these companies do offer pre-paid, no credit deals, but they stink.

I’m trying to figure out why companies don’t let you buy whatever plan you’d like, on whichever system you prefer. There are minor technical difficulties, like running out of money on overage, but the advantages, which I’ll outline shortly, seem to outweigh them.

The first advantage is in cash flow. If a customer prefers to pre-pay, the company gets their money 60 days earlier. They don’t have to borrow that cash, and can earn interest on it. If all a company’s customers switched to paying earlier, then it would save 1/6th of its annual interest payments, and get interest on about the same amount of cash. (Assuming that the company holds the cash until it delivers the service.) That’s not chump change. Now, the accounting treatment may be a little different. (This is based on a conversation with Samablog, who knows more about accounting than I ever hope to. Errors mine.) That’s because selling accounts receivable is somewhat easier if you haven’t delivered service yet. If you don’t deliver, the bank doesn’t collect, but it’s also not liable for delivering anything. So you get a slightly better rate for the receivable than you do selling your pre-paid income stream.

The second advantage is in liability. If you’re not loaning a customer money, you fall under fewer rules like GLB (FISMA) or SB 1836.

The third advantage would be in privacy, meaning here perceived ID theft risk–by not asking for this information, it’s clearly impossible to abuse it.

One disadvantage is you can’t sell your customer’s personal information so easily. Does that compensate? Are there others? If not, why is no one doing this?

Delta Blood bank

Posted on by

Delta Blood Bank sent a letter Friday to donors, warning them a computer that held their personal information had been stolen and advising them to take steps against identity theft and credit card fraud.

…

In addition to the letter…The blood bank will no longer require Social Security numbers from its donors…

No longer require social security numbers? Why were they required in the first place? Using social security numbers as an ID number (or password) has been a bad idea for a long time. As Chris Hibbert pointed out in 1994:

Database designers continue to introduce the Social Security Number as the
key when putting together a new database or when re-organizing an old one.
Some of the qualities that are (often) useful in a key and that people think
they are getting from the SSN are Uniqueness, Universality, Security, and
Identification. When designing a database, it is instructive to consider
which of these qualities are actually important in your application; many
designers assume unwisely that they are all useful for every application,
when in fact each is occasionally a drawback. The SSN provides none of them,
so designs predicated on the assumption that it does provide them will fail
in a variety of ways.

Of course, the costs of that the bad design were borne by customers, not the organization. Further, the SSN choice was a standard, and so hard to fight. Now, new rules like SB 1386 push some of the cost of that choice back where it belongs.

If your organization does business in California and collects, or over-uses SSNs, now would be a fine time to talk about bad PR and other costs of doing business that way, and push to make a liability-reducing change.

(From News.com.com.)

Ripping into ROI

Posted on by

Over at TaoSecurity, Richard Bejtlich writes:

‘ROI is no longer effective terminology to use in most security justifications,’ says Paul Proctor, Vp of security and risk strategies for META Group…

Executives, he says, interpret ROI as ‘quantifiable financial return following investment.’ Security professionals view it more like an insurance premium. The C-suite is also wary of the numbers security ROI calculators crunch.
‘Bottom line is that most executives are frustrated and no longer interested in hearing this type of justification,’ Proctor says. Instead, express a technology’s or program’s business value, cost/benefit analysis and risk assessment.”

Well, of course. ROI has enormous problems, including an assumption that technology works out, that there’s an infinite pool of free capital to draw on, etc. Techniques such as economic value add allow you to take some of these into account. But the biggest problem is that quantifying the cost of a breach is hard. Without knowing what the alternative is (to reserve or insure), its hard to justify much security spending. Computerworld has a good story “Where ROI Models Fail,” or see CIO’s “The Trouble With ROI” Roundtable for more on these issues.