Stolen EFF docs at WIPO negotiations

The EFF is doing a great job trying to prevent bad law from being created at a global level. There’s a bizzare story of EFF docs being stolen and trashed to prevent their message getting out. Cory writes:

We ended up posting a guard over the table — thanks to Rufus Pollock from the Campaign for Digital Rights for yeoman duty! — and rescuing our papers from the trash and from reserve stashes. Unfortuately, we couldn’t make any more copies because the UN Secretariat — who administers logistics — has announced that as of this meeting, non-governmental organizations (NGOs) can no longer have their materials photocopied by WIPO.

Well, of course. WIPO can’t be sure who owns the copyrights on those pages. As Mr. Gibson said, the future is already here, its just unevenly distributed.

Security & Outsourcing

[Inland Revenue] learned a lesson after one incident, during the previous EDS contract, when its security department found out about cost-saving plans to shut a data centre and move sensitive information to a shared site only after an internal memo was circulated.

Computing has a good basic article on security issues in outsourcing of IT activity. It doesn’t touch on the security (confidentiality) of outsourced development, or the security (vulnerability) of the delivered code. Recently, I heard about an outsourcer who was well-regarded by their customer, who delivered a security fix in the form of javascript-driven client side verification. This was discovered because the verifier didn’t work in Firefox. The same sort of issues will come up in outsourced IT security. You won’t know if until it bites you, or if you get lucky. Oversight raises the cost of outsourcing, which weakens the reasons to do it. You want your outsourcer to know more than you about the issue.

A great many operational decisions are security decisions. Knowing what to put into an outsource contract is hard, and I hope that painfully learned lessons get shared quickly.

(Via SecurityFocus Elsewhere.)

A Market for Journal Articles?

In A Market for Journal Articles, Alex Tabarrok refers to a paper by David Zetland on A Market for journal articles.

Zetland suggests that journal publishers should buy manuscripts in an auction.  You probably already have some objections, Where would the money come from?  Why would journal editors buy what they can get for free? etc.  But wait.  Here comes the clever part:

The money paid in the auction would flow not to the author of the paper but to authors cited by the paper and their publishers.  For example, if a journal buys a paper by A.Tabarrok for $1000 which cites an article by T.Cowen published by Oxford University Press and an article by M. Friedman published by the University of Chicago Press then Cowen, Friedman and their publishers would each receive $250 (the author/publisher split could vary.)

First, let me say this is a cool idea. Zetland acknowledges the potential for citation gaming in the paper. Perhaps more important is an issue he alludes to in the introduction:

Gans and Shepherd (1994) asked some famous economists if they ever had trouble getting their seminal articles published. Tales of woe poured forth from wounds never healed. 3 Although these economists did get published in the end, many do not. The process of publishing a journal article is often frustrating— misplacement, delay, overburdened editors and dense reviewers inhabit our worst nightmares. Since articles are the primary tool in academic discourse, improving this process is important.

It is clear that editors and reviewers do a poor job of selecting articles. I see the core problem as reviewers want to select papers that doen’t shake the boat (and ideally, cites their work). Editors are unable to tell a good article from a bad one, and rely on reviewers to do that. So perhaps pay reviewers who praise articles that later are well-cited? (This of course relates to Keynes’ beauty contest.)

The height of logic

“The question was, why do I support a strong dollar policy? The answer is because it is our policy,” [US Treasury secretary John] Snow said.

“Our dollar policy remains unchanged because a strong dollar is in both the national and international interest.” He pledged to curb the US massive budget deficit – but said the size of the current account deficit at the moment was evidence of “economic strength”.

He further clarified that ignorance is strength, and freedom is slavery.

(From the BBC.)

TSA’s identity obsession

US Homeland Security undersecretary Asa Hutchinson said the current practice of airlines giving the names of passengers to US officials 15 minutes after take-off did not make sense.

“If we have to have information 60 or 45 minutes before, you’ve got to close off the passengers that come in at the last second,” he told reporters. It’s a behavioral adjustment that has to be made.”

The behavioral adjustment that needs to be made is a recognition that names are not inherent properties of people. What we care about is “Does this person have means, motive and opportunity to commit a serious crime on this aircraft?” The name is not so important.

‘Tis but thy name that is my enemy;
Thou art thyself, though not a Montague.
What’s Montague? it is nor hand, nor foot,
Nor arm, nor face, nor any other part
Belonging to a man. O, be some other name!
What’s in a name? that which we call a rose
By any other name would smell as sweet;
So Romeo would, were he not Romeo call’d,
Retain that dear perfection which he owes
Without that title. Romeo, doff thy name,
And for that name which is no part of thee
Take all myself.

(From ABS-CBN News, via Webflyer; Romeo and Juliet, Act II, Scene II. )

Glad to be a perfect straight man

In his response to my comments on vulnerability hunting, Pete Lindstrom discusses four ways to make things better:

  1. Legislate/enforce the law
  2. Buy exploits now and then
  3. Create Software security data sheets
  4. More honeypots

