2006 Underhanded C Contest

long unsigned int maxwordsize(char *inputFromStdIn)
long unsigned int tmpwordsize=0,maxword=1,i;
for (i=0; i <= strlen(inputFromStdIn); ++i,++tmpwordsize)
[etc etc]

So sayeth the winner of the "2006 Underhanded C Contest." (Underhandedly, they've titled the page, "2005 Underhanded C Contest:" I bet they're checking to see who's paying attention.)

I'm a huge fan of the Underhanded C Contest. When I was with Reflective, we spent a lot of time talking with executives concerned about trojans in their code. Now, detecting trojans in the code is a lot harder than detecting buffer overflows, and, I think, there are a lot more of the latter.

I'm glad to have samples of underhanded C code, because they allow us to study the problem, and the problem looks awfully hard.

Extra! Extra! Read Nothing About It! (Latest on Apple V. Maynor)

In “SecureWorks Backs Out of Macbook Demo,” Brian Krebs writes:

David Maynor, the SecureWorks researcher who was set to demonstrate how wireless driver flaws could be used to compromise an Apple Mac laptop, suddenly has been yanked from the ranks of Toorcon presenters.

At around 12:50 p.m. PT, SecureWorks issued the following press release:

“SecureWorks and Apple are working together in conjunction with the CERT Coordination Center on any reported security issues. We will not make any additional public statements regarding work underway until both companies agree, along with CERT/CC, that it is appropriate.”

TRUSTing Mary Ann Davidson

Yesterday, Mary Ann Davidson had a fascinating post about the classics of Western literature. As usual for Mary Ann, the apparent basis of the post is really just exposition for her main point. In this case, the thrust of her post is the need for developers to have more training in secure coding at the university level. Mary Ann and several others have started working with several universities (including UC Berkeley, Stanford and CMU) and corporations (including GE, Sun and Visa) to produce such a curriculum. They are calling this program “The Team for Research in Ubiquitous Secure Technology” or TRUST and have bunch of resources and information online.
[Edit: Gunnar Peterson over at 1 Raindrop points out that: Ken Van Wyk and John Steven have an article “Essential Factors for Successful Software Security Awareness Training” in the current issue of IEEE Security and Privacy, that is also relevant to the general issue.]

Computers Will Make Our Lives More Private


Social Security Administration officials believe computerization of files has contributed to their security. In the manual era, the applicant’s record was an individual ledger sheet. Thus if a person could get to the file drawer and then the ledger, he could check any record. Although entry to the files area was restricted by guards who checked workers’ identification, it was impossible for the guards to keep track of everyone. Under SSA’s computerized system, however, the individual has to secure the tape from locked storage. Then, because SSA runs a batch processing operation, the entire tape must be run to gain access to any single record.

From “Databanks in a Free Society,” Alan Westin and Michael Baker 1972, Quadrangle/New York Times Book Company. Thanks to Andre Frech for the quote.

Photo: An IBM 360 operations room, from Cray-Cyber.org.

Words to live by

No free man shall be seized or imprisoned, or stripped of his rights or possessions, or outlawed or exiled, or deprived of his standing in any other way, nor will we proceed with force against him, or send others to do so, except by the lawful judgement of his equals or by the law of the land.

Magna Carta, Article 39
An opposing view was today expressed by the United States Senate.

Breach Datasource Design Criteria

 Most readers of these words are probably familiar with at least one of the lists of data breaches commonly referenced in the media and in specialized blogs.  Among these are Attrition.org’s Dataloss, and Privacyrights.org’s Breach Chronology.  The ID Theft Center also maintains a list (available, it seems, only as a PDF), and various academic researchers have also compiled breach datasets.  Clearly, there is interest in having a handy source of current information about such incidents.  This post is my take on what such a source should contain, and what sorts of activities it should allow.  I want to state right away, and emphatically, that these remarks are not a criticism of any existing list or database.  Indeed, those resources are the shoulders of giants on which I think we all can stand.  Seriously.

 First, the datasource should not be a simple list, oriented toward on-screen viewing or printing in its entirety.  It should be a database.  I am not speaking of its physical representation or storage format, but the kinds of uses it should be amenable to.  I’m saying that it should contain a rigidly-enforced set of data elements, and allow random access to records based on criteria pertaining to those elements.  That can be done with flat files, with a full-blown relational database, with a spreadsheet, or any number of other things.

Second, this datasource should have a web interface.  This interface should make easy the types of arbitrary queries referred to in the preceding paragraph.  For example, it should be possible for a user to obtain a listing of all breaches with a specified date range, or within a certain industry. The result sets obtained through these arbitrary queries should be made available for download in as universal a format as possible, for example as a CSV file, and should also be viewable on-line if their size permits.

Third, the datasource should contain a wider range of data pertaining to each breach than is currently available.  Today’s datasources typically contain variables such as these:

  • Date breach became known
  • Affected Company
  • Industry of Company
  • Number of records disclosed
  • Type(s) of information revealed
  • Names of third parties involved in the breach
  • Reference to a media account of the incident
  • General Comment

These, I would say, are “the basics” and are fine for many purposes.  However, deeper understanding requires more information.  Specifically, as my fourth point, I would like to see:

  • Full address information for the Affected Company
  • Company stock symbol and exchange (where relevant)
  • Indicator of company size, such as number of employees or gross revenue
  • Dates for the discovery of the breach, the occurence of the breach, and the reporting of the breach to “victims”, law enforcement, and regulators.
  • The proximate cause of the breach
  • Whether notice to victims took place
  • Whether this notice was required by law
  • The minimum and maximum number of affected individuals, where a precise count is not known.

 All of these variables are easily represented in text form, although some discipline is needed in coding the breach cause — there are many ways of saying “web server config error”, after all.  Similarly, maintainers of this ideal datasource should publish their coding guidelines, so that users of the datasource understand just how a “web server config error” is determined to be a breach cause, rather than (say) “improper firewall ruleset”. 

Fifth, the datasource should  be easy to extend and link to other sources of information about an incident.  The DLDOS datasource has begun using a unique identifier for each of its records, which allows others (of whom I am one) to link related information.  Since, unfortunately, much of the work in amassing the data on breaches has been a part-time thing conducted by amateurs, it may be important to allow others to “connect” and reconcile different ways the same event has been recorded.  

Sixth, and related to the preceding, the datasource should allow for easy linkage of non-textual data.  My personal favorite example would be the notification letters and paperwork I have obtained from New York.  As interest in this subject grows, particularly among academics who can do this full-time (or more — grad students don’t work 9-5), notification letters contributed by their recipients may be sanitized and added.  For some breaches, I can even see Wiki-like possibilities.

Last, the datasource should be free, as in beer.  We can argue over which license is best in another post :^).

