While genetics is concerned with the observation of specific sections of DNA, genomics is about studying the entire genome of an organism, something that has only become practically possible in recent years. In forensic genetics, which is the technology behind the large national DNA databases being built in several countries including notably UK and USA (Wallace’s outstanding article lucidly exposes many significant issues), investigators compare scene-of-crime samples with database samples by checking if they match, but only on a very small number of specific locations in the genome (e.g. 13 locations according to the CODIS rules). In our paper we explore what might change when forensic analysis moves from genetics to genomics over the next few decades. This is a problem that can only be meaningfully approached from a multi-disciplinary viewpoint and indeed our combined backgrounds cover computer security, bioinformatics and law.

(Image from Wikimedia commons, in turn from NIST.)

Sequencing the first human genome (2003) cost 2.7 billion dollars and took 13 years. The US’s National Human Genome Research Institute has offered over 20 M$ worth of grants towards the goal of driving the cost of whole-genome sequencing down to a thousand dollars. This will enable personalized genomic medicine (e.g. predicting genetic risk of contracting specific diseases) but will also open up a number of ethical and privacy-related problems. Eugenetic abortions, genomic pre-screening as precondition for healthcare (or even just dating…), (mis)use of genomic data for purposes other than that for which it was collected and so forth. In various jurisdictions there exists legislation (such as the recent GINA in the US) that attempts to protect citizens from some of the possible abuses; but how strongly is it enforced? And is it enough? In the forensic context, is the DNA analysis procedure as infallible as we are led to believe? There are many subtleties associated with the interpretation of statistical results; when even professional statisticians disagree, how are the poor jurors expected to reach a fair verdict? Another subtle issue is kin privacy: if the scene-of-crime sample, compared with everyone in the database, partially matches Alice, this may be used as a hint to investigate all her relatives, who aren’t even in the database; indeed, some 1980s murders were recently solved in this way. “This raises compelling policy questions about the balance between collective security and individual privacy” [Bieber, Brenner, Lazer, 2006]. Should a democracy allow such a “driftnet” approach of suspecting and investigating all the innocents in order to catch the guilty?

This is a paper of questions rather than one of solutions. We believe an informed public debate is needed before the expected transition from genetics to genomics takes place. We want to stimulate discussion and therefore we invite you to read the paper, make up your mind and support what you believe are the right answers.

Corporate custodians of confidential medical data should be closely monitoring events connected to a nightmarish computer security breach in the St. Louis region.

Express Scripts is one of the nation’s largest pharmacy benefits managers. The company, with headquarters in St. Louis County, handles approximately 500 million prescriptions per year for 50 million workers at 1,600 American companies. Early in October, it received an extortion letter, the details of which it released on Nov. 6.

The letter included personal information on about 75 Express Scripts clients — Social Security numbers, dates of birth and, in some cases, information about prescription medications. Whoever sent the letter demanded money from the company — the amount has not been disclosed — and threatened to use the Internet to reveal personal and medical information about millions of people if the demands were not met.

...

Beyond the scale of the problem for Express Scripts — and the potential impact on the company is enormous — the issue extends well beyond the mounting concerns about identity theft, a phenomenon with which most people have become at least somewhat familiar.

The greater problem is the unique nature of personal medical records, the importance of moving to computerization of such records to improve health safety and reduce costs and the irreversibility of the damage people can suffer if confidential medical information becomes public. The stakes are so high that a federal law establishes strict standards for maintaining the privacy of medical information and stiff fines for failing to do so.

Medical records of all kinds — paper and, especially, electronic — must be protected with the most sophisticated kinds of security systems available, including backup protections and automatic alerts of security violations. Yet Express Scripts learned of this breach in the “worst way,” as InformationWeek.com security correspondent George Hulme put it in an online report: “via an extortion letter.”

The Express Scripts breach raises many questions for all elements of the health industry: hospitals, clinics and doctors’ practices, benefits management firms, insurance companies, pharmacies, employers and government agencies:
Are they using the most advanced information security technology possible? Do they minimize the amount of data they collect and keep it only as long as necessary? Do they have strict protocols governing access to personal and medical data — and systems to enforce those protocols? If criminals were to hack into their systems, how would the companies know? How soon? And are the systems capable of instantly cutting off illegal access as soon as a breach is discovered?