I don’t think that (1) actually helps. More laws against finding vulns makes life harder for the good guys, by moving information flow back underground. Were we better off in the days of Zardoz? It would move the mailing lists and web sites offshore, not slow down the rate of finding things.

(2) would seem to help, but Immunity is already doing it. Is that helping?

(3) I really like. Better data from software authors is good.

(4) I’m not sure I understand.

Pete also says:

I don’t see any reason that exploit code would cease to exist, the volume and proliferation would just slow down. Of course, I certainly wouldn’t lose sleep if there were no exploits anymore. Ultimately, the existence of these host intrusion prevention products is what makes my opinion stronger – because there are solutions that don’t rely on signatures of known attacks.

I certainly would lose sleep, because without easy access to exploit code, we don’t see exchanges like this. Without such commentary, how can we decide if our tools work?

TSA ignores the public

As I and others >predicted, the TSA has chosen to run roughshod over our concerns. Interestingly, they claim that we have implicitly consented to the data being used this way. That’s interesting, because in the comments which I sent to them, I explicitly stated that I don’t consent. (Search this document for the words “do not consent.”) I’m not sufficiently familiar with the law to know, but do I have a right to have my data excluded from the tests on that basis?

The TSA says no, but they clearly have trouble with the law. And besides, we need to give those judges a reason to annoy Ashcroft.

Comments on the TSA’s dissing of America

Thanks to Ed Hasbrouck for catching the TSA’s disdainful response to the American people. Quotes are from the TSA’s Notice of Final Order for Secure Flight Test Phase and Response to Public Comments. Because the document is apparently a scan of a printout, I can’t copy text, and thus chose which words I bother to type in:

“This test will involve commercial data aggregators whose procedures will be governed by strict privacy and data security protections. TSA will not receive the commercially available data that would be used by commercial data aggreators.” (Page 4)

In other words, data that the government collects under secret regulations will be used for quality assurance purposes by LexisNexis, as they update their database.

TSA stated … it would invoke excemptions to the Privacy Act’s requirements… that information collected by the agency be relevant and necessary to the agency’s statutory purpose. (Pages 9 and 10)

Quite. How the agency plans to explain that it can ignore the law and collect data that is not relevant and necessary is of great interest to those of us in the reality-based community.

TSA will neither use passenger information to monitor individuals’ movements within the country nor share such information with other agencies or third parties. (Page 11)