At any rate, those are some quick thoughts.  I’ve tried to instantiate them, but have been hampered by my lack of skill as a DBA and data-modeller, and my lack of time.  If others are interested in this subject, as I think the example of Attrition and PogoWasRight.org easily demonstrates, we may all benefit from cooperating openly.  I’m interested in reactions, criticisms, suggestions, and even flames.  Let’s hear them.

Well, At Least TSA Isn’t Driving People to Drink


“Everybody personally and professionally that I know who is afraid to fly gets their hands on Xanax,” said Jeanne Scala, a psychotherapist in Roxbury, N.J., adding that she has seen an increase in patients and friends talking about taking medication for flying jitters. “They’ll do anything to take the edge off the anxiety of sitting in a plane,’’ she said. “They just want to zone out, they want to sleep. So they’ll take Ambien, Sonata, even pain medication like Soma, which is for back pain. People use whatever they have — the pharmacy in their house.”

You Are Cleared For Takeoff,” The New York Times.

In case it’s not obvious, I’m posting out of sheer glee that TSA is driving people to illegal drug use as they work to make flying as unpleasant safe as they can, and for the phrase “the pharmacy in their house.” What a great image. Its too bad you can’t go to the drugstore and buy the drugs you want, but that’s not the TSA’s fault. A different government agency screws that one up.

Worse Than Choicepoint: The FTC?

So part of Choicepoint’s settlement with the FTC was a $5m fund to compensate their victims. Now, there were 167,000 victims, of whom 800+ had their identities abused by fraudsters. None have gotten any money:

Jessica Rich, assistant director of the FTC’s division of privacy and identity theft, said in a statement released to AP on Wednesday that “law enforcement is still identifying victims and we want to make sure we have the right people.”

(From the AP, “FTC Yet To Pay Choicepoint Victims.”)

U.S. versus E.U. Audits

Speaking of the differences between how security gets managed in the U.S. versus the E.U., CSO magazine has a light-hearted and somewhat irreverent article on the differing goals and priorities of audits on either side of the Atlantic. In spite of its tone, it does highlight some important issues to keep in mind. In particular:

But it also illustrated a fundamental difference in the way audits are conducted on both continents. In the United States, audits are about ensuring that sufficient controls are in place to mitigate risks. Thus, the audit findings tend to emphasize lapses in application and network security. In Europe, audits tend to focus on following a predefined process, being transparent in the actions taken, precisely defining policies and procedures, and adhering to international standards.

I’d love to see a much deeper analysis of managing compliance in the U.S. versus the E.U. from someone who has a lot experience working in both domains. Does this already exist? Or are folks interested in collaborating on writing something like this?

“Handling Security Breaches Under European Law”

In a comment on “What’s Next in Breach Analysis,” Ian Grigg pointed out the very interesting “Handling Security Breaches Under European Law:”

There are as yet no direct equivalents of the mandatory security breach reporting legislation we have seen in the U.S., either at a European Union level or within Europe itself. That is not to say there is no law on the reporting of breaches in Europe. While a number of countries have been looking at the increasing number of security breaches, in the main the response has been to use existing privacy legislation to take action.


In Norway, the unauthorized disclosure of personal data must be reported to the Datatilsynet, but not to the data subject. Section 2-6 of the Norwegian Personal Data Regulations provides…

So…does Norway have a Freedom of Information act?

International Breach Notices: The Future Is Unevenly Distributed

So said William Gibson, and it is as true in breach notices as it is anywhere else. While only 34 US states have laws requiring these notices, we see organizations around the world sending them. They resonate as the right thing. Acknowledging and apologizing for your mistakes is powerful. (Hey, someone should mention that to Mark Hurd. Using a scandal as a pretext for promotion isn’t going to serve you well. But I digress.)

Organizations around the world are getting ahead of their problems by reporting them to their customers:
KRA computers stolen, which contains the interesting comment “A [Kenya Revenue Authority] official said the computers had crucial data on tax returns and it is likely that the data had no back up.”

On the other side of the world, “Computers with patient data stolen from Nagasaki hospital.”

Both via the Dataloss list.