Confronted with a grave breach of electronic security, Express Scripts has responded by contacting law enforcement, establishing an informational website, offering a substantial reward and hiring a private consulting firm to help clients who have privacy concerns and investigate situations that “appear to be tied to identity theft” and provide “identity restoration services.” There is no question that the company is taking the situation extremely seriously.
Given the ongoing criminal situation, information about how Express Scripts’ data systems were compromised — and whether it could have been avoided — has yet to be disclosed. But the American people have the right to expect that their sensitive personal and medical information is zealously protected and kept secure — not only by Express Scripts but also by every person or company entrusted with it.

"Customers and customer relationships...have tangible measurable value to businesses, and their value is much easier to communicate to those who fund projects. So in an enterprise risk management scenartio, their vlaue informs the risk management process...[For example, consider] a farmer deciding which crop to grow. A farmer interested in short term profits may grow the same high yield crop every year, but over time this would burn the fields out. The long term focused farmer would rotate the crops and invest in things that build the value of the farm and soil over time. Investing in security on behalf of your customers is like this. The investment made in securing your customer's data build current and future value for them. Measuring the value of the customer and relationships helps to target where to allocate security resources."

Errata: Version 1.1 of the paper, reference, and optimized code corrects an error in which the length of the configuration string was passed in as the size of the internal block (256 bits for Skein-256, 512 for Skein-512, and 1024 for Skein-1024), instead of a constant 256 bits for all three sizes. This error has no cryptographic significance, but affected the test vectors and the initialization values. The revised code also fixes a bug in the MAC mode key processing. This bug does not affect the NIST submission in any way.

NIST has received 64 submissions. (This article interviews one of the submitters, who is fifteen.) Of those, 28 are public and six have been broken. NIST is going through the submissions right now, making sure they are complete and proper. Their goal is to publish the accepted submissions by the end of the month, in advance of the Third Cryptographic Hash Workshop to be held in Belgium right after FSE in February. They expect to quickly make a first cut of algorithms -- hopefully to about a dozen -- and then give the community about a year of cryptanalysis before making a second cut in 2010.

Lastly, this is a really nice article on Skein.

These submissions make some accommodation to the Core 2 processor. They operate in "little-endian" mode (a quirk of the Intel-like processors that reads some bytes in reverse order). They also allow a large file to be broken into chunks to split the work across multiple processors.

However, virtually all of the contest submissions share the performance problem mentioned above. The logic they use won't optimally fit within the constraints of a Intel Core 2 processor. Most will perform as bad or worse than the existing SHA-1 algorithm.

One exception to this is Skein, created by several well-known cryptographers and noted pundit Bruce Schneier. It was designed specifically to exploit all three of the Core 2 execution units and to run at a full 64-bits. This gives it roughly four to 10 times the logic density of competing submissions.

This is what I meant by the Matrix quote above. They didn't bend the spoon; they bent the crypto algorithm. They moved the logic operations around in a way that wouldn't weaken the crypto, but would strengthen its speed on the Intel Core 2.

In their paper (PDF), the authors of Skein express surprise that a custom silicon ASIC implementation is not any faster than the software implementation. They shouldn't be surprised. Every time you can redefine a problem to run optimally in software, you will reach the same speeds you get with optimized ASIC hardware. The reason software has a reputation of being slow is because people don't redefine the original problem.

That's exactly what we were trying to do.

There is another reason why the article got my attention; my manager, Steve Lipner, is one of the few people to have designed and built a TCSEC A1 assured system and lived to tell the tale. None were sold, but they built one!

The NSA-directed project, the Tokeneer ID Station (TIS), involved building a low-defect system that conforms "to the Common Criteria requirements for Evaluation Assurance Level 5 (EAL5)" in a "cost effective manner." I'm all for this, because building high-assurance solutions is not cheap.

There's a paper with more technical detail about the project that is worth a read.

In my opinion, the project is only a science project, an experiment, for the following reasons:

• It's tiny. Weighing in at a little under 10 KLOC.
• It's only a very small portion of a much larger solution which has not been developed using the same rigor. This bit of context makes the solution as a whole moot. Call me cynical, but my question is "can the entire solution be built with same rigor in a ‘cost effective manner'?" Perhaps it can, but that is not what is presented.
• It sits on top of many operating systems (Windows, Mac OS X and Linux) that are not EAL5 certified. So it would be a little like having an EAL5 certified CharMap application running on EAL4 Windows Vista.
• It's written in a subset of Ada called SPARK, and SPARK skills are not common in the marketplace. Interestingly, SPARK makes use of annotations to help drive the static analysis process. While not a total analog, we also recommend Microsoft development teams use annotations (SAL) to help drive the required static analysis process.
• The application has a large number of dependencies that are not part of the project:

In the SDL we call these files ‘giblets' because they are components needed for your application to operate, but they do not belong to your team. Some of the files look old and highly vulnerable, such as libpng-3.dll from 2001! OSVDB lists 23 vulnerabilities since 2002 in libpng!

In summary, the TIS project is very interesting to a small number of important but specialized customers, such as the NSA, for whom this kind of research is critical. I too found it interesting, but the process is far from a set of "secrets to writing secure code" and the tools are certainly not within reach of day-to-day applications and not applicable to developing complete solutions.

The latest Microsoft patch MS08-68 is a great example. It is a problem with NTLM authentication where the attacker can force a client to authenticate to him and the credentials, while not exposed in cleartext, can be relayed to another server or brute forced to obtain the cleartext. This is a very classic crypto protocol vulnerability. It’s not the crypto algorithms that are the problem, but the protocol implementation.

Microsoft recently fixed the problem, perhaps due to the availability of exploit code, the availability of an easy to use Metasploit implementation, or perhaps Microsoft’s changed tolerance for vulnerabilities. We can sum it up as a change in the threat space that made it worth fixing. But make no mistake, this is a very old problem.

News reports have been citing Sir Dystic’s SMBrelay tool, which was published in March, 2001, as the first knowledge of this vulnerability. Eric Shultze who worked at MSRC in 2001 just yesterday is quoted as saying, “I have been holding my breath since 2001 for this patch.” Obviously it is a long time coming. But this wasn’t the first publication of the problem. In 2000, one of my collegues on the research team at @stake, Christian Rioux (aka Dildog) published the telnet NTLM authentication vulnerability.

Rioux’s advisory has a great description of the credential relay and cracking weaknesses. I have talked to him and he says he discovered these problems independently, but he didn’t find them first. Dominique Brezinski published exactly these NTLM vulnerabilities in the SMB protocol in 1996 in a paper titled, “A Weakness in CIFS Authentication”. The earliest reference I can find on the paper on the net is here where it is included in another paper published in 1997. Such is the ad-hoc world of independent security research of 12 years ago which still continues today.

It seems ridiculous that a field like security research, which is so important to the running of modern society is so ad-hoc. Shouldn’t we know who discovered a vulnerability? Shouldn’t all researchers and engineers know about it? More importantly if someone implements a tool that takes advantage of a vulnerability shouldn’t they credit the discoverer? Don’t get me wrong. Implementation takes a lot of work and sometimes makes all the difference in makeing people aware of a security problem. After all when I was at the L0pht our slogan was, “Making the theoretical, practical”. I still think researchers should get credit when credit is due.

The security community has gotten better at documentating our research but I still see instances of independent discovery, misplaced credit, and tools giving no credit to researchers. I hate to say it but getting a bit more academic is in order. Credit is the currency of a researcher and placing it well will reward the right people and we will all benefit.

After 26 days, and almost 350 million e-mail messages, only 28 sales resulted -- a conversion rate of well under 0.00001%. Of these, all but one were for male-enhancement products and the average purchase price was close to $100. Taken together, these conversions would have resulted in revenues of $2,731.88 -- a bit over $100 a day for the measurement period or $140 per day for periods when the campaign was active. However, our study interposed on only a small fraction of the overall Storm network -- we estimate roughly 1.5 percent based on the fraction of worker bots we proxy. Thus, the total daily revenue attributable to Storm's pharmacy campaign is likely closer to $7000 (or $9500 during periods of campaign activity). By the same logic, we estimate that Storm self-propagation campaigns can produce between 3500 and 8500 new bots per day.

Under the assumption that our measurements are representative over time (an admittedly dangerous assumption when dealing with such small samples), we can extrapolate that, were it sent continuously at the same rate, Storm-generated pharmaceutical spam would produce roughly 3.5 million dollars of revenue in a year. This number could be even higher if spam-advertised pharmacies experience repeat business. A bit less than "millions of dollars every day," but certainly a healthy enterprise.

Of course, the authors point out that it's dangerous to make these sorts of generalizations:

We would be the first to admit that these results represent a single data point and are not necessarily representative of spam as a whole. Different campaigns, using different tactics and marketing different products will undoubtedly produce different outcomes. Indeed, we caution strongly against researchers using the conversion rates we have measured for these Storm-based campaigns to justify assumptions in any other context.

Spam is all about economics. When sending junk mail costs a dollar in paper, list rental, and postage, a marketer needs a reasonable conversion rate to make the campaign worthwhile. When sending junk mail is almost free, a one in ten million conversion rate is acceptable.

News articles.