This blatantly contradicts what they said in the Privacy Act Notice: (Pg 57347, column 3, under “ROUTINE USES OF RECORDS…

To the Federal Bureau of Investigation where the TSA becomes aware of information that may be related to an individial identified in the Terrorist Screening Database…

(Bold theirs, emphasis mine.)

On page 17 comes the money quote:

These are all key issues TSA will be attempting to resolve during the testing phase.

Perhaps, just perhaps, you could resolve these issues before invading the privacy of millions of Americans?

Blog changes

Thanks to Dave and Lisa, I’ve moved to a new host. Things may have unsettled during the move. We’ve also added a feature that closes comments after a bit, because old posts are getting nothing but blogspam.

A downside to data warehousing

A long story in the New York Times ends:

Still, as Wal-Mart recently discovered, there can be such a thing as too much information. Six women brought a sex-discrimination lawsuit against the company in 2001 that was broadened this year to a class of about 1.6 million current and former female employees. Lawyers for the women have said that Wal-Mart has the ability to use its human-resources database to calculate back pay for the plaintiffs as well as to determine whether women were fairly promoted and paid. The judge hearing the case, which is pending in a federal court in San Francisco, has agreed.

The database is unusually detail-rich, said Joseph Sellers, a lawyer for the plaintiffs. “They’ve put into their work force database the information that bears on virtually every facet of compensation,” he said. “They have performance reviews, along with seniority, the time spent with the company, which store they worked in. So you can compare people working in the same store, to measure whether men and women are paid differently.”

There’s an distinction I use: Data protection is someone else promising to keep their information about me under control. Privacy is them not getting the data. I fully expect that one of the ways in which we will start to claw-back privacy from the companies that conflate these concepts is liability and compliance costs.

Collecting my social security number may well bring you under the Financial Services Modernization act (GLB). Store any health data on me, and spend big on HIPPA compliance. Don’t store that data, don’t incur those direct compliance costs or liability risks.

How not to find vulnerabilities (2)

Pete Lindstrom has argued that we need to end the bug-hunt:

Once evaluated, neither reason provides a good foundation for continuing the practice of vulnerability seeking, but it gets much worse when we consider the consequences.

There is a rarely mentioned upside to all this bugfinding, which is that researchers use the exploit code to test defensive mechanisms. Companies like Immunix, PivX, or Sana could not accurately test their tools without exploit code. That’s not an argument for immediate release. But those zoos of exploit code are very useful.

More importantly, Lindstrom says what we should not do. He’s clearly been talking to too many security experts. I’d like to hear what we should do. More laws like the DMCA? Privately paid bug bounties? Public beheadings?

I think that Lindstrom and I are in full agreement: The current system is bad, and we’d all like to do better. I don’t think attacking the bugfinders is the right approach. We need to stem the problem where it starts. The problem starts with development languages that are unsafe at any speed. Developers aren’t trained in their use. Projects are driven to ship quickly, without good QA.

There are better ways to develop? The eXtreme Programming folks call for better test harnesses. Better modularity allows you to develop and test patches faster. Better patch management, including bullet-proof rollback, allows your customers to deploy patches at lower risk. More use of things like Stackguard automatically close off venues of attack.

I recite these things because there are better ways to do things. Those better ways make sense, and smart companies are adapting them. I’d love to see an analogous way to improve bug-hunting.

[Update: Nudecybot has waaaaaaay too much time on his hands if he catches spelling errors like that. Must be the snow.]

How not to report vulnerabilities

This week Finjan announced that it has told Microsoft of 3, or 10, or maybe 19 issues with SP2.
Robert Lemos at CNET writes:

“We don’t want to argue with Microsoft about these things,” he said. “We found the 19 vulnerabilities, and we showed that you could take remote control of a computer.”

However, Microsoft’s Wilson took issue with Finjan’s move, contending that the software giant does not agree on how many of the flaws are real. Moreover, because the security company released the issues piecemeal, the software giant argues that it is not certain that Finjan has even named 10 vulnerabilities.

“They have been contacting us over time regarding various issues,” Wilson said. “But there is no definitive communications between Microsoft and Finjan about 10 specific issues.”

(I don’t agree that a vendor is always owed 30 days (as Lemos claims is standard.) Its a fine goal, but there are often issues that need faster response. The vulnerability clock ticks from the day the bad code is written. Software companies need to enhance their testing practices and software modularity so they can cut reliable patches faster.)

Back to the reporting side.

The Finjan press release includes no CVE names. It is now easy to reserve CVE CANdidates. Responsible researchers should do so. (There are lots of good, competing definitions of responsibility. None that I know of includes making your research harder to access and manage.)

Microsoft and Finjan can’t agree on how many issues Finjan has reported. This is slop on Finjan’s part. They may have found two routes to one issue, but there certainly shouldn’t be a 3-10-19 discrepancy. Finjan should clearly state how many issues they’ve found, roughly what they are, and when Microsoft was informed of them. Many people have issues with the detail in eEye advisories. But they are very clear on what they’ve reported.

Kaspersky Labs switches to a new naming scheme

Kapersky Labs makes some of the best anti-virus software out there, as analyzed by the Virus Test Center at the University of Hamburg.

They recently announced a new naming scheme. I’ve been thinking a lot about naming schemes recently, and I think this one could be better. Let me take it apart, and explain why. The scheme breaks down into:

Verdict: verdict clarification.
Verdict clarification includes the following categories:
Behaviour[-Sub-behaviour].OS.Name[-Modification:]

An example name is thus: “Trojan-Dropper.Win32.Agent.a

My first problem is that the name is long–29 characters, or 9 syllables. That makes it harder to work with than a shorter name. (This is probably more of a problem for those who spend their days working with them. For example, with CVEs, the 8 character length is longer than I can typically handle as one “chunk” and I need to look several times to ensure it’s right. If CVEs were 5-7 characters, they’d fit better in typical short-term memory. (This could be accomplished, for example, by using letters in place of numbers, getting a higher data density per character.)

My second issue is that much of the information is not needed. Today, 99+% of malware infects Windows. By actual infection, non-Windows malware is a rounding error. So why not leave off those 5 characters, except when they’re needed: “rootkit.macosx.opener“?

I think the ordering in use could be better. The name should be an index into a name list, and sometimes, human beings use visual scanning in place of search functions. In those cases, naming this “Agent.a-trojan-dropper” makes scanning much easier, without changing the information content.

Part of me wants to say that they should have used abbreviations in the name: “Agent.a.TD,” to make it harder to typo. But that runs into trouble with handling errors. If you do make a mistake, did you mean its a T(rojan) and added an extra character?

Generating good names that will satisfy all your different of user-types is very hard. Its also very important.

(From Nudecybot via email.) [Update: The cybot pointed me at the Kapersky labs article, he didn’t write the above.]

Selling Security

The poll of IT network and security administrators in SMEs to determine how they persuade management to change security practice found that almost half of respondents admit to advocating the fear factor.

Many respondents indicated that they have to present worst case scenarios involving confidentiality breaches, lost customers or liability charges to justify investments in information security technology.

The use of scare tactics may be prompted by the fact that, according to additional findings from the poll, more than one in four (29 per cent) network administrators claim that senior management rarely, or never, change standard practices in response to security recommendations alone.

However, an encouraging 30 per cent indicated that rational facts, including cost-based analysis, productivity statistics and industry articles, are sufficient to prompt a reaction.

Additionally, 51 per cent of respondents reported that senior management implement changes to security practices based on their recommendations most or all of the time.

(No comment. From VNU, via Infosec News Blog.)