Superconductor

What happened at VeriSign?

VeriSign's latest 10Q report has an interesting paragraph in it. It says this:

We experienced security breaches in the corporate network in 2010 which were not sufficiently reported to Management.

In 2010, the Company faced several successful attacks against its corporate network in which access was gained to information on a small portion of our computers and servers. We have investigated and do not believe these attacks breached the servers that support our Domain Name System (“DNS”) network. Information stored on the compromised corporate systems was exfiltrated. The Company’s information security group was aware of the attacks shortly after the time of their occurrence and the group implemented remedial measures designed to mitigate the attacks and to detect and thwart similar additional attacks. However, given the nature of such attacks, we cannot assure that our remedial actions will be sufficient to thwart future attacks or prevent the future loss of information. In addition, although the Company is unaware of any situation in which possibly exfiltrated information has been used, we are unable to assure that such information was not or could not be used in the future.

The occurrences of the attacks were not sufficiently reported to the Company’s management at the time they occurred for the purpose of assessing any disclosure requirements. Management was informed of the incident in September 2011 and, following the review, the Company’s management concluded that our disclosure controls and procedures are effective. However, the Company has implemented reporting line and escalation organization changes, procedures and processes to strengthen the Company’s disclosure controls and procedures in this area. See Item 4 “Controls and Procedures” in Part I of this report.

Now VeriSign is essentially out of the digital certificate business, so it's unlikely that this is another example of a CA/RA being compromised. Instead, they really just focus on DNS for several of the Internet's top-level domains (.com, .edu, etc.), so if anything was affected, it woudl probably have been the integrity of DNS. But without further information from VeriSign, it's not clear exactly what happened. Maybe we'll find that out over the next few weeks.

Lots of infected PCs in China

The recent "Security Threat Report 2012" from Sophos has all sorts of interesting information in it. I found the data about the fraction of PCs that experienced a malware attack over a three-month period interesting. Here's the data from Sophos' report that describes this:

But if we use the number of on-line users in each country as an estimate of the total number of infected PCs in each country, the graph looks much different:

China's definitely a big problem, isn't it?

Imperva does it right

I've always been irritated by those vague citiations to analyst reports that you see in sales and marketing presentations. Things like "This market is projected to grow by 1,000,000 percent by 2015 (Forrester)."

I always assume that this really means "This market is projected to grow by 1,000,000 percent by 2015 (but we know you really won't check this outlandish claim)." That's why I so pleased to see how the most recent version of "Imperva's Web Application Attack Report" (PDF) actually included references to analyst estimates that they cited.

There are lots of other reasons to read this report aside from the fact that Imperva did a good job with their references. There's lots of interesting data about how the hacker threat is continuing to evolve. Here's how they summarize what's contined in this report:

• Hackers continue to increase the scale of their attacks: In our last report, we explained that websites are probed about once every two minutes, or 27 times per hour. Over the past six months, the number of probes has dropped to 18. Though a drop, this change does not mean hackers are any less persistent. In fact, when applications are attacked, hacker firepower actually saw a 30% increase. In July, we reported that applications experience about 25,000 attacks per hour. In the last six months, this has increased to nearly 38,000 attacks – or ten per second.

• Hackers exploit five common application vulnerabilities: We have identified and investigated malicious traffic containing the following technical attacks: Remote File Inclusion (RFI), SQL Injection (SQLi), Local File Inclusion (LFI), Cross Site Scripting (XSS) and Directory Traversal (DT). Cross Site Scripting and Directory Traversal are the most prevalent classical attack types.

• Hackers are relying on business logic attacks due to their ability to evade detection: We also investigated two types of Business Logic attacks: Email Extraction and Comment Spamming (EmExt and ComSpm, respectively, in following Figures and Tables). Comment Spamming injects malicious links into comment fields to defraud consumers and alter search engine results. Email Extraction simply catalogs email addresses for building spam lists. These Business Logic attacks accounted for 14% of the analyzed malicious traffic. Email Extraction traffic was more prevalent than Comment Spamming. A full anatomy of BLAs is described in this report.

• The geographic origin of Business Logic attacks were:
  • Email extraction was dominated by hosts based in African countries.
  • An unusual portion of the Comment-spamming activity was observed from eastern-European countries.

Is there really no innovation in information security?

According to a recent article on the CSO magazine web site, there's not enough innovation in the information security industry to let businesses keep up with the ever-changing threats that they face.

Is this really true?

Voltage has created an innovation or two, and because that's the sort of stuff that I see on a day-to-day basis, my first thought was that this can't possibly be true. After all, if we're doing it, others must be doing it too.

But then I remembered going last year's RSA Conference and how unimpressed I was by what vendors were offering. I didn't really see much that I thought was innovative. (No, no CEO claiming that the next 12 months were going to be "the year of PKI" doesn't count as the sort or innovation that we're interested in here.)

This year's conference isn't too far off. It starts at the end of next month, and this year I'll be looking at what I see at it in terms of checking whether or not the claim that there's not enough innovation in the industry is true. I hope that I'll see some good counterexamples, but I'm really not expecting to.

President's Challenge hacked

It looks like the President's Challenge web site has been hacked and users' data stolen. Here's what the email to users of the site said:

We are writing to inform you about a security issue involving the President’s Challenge website [www.presidentschallenge.org]. 

Hackers recently accessed our database, which included personal information such as your username, password, security question and answer, email address, date of birth, city and state, and, if you provided it, your name. The hackers were also able to access data such as your logged activities, your nutrition goals, what groups you are in, and messages you had sent and received within the online tracker. 

After we learned about the attack, we quickly took down the President’s Challenge website on January 11 and began the process of determining what information the hackers accessed and how it may affect you. We also contacted law enforcement to alert them to the hackers’ illegal activity.

Please note that we do not keep credit card numbers or Social Security numbers for users of our online tracker and shop. Regardless, we are alerting you so you can change your login information on any website where you might have used the same or similar username and/or password, and so you can generally monitor your personal and financial information.

We are in the process of securing the President’s Challenge website, and we expect to bring it back online within the next few days. Before you log in, you will be prompted to reset your password. You will then be able to log your activities and, for PALA+ users, your nutrition goals for the past three weeks. All of your previously logged activities and nutrition goals are still stored in the database.

We are sincerely sorry for this situation and any inconvenience or concern it causes you. We take your privacy very seriously. Before the attack, our website was routinely reviewed for security flaws. We are currently reviewing our security practices to make them even stronger and to reduce the probability of a future breach.

I haven't heard how many users were affected by this breach. The President's Challenge is somewhat popular with Boy Scouts, who can get some sort of recognition for completing it, so there may actually be lots of people affected by this breach, including lots of children.

XTS in Cryptologia

It looks like the article on the XTS mode of AES finally made its way into Cryptologia. If you don't subscribe to Cryptologia, you can get a copy of the article here, although you'll have to pay either $58 for the entire issue that it's in or $43 for the single article. Either price seems a bit high to me.

Not those sort of logs

As I've mentioned before, the number of records exposed in data breaches seems to follow a lognormal distribution, so that the size of breaches doesn't follow a normal distrubution, but the logarithm of their sizes does. This has led to more than one conversation that went roughly like this.

"The number of records exposed in data breaches follows a lognormal distribution. That means that the number of records exposed in breaches doesn't follow a normal distribution, or 'bell curve,' but the log of the number of records exposed does."

"Does that mean that we can use event logs to predict data breaches?"

"No."

A dot-com era story about digital signatures

Here's a dot-com era story that I was telling one of our engineers this morning. They suggested that I put it here, so here it is.

Back in the dot-com era, I worked for the information security group at a large accounting firm. It was called a "Big 5" accounting firm back then, before the troubles at Arthur Andersen reduced it to the Big 4. At this accounting firm we used Lotus Notes for email and other forms of collaboration, and Notes happened to give you the ability to sign or encrypt emails. This capability wasn't actually that useful because it really only worked inside the company, but that's a limitation that pretty much any email encryption product that uses digital certificates to manage public keys has.

In any event, the partner who ran the security group was very concerned that by digitally signing emails we were creating legally-binding contracts. Everyone in his group tried to explain to him how this wasn't true, but he either didn't understand what we were saying or decided not to follow our advice.

The result was a policy forbidding us to use digital signatures.

And because it can be hard to get policies changed at large organizations, I wouldn't be at all surprised if this particular organization is still forbidden from using digital signatures.

Maybe that's not quite true.

The people in this particular organization seemed to quickly figure out that their management didn't quite understand information security and there was soon a mass exodus of very talented people. I seem to recall that the group went from roughly 30 people to less than 10 people over a period of a month or two as people quickly quit and moved on to other jobs. The partner in charge of the group was quickly reassigned to a position that focused on just accounting, so it's entirely possible that his policy on digital signature use disappeared with him. But you never quite know with these sorts of policies.

Understanding risks and probabilities

I was just talking to a former co-worker who had just returned from Las Vegas. Although I've been to Las Vegas a few times, I've never gambled while I was there. The expected value of gambling is negative, after all, and I really don't think that I'd find gambling entertaining enough to justify calling any gambling losses an "entertainment expense." My former co-worker, on the other hand, always gambles when he's in Las Vegas.

When I explained my justification for not gambling – the fact that's the best you can do is to lose money in the long run – my former co-worker said, "But that's only if you play the best odds."

"And if you don't do that," I said, "you'll lose even more, won't you?"

Perhaps it's a good thing that this particular former co-worker doesn't work in information security or risk management any more.

Smeed's law and information security

 

Will Smeed's law apply to the dangers from hackers? Probably not. Here's why.

Smeed's law is based on a 1949 observation by Reuben Smeed that the number of deaths per vehicle from automobile accidents tends to decrease over time. So even if the numbers of cars driven increases dramatically, the number of deaths caused by cars will decrease even faster than the number of cars increases, resulting in fewer deaths per car.

Smead claimed that this was due to a sort of group psychology that understands and adapts to risks over time. Some data suggests (PDF), for example, that when cars with modern safety features are used in developing countries the fatality rates per car are as much higher than you'd expect for the same car driven in a more developed country, which is exactly what we'd expect from Smeed's law.

Let's suppose that that people's behavior actually causes Smeed's law. If that's true, we might expect them to adapt to the dangerous world of the Internet, learning to avoid phishing, etc., over time. But this doesn't seem to be happening. That's probably because the threat environment changes too quickly. What's a very serious information security threat today may not be serious at all a year from now, and a year may be too short of a time for the group psychology in Internet users to understand and adapt their behavior to the changing threat.

And unless the adaptation is close to perfect, it may not be enough to significantly affect the threat landscape. If people adapted to spam by never clicking on it, for example, then spamming would become unprofitable and the flood of spam would stop. But because it takes very few people falling for spam-based schemes for the schemes to be profitable, it's unlikely that it will ever be possible for enough people to adapt to spam enough to make it disappear. So even if the group psychology effect of Smeed's law is real, it seems unlikely that it's effects will ever be significant for the risks that information security manages.

More on the lack of qualified security people

As I've noted before, some people are claiming that the US government is facing a critical shortage of information security personnel, although this doesn't seem to be reflected by things like market forces.

The recent GAO report "Cybersecurity Human Capital" (PDF) also doesn't seem to support the claims that there's such a shortage. The GAO found that federal agencies were generally able to find qualified information security staff. The single notable exception that they list is the Department of Defense, which was still able to fill over 90 percent of their information security positions.

So I still can't find any reliable data that indicates that there's a shortage, critical or not, of information security personnel these days.

Quantum cryptography gets hyped again

I just came across a story on the Science Daily web site that seems to be little more than a slightly-disguised marketing message for quantum cryptography (also known as quantum key distribution). Here's what the story claims when it describes a successful year-and-a-half pilot of QDK technology:

Scientists and engineers have proven the worth of quantum cryptography in telecommunication networks by demonstrating its long-term effectiveness in a real-time network.

This story goes on to say this:

For QKD to become more widespread in the commercial world, its reliability needed to be thoroughly tested as these networks run constantly all year round.

I don't think that that's quite right.

Instead, for QKD to become more widespread in the commercial world there needs be a compelling need for it. That's what it takes to get people to pay for technology. And because existing cryptography works just fine, I don't think that we'll be seeing the widespread use of QKD any time soon. Perhaps ever.

But if you want to read more about the actual pilot, you can find the paper that describes it here.

How many information security people does the US government really have?

I just started to look at the GAO's recent report "Cybersecurity Human Capital." (PDF) When I read reports on the information security industry there's always always something that makes me stop and wonder exactly what's going on. This report didn't change that.

My first Huh? moment was actually when I looked at the cover page of this report. It turns out that this report was actually prepared by the GAO for the Senate Subcommittee on Immigration, Refugees, and Border Security, which is part of the Senate's Judiciary Committee. Acccording to the Subcommittee's web site, it's responsible for:

(1) Immigration, citizenship, and refugee laws;

(2) Oversight of the immigration functions of the Department of Homeland Security, including U.S. Citizenship and Immigration Services, U.S. Customs and Border Protection, U.S. Immigration and Customs Enforcement, and Ombudsman Citizenship and Immigration Services;

(3) Oversight of the immigration-related functions of the Department of Justice, the Department of State, the Department of Health and Human Services Office of Refugee Resettlement, and the Department of Labor;

(4) Oversight of international migration, internally displaced persons, and refugee laws and policy; and

(5) Private immigration relief bills.

So my first thought was to wonder exactly this particular Subcommittee came to be interested in information security staffing within the government.

I couldn't think of a good reason, so I moved on the actual report. I had made it to page 13 of the roughly 80 page document when I came across Table 2: Comparison of Reported Number of Cybersecurity Workers from Multiple Sources. This was another Huh? moment, but using at least a 36-point font this time.

It turns out that the estimates of the number of information security workers can vary greatly: if you ask the same agency more than once you can get very different answers each time. Some examples:

• The number of information security workers at the Department of Defense is apparently somewhere between 18,955 and 88,159.
• The number of information security workers at the Department of Homeland Security is apparently somewhere between 1,361 and 12,500.

This suggests a very inexpensive way to increase the information security staffing at government agencies: just keep asking how many people they have until you get an answer that's big enough.

Breaches and states of the US

There have been a few very big data breaches recently, which has changed the list of the 10 biggest breaches. That means that it must be time to create a bubble chart that compares the size of the 10 biggest data breaches with the populations of the 10 largest US states. Here's what that looks like:

Academic cryptographers versus commercial cryptographers

Last night I was asked why I distinguish between academic cryptographers and commercial cryptographers. Here’s roughly what I said.

Academic cryptographers invent things. Some examples of these things are the Diffie-Hellman key exchange, RSA encryption and Boneh-Franklin identity-based encryption. Academic cryptographers also invent ways to ensure that cryptographic schemes and protocols are secure. Practice-oriented Provable Security is an example of this.

Most of the creations of academic cryptographers aren’t really very interesting to most people, but that’s not a reflection on the academic cryptographers. Most academic work isn’t very interesting unless you’re a specialist in a very narrow field, and cryptography is just like other academic fields in this respect.

Academic cryptographers need to keep producing new ideas to keep their jobs.

Commercial cryptographers worry about practical implementations of the things that academic cryptographers invent. They turn what’s in the paper “Identity-based Encryption from the Weil Pairing” into Voltage SecureMail, for example. They understand the legal and regulatory environment of business and how cryptography fits into it. And they understand the real-world constraints that make some otherwise-interesting academic creations not very practical.

Commercial cryptographers need to keep producing things that are of value to someone else to keep their jobs.

One example of the difference between academic cryptographers and commercial cryptographers is in how they understand one particular aspect of identity-based encryption. Many academic cryptographers think that the fact that systems that implement IBE inherently have the ability to do key recovery is a bad thing because it makes it possible for a rogue administrator (some would even say the NSA) to decrypt their encrypted data. Commercial cryptographers think that the ability to do key recovery is a good thing because it’s absolutely necessary due to the legal and regulatory environment of business.

From the point of view of the academic cryptographers, they’re right. They don’t want anyone to be able to get access to any data that they might encrypt. Particularly the NSA. And from the point of view of commercial cryptographers, they’re also right. The market for encryption technology that doesn’t include the ability to do key recovery is extremely small. In the real world, CIOs get hit by buses and their replacement needs access to the data that their predecessor encrypted. Even more commonly, administrators need to recover keys for people who lost their keys or forgot the password that controls access to their keys.

But not everyone understands the difference between the two approaches to cryptography. Some people in the business world try to approach cryptography from the point of view of academic cryptographers, and when they do this, it almost always causes problems. I actually come across this fairly often.

I don’t have any firsthand experience with this, but I’ve heard stories of how people in the academic world who try to approach cryptography from the point of view of commercial cryptographers also encounter problems. The places where they work typically put more value on inventing new things, so practical implementations are often considered not as good as less practical, yet new, inventions. So it’s easy to imagine an academic cryptographer who spends his time creating a successful business having problems with his academic department because that’s not the sort of behavior that they want to see.

So the bottom line is that there are really two different approaches to cryptography. The specialized background needed for academic cryptography is too expensive for most of the commercial world to support and the practical approach of commercial cryptographers isn’t really suitable for academic environments. But we really need people working on both aspects of the field if we’re going to see useful progress in the future.

What's more important - compliance or security?

I just came across an interesting bit of information in Kaspersky Lab's June 17, 2011 Global IT Security Survey (PDF) report. Most other surveys that I've read about say that people in IT security are more worried about regulatory compliance than about actual strong and useful security. The Kaspersky report, on the other hand, says the exact opposite. Of the 11 areas that they asked people to prioritize, "Preventing IT security breaches" was deemed to be the most important and "Complying with industry regulations and standards" was deemed to be the least important. This varies so much that I'm left wondering how this puzzlinng result could be explained.

My first thought was that the Kaspersky survey might have polled a different type of person than the other surveys did. Here's how the Kaspersky report describes their methodology:

More than 1300 senior IT professionals from 11 countries took part in the survey. All respondents had an influence on IT security policy, and a good knowledge of both IT security issues of general business matters (finance, HR, ,etc.) Geographically, the survey was conducted in 11 countries, including both those with developing and mature economies.

Other surveys, like the CSI Computer Crime and Security Survey and Ernst & Young's Global Information Security Survey give a fairly detailed breakdown of the roles of the people that responded to the survey. That's something that's missing in the Kaspersky report, so it might be the case that people like CSOs tend to reply to the CSI and E&Y surveys while people responsible for getting the work done tend to reply to the Kaspersky survey. That difference might explain the different focus on what's the most important. Or it might not. In any case, I'll definitely be looking at future reports to see whether what Kaspersky found also appears in other reports.

BFF version 2.0

I finally got around to trying CERT's Basic Fuzzing Framework 2.0. It's been out since February, but there always seemed to be something more important to do than try it. (Things like making graphs of projective curves, etc.) BFF is actually based on the zzuf fuzzer, but has some useful additions, like the statistics and data visualization tools that you now get with BFF 2.0.

If you haven't already tried BFF 2.0, it's probably worth checking out. It seems to be a good tool for finding application-level vulnerabilities and the price (free) is certainly right.

Data breaches caused by internal agents

According to Verizon's 2011 DBIR, here are the percentages of breaches caused by various types of internal agents. Average employees cause most breaches, not people with above-average access or permissions. Here's what their data looks like. The values are percentage of breaches caused by a particular type of agent.

 

Why Most Published Research Findings Are False

 

I just came across an interesting article ("Why Most Published Research Findings Are False", by John Ioannidis) that talks about how lots of research that seems to find statistically-significant results ends up being wrong. Here's the article's summary that describes what it covers. Note that this only applies to cases where a conclusion is based on a statistical analysis of data. It doesn't apply to research in areas like math where everything has a proof.

There is increasing concern that most current published research findings are false. The probability that a research claim is true may depend on study power and bias, the number of other studies on the same question, and, importantly, the ratio of true to no relationships among the relationships probed in each scientific field. In this framework, a research finding is less likely to be true when the studies conducted in a field are smaller; when effect sizes are smaller; when there is a greater number and lesser preselection of tested relationships; where there is greater flexibility in designs, definitions, outcomes, and analytical modes; when there is greater financial and other interest and prejudice; and when more teams are involved in a scientific field in chase of statistical significance. Simulations show that for most study designs and settings, it is more likely for a research claim to be false than true. Moreover, for many current scientific fields, claimed research findings may often be simply accurate measures of the prevailing bias. In this essay, I discuss the implications of these problems for the conduct and interpretation of research.

In addition to explaining why most claimed research findings are false, this article lists five corollaries to its main claim. These aren't quite a rigorously supported as the main claim, but they're interesting because they seem to explain some of the less-accurate-than-we'd-like-it-to-be data that we often see in the field of information security.  

1. The smaller the studies conducted in a scientific field, the less likely the research findings are to be true.
2. The smaller the effect sizes in a scientific field, the less likely the research findings are to be true.
3. The greater the number and the lesser the selection of tested relationships in a scientific field, the less likely the research findings are to be true.
4.  The greater the flexibility in designs, definitions, outcomes, and analytical modes in a scientific field, the less likely the research findings are to be true.
5. The greater the financial and other interests and prejudices in a scientific field, the less likely the research findings are to be true.

So even if it's frustrating to deal with the lack of accurate data that field of information security seems to be stuck with, it's somewhat reassuring to see that we're not alone in having this problem.

The list of the 10 biggest data breaches changes AGAIN

The recent data breach at the on-line gaming company Steam that exposed roughly 35 million customer records is now tied for 6th place in the list of the biggest breaches ever. Here's how the list currently looks. Note that three of the top ten have actually happened in the past year. That's probably not a good sign.

Organization	Records	Year
Heartland Payment Systems	130,000,000	2009
TJX	94,000,000	2007
TRW	90,000,000	1984
Sony Corporation	77,000,000	2011
CardSystems	40,000,000	2005
SK Communications	35,000,000	2011
Steam	35,000,000	2011
RockYou	32,000,000	2009
U.S. Department of Veterans Affairs	26,500,000	2006
HM Revenue and Customs	25,000,000	2007

Why people aren't good at estimating probabilities

I just came across a good description of why people aren't very good at estimating probabilities. This was in "Are Humans Good Intuitive Statisticians After All?" by Leda Cosmides and John Tooby, all 73 pages of which was published in Cognition back in 1996. Here's what they said:

In the modern world, we are awash in numerically expressed statistical information. But our hominid ancestors did not have access to the modern system of socially organized data collection, error checking, and information accumulation which has produced, for the first time in human history, reliable, numerically expressed statistical information about the world beyond individual experience. Reliable numerical statements about single event probabilities were rare or nonexistent in the Pleistocene - a conclusion reinforced by the relative poverty of number terms in modern band-level societies. In our natural environment, the only database available from which one could inductively reason was one's own observations, and possibly those communicated by the handful of other individuals one lived with.

So it shouldn't be too surprising that we're not good at this. But because information security concerns dealing with uncertain events and the damage that they can cause, understanding the probabilities of the uncertain events is important to doing it well. Unfortunately, it looks like we're just not meant to work that way.

Cryptography and Security at arXiv.org

The best place to find preprints of papers on cryptography is probably the IACR's eprint preprint server. But it looks like there's also another place to find this type of preprint, and that's the on the arXiv.org preprint server that's maintained by Cornell. It turns out that they have a section for Cryptography and Security, although there aren't many papers there yet. Maybe it will get more useful in the future.

What does 15,360 bits look like?

According to NIST's guidelines, it takes a 15,360-bit RSA or Diffie-Hellman key to provide the same level of cryptographic strength as a 256-bit AES key.

What does a 15,360-bit key look like?

A 15,360-bit number has about 4,624 decimal digits. Here's what a number with 4,624 decimal digits looks like. It's big. Doing public-key operations with numbers that big is slow.

Don't use them unless you absolutely have to.

94598000209149914523662835549475089923370892004800021803369459826940368587029734135
53140333404205082341000224410481949851574795432979265755760040881222220641300023125
50737421110002040128607469796644894392870725815000246360649329165053448440219525634
36517708207207317900002561196904462645747774519243372965394595934258260527000261547
44526695270799535936783848823961011833211594660002794557285736789754387546224443191
19042592929274597300028424811621397344072116868487670307112059257014667000029235237
83177320889837689359141626252296630552282562000300449352494752463382445862510256196
27933565337124720003100549976546405188159961196389654692823912328729529000323596315
30726898093543335135462779745002490103393330003359808083914542726842836094970013021
24892785652010600034460588523601390922867728144077939108364770617429410003532179005
97873792524105567070078674317157853941183800036692346140620117452041595660000187439
24239711896338000371956541430017587537940419215856667436806849628520700038451551493
81947607246436679454359047900332082669541000399486431994361681085134888815530154035
45605014511760004098086248264524028404449990889639094734073544131880000413318516232
41941509498943548581886954199437548730430004280951004069638270774201512338725016252
98946246117100043797524914071961282966986102591748522053900387595790004418633325379
81450657131010246740545561427779389193600045740294390277557322709779017119525275802
18081451748000465417845611809933714305335129695612719255360409032400047116644988352
07984827593817153909973334408846123356000484832477928312496471002295368703230757546
15020099940004969074941388763791976355840440110518216150184876938000500918820097328
25395270422086304833898737464278580440005190045854975198150654949388199791870761506
84766465900052731895020747677262696229064464271246701841361827600005375768764902097
18774990429122729537505871938234317800054540164405666281310030068227398207145329507
70617813000550835869910785424278513661588730461897553312230842000056283060326481333
10591405100789332604604759411901840000575384086233815941362851215902902846668795777
62207910005891757537416161362269502639021255781765148348347055000598941592694003975
83911260717646489497230694541374080006077513038208686429901684148277451908139807289
35550700061195023717469979202885521029773742877525165344674150006221818593139327881
75705686731560708285046318533845200063514746649968107236219404991345428360919108007
45449000649955968331625352417069777128307481978142438607283400065337134800793584728
69519266472158303298229317493972000668527486893113032297028834341377351590400711484
36430006784133896404403552166738527009161222605616232718423000685673216234173959613
11012391622854965756081604188800006965138568068764885261343136586145875210698564447
27700070380010217681719117117160292937742196404965584496980007137402963970130477586
56271100864732462605400303743800072971254034887083314172181539250752376204715501295
78000732182641134471433407264638859024913906441038565455200074731354274295719090358
57947429608789881566469119202000750763877929030611807296207441562382199538047136699
40007660528834410795419814591752069505533521396121206455000778359635655069589298305
12809719774335378392301504980007810850627469959910507134990631953075718390641019362
00079398209895243622631476442180814438000935131024731670008059580064787556978800888
35544862376806156041110840800081385080734123793487639082297022177190420795954499530
00823069270668946881612756196800918206763400054626920000083654439565918288274374963
22404108337656769629990836000842726750264131927229407477446061798548911973413035800
08591307069911907224210366995372828825357932897666252000866843494688844731362262126
98408128438259009815931460008748908158775474524591357000475483824526925413055160000
88069134519742672786011188309528630119890114974403440008910455160191421033712913423
78218832580851436677088300090128839734365027611840428501392179741507790712267690009
12177830976388073696131649420966328102023088164744900092195235951565122596598628368
25869572137981643591529000936724552670355831656379246866867646334222266559080200094
60584473770750037992451342652926760836374132644344000955385341377360669485058838738
59493647333196240436420009624637387367438489342526230799212369186010374283873000978
30801245138992228150775951777973772758551972378670009816444243343615199073274937093
98513032552548465475900099607901815757178657621116178576458195297965130048600010003
99110461937161689466083246538460958232886181916100101385559555432886597800835560860
29735477627129923853001021754673704920524621555121292815907607936279545890900103326
43528619581906831009119893676355937798086300514001046957268

Data-centric security for a data-centric world - #voltagelive 2011 in NYC

New innovation and emerging technology brings with it opportunities for streamlining costs, eliminating hurdles for end users and reducing risks to the business. However, implementing game changing solutions can be unique to your environment, policies and processes.

That's why I invite you to join Voltage Security at its first customer summit in New York City on November 9, 2011. The summit will focus on data-centric security and will feature top Voltage customers such as Amex, Wells Fargo, State Street and others, who will discuss how they implemented encryption projects for mail, data and payments. Also presenting will be Eric Ouellet, research vice president with Gartner Group, who is currently developing new analyses of how companies use encryption. The summit features customers talking to customers—at last count this includesAmerican Express, BJ's Wholesale Club, Citigroup, Deutsche Bank, Fidelity Investments, JPMorgan Chase, UBS, State Street Bank andWells Fargo. The goal of the summit is to enable Voltage customers to network with each other and pick up valuable best practices. If you're interested in attending, please visit www.voltage.com/live.

The theme is 'Data-centric Security for a Data-centric World,' it's an area of huge attention. Data is the lifeblood of industry, commerce and leisure, every business and every transaction. That's why protecting it is such a serious and difficult responsibility. 

Here's a quick scan of the Hot Topics we have on tap at Voltage Security Live 2011:

Cloud Data Security Data-centric Encryption Ecommerce Security

Email Encryption Mobile Data Security Payment Security

There's no question that every company continues to face a long serious of challenges related to these topics. The conference is designed to tackle specific issues and help formulate achievable solutions. The areas to be covered include:

• How to fund and integrate a data-centric strategy into your overall security program
• Best practices for data-centric encryption based on real-world implementation at a Fortune 50 Bank
• How to roll out encryption projects successfully across the organization and end-user community
• Successful phases for fast and non-disruptive implementation—what you need to do before during and after an implementation
• Elements of key management architecture and design
• The role of cloud and mobile data-centric security

Voltage Security Live 2011 will bring together the brightest minds in our field, all with considerable experience. There will be representatives from teams responsible for implementation, as well as enterprise and security architects looking for, and developing, best practices for data-centric encryption. 

The sessions will cover customer project case studies addressing issues such as how to maximize end-user adoption for your B2C implementations and implementing data-centric encryption projects, while the Customer Track focuses on panel discussions and presentations on topics such as protecting outsourced data, eDiscovery and Archiving and securing application emails. There's also an Architecture Track, featuring panel discussions and presentations on topics such as key management architecture, security policy, enterprise applications and the web services API and scalable design considerations. And there's the Security Panel, with a discussion and general Q&A featuring leaders from the security community—Gartner Security Analyst, Encryption Architects, QSAs. 

There's going to be a broad cross-section of security specialists attending, but some executives will find it particularly enlightening: CXOs and security leaders responsible for security strategy and programs; VPs/Directors responsible for security implementation; and architects responsible for security and application and enterprise architecture. If you have one of these roles, we think this conference is exactly right for you. 

We know there are constant demands on your time - we hope to see you there.

Register at www.voltage.com/live

The CDC's plans for zombie outbreaks

Back in May, someone at the CDC did a blog post about how to prepare for an outbreak of zombies. Here's how the CDC would respond to such an unprecenented event:

If zombies did start roaming the streets, CDC would conduct an investigation much like any other disease outbreak. CDC would provide technical assistance to cities, states, or international partners dealing with a zombie infestation. This assistance might include consultation, lab testing and analysis, patient management and care, tracking of contacts, and infection control (including isolation and quarantine). It’s likely that an investigation of this scenario would seek to accomplish several goals: determine the cause of the illness, the source of the infection/virus/toxin, learn how it is transmitted and how readily it is spread, how to break the cycle of transmission and thus prevent further cases, and how patients can best be treated. Not only would scientists be working to identify the cause and cure of the zombie outbreak, but CDC and other federal agencies would send medical teams and first responders to help those in affected areas (I will be volunteering the young nameless disease detectives for the field work).

Now I really doubt that the CDC actually has plans for how to handle a zombie outbreak, but when I read this I wondered what other events some government agency has actually planned for. Do they have plans for deflecting killer asteroids from Earth like shown in the movie Armageddon? Do they actually have plans for how to handle an invasion by aliens like shown in the movie War of the Worlds? (H. G. Wells' book did indeed come first, but I'd guess that any plans are based on the movie version, not the book version.)

What about more realistic, yet very unlikely, threats? What happens if a clever hacker finds a way to break the ubiquitous RSA encryption algorithm? What happens if a hacker manages to get into the air traffic control network? I wouldn't be too surprised if things like these are planned for, but I'd also guess that the plans are classified, so we'll probably never quite know what our governments have planned for us.

Webcast - What's New in Crypto for z/OS?

Our marketing people are having another of their fine webcasts. This one tells you about what sort of new encryption technology is available for protecting data on z/OS mainframes. It's sponsored by IBM and will take place at 10 a.m. (Pacific) on November 15, 2011 and will last for 60 miniutes. If this sounds interesting, you can sign up for this event here.

Here's an overview of what this webcast will cover:

Mainframes remain the core of business-critical operations in most of the world's largest and most successful enterprises, including those in banking, insurance, healthcare, and retail. But as IT management will attest, there can be issues with complexity when it comes to securing critical information on the mainframes running on z/OS.

Implementing an encryption solution can be disruptive to business operations and require hundreds of lines of code to acquire and store keys and perform cryptographic operations. Adding to the complexity are the deep expertise and highly specialized knowledge needed to keep all the moving parts working. Not only that, roughly 80% of z/OS customers use CICS, yet many vendors offer no developer abstraction to make it easy to encrypt from CICS transactions.

In this webcast we'll discuss proven strategies for easily implementing data security in the z/OS environment.

We'll also cover:

• Extending the proven security and defenses of the mainframe to protect information assets against new world threat to data 
• Pros and cons of various types of encryption and key management
• Achieving system interoperability with a data security platform approach
• Simplified key management that virtually eliminates key management issues
• A native z/OS encryption implementation that's easy to use with CICS or any z/OS environment

Telling the future with Cleverbot

It looks like we won't be using anything except elliptic curves or hyperelliptic curves for a while. At least that's what the almost-certainly-authoritative Cleverbot thinks will happen.

  

Voltage Customer Summit #VoltageLive - Only 23 Spaces left

 *** Only 23 spaces left ***

Voltage Security invites you to "Voltage Security Live 2011" at Bridgewaters in New York City on November 9, 2011. This customer summit will focus on data-centric security and will feature several leading Voltage customers, such as American Express, Wells Fargo, State Street and others, who will discuss how they have implemented encryption projects for email encryption, data-centric encryption and end-to-end payment encryption. Also presenting will be Eric Ouellet, research vice president with Gartner Group, who is currently working on a new analysis of how companies use encryption. The goal of the summit is to enable Voltage customers to network with each other and pick up valuable best practices.

Stop Press: Thanks to our sponsors - Coalfire, OpenPath, Teradata and Thales, we are able to offer registration for eligible particpants at no cost.  Register now at www.voltage.com/live

Join Voltage customers including: ADP, American Express, Bank of America, AT&T, Citigroup, Deloitte, Deutsche Bank, Elavon, Fidelity Investments, Heartland, JPMorgan Chase, McGraw-Hill, UBS and Wells Fargo. 
.
Highlights of the agenda include:

• CxOs Panel – Business dynamics for data-centric encryption security – How to get your security project funded
• Key Note – Eric Ouellet, Vice President Research, Gartner Group                      
• How to maximize customer adoption – Kim Mroczkowski, Wells Fargo
• 4. How to structure a data-centric encryption project – Emily Mossberg, Deloitte
• 5. “Birds of a Feather” Networking lunch
• 6. Tracks: Customer and Best Practices – American Express, State Street, Thales, PwC, Coalfire 
• 7. Security Leadership Panel – Gartner Group, State Street, American Express, Wells Fargo

Stop Press: Thanks to our sponsors - Coalfire, OpenPath, Teradata and Thales, we are able to offer registration for eligible particpants at no cost.  Register now atwww.voltage.com/live 

 

The biggest risks, according to E&Y

According to Ernst & Young's Business Risk Report 2010, here are the top 10 risks that businesses are facing today:

1. Regulation and compliance
2. Access to credit
3. Slow recovery or double-dip recession
4. Managing talent
5. Emerging markets
6. Cost cutting 
7. Non-traditional entrants
8. Radical greening
9. Social acceptance risk and corporate social responsibility
10. Executing alliances and transactions

Regulation and compliance is at the very top of the list this year. That's up from position 2 last year. It was also number 1 in 2008.

But there's a lot more to regulatory compliance that just the things that information security deals with. Here's how E&Y described the risks that businesses face from regulation and compliance:

Regulation and compliance has remained one of the most prominent risks since 2008 when these reports began. In 2008, regulation and compliance risk topped the global list. In 2009, this risk was only exceeded by worries about the credit crunch. For 2010, regulation and compliance has resumed its place as the Number 1 threat, not only for financial services, but also across a spectrum of sectors, from oil and gas to real estate, and from life sciences and technology to telecoms. Compliance risks are also notable in the automotive sector and the power and utilities sector.

For the financial services sector, the risk of encroaching regulation is still growing with severe worries regarding a poorly designed regulatory response to the credit crisis. Coordination among governments worldwide has the potential to fall by the wayside, increasing the risk of uncoordinated and conflicting new regulation. Banking executives and academic analysts expressed concern that this could result in an over-regulated sector and greater protectionism, preventing global firms from effectively operating across borders.

Our interviewees worried that, in the wider financial sector, regulatory reform proposals have the potential to destroy customer and shareholder value. "New taxes and higher capital requirements will impair the industry’s ability to absorb risk, impose a competitive disadvantage when it comes to attracting capital relative to other financial market players, and more broadly constrain the industry’s ability to meet its social and economic function as ultimate holder of risk," wrote Daniel Hofmann, Group Chief Economist at Zurich Financial Services. Firms need to rebuild trust, and act in concert to convince governments, regulators and the public at large that their activities do not create systemic risks.

Uncertainty over regulation was another problem raised by many panelists this year. Uncertainty both damages investment and the ability of companies to act. "Governments need to move fast to remove uncertainty, particularly regarding regulation of the financial sector," wrote one panelist. Similar concerns were raised beyond the financial services sector in telecoms, power and utilities, and oil and gas.

Companies can take a number of steps to respond to this risk. First among these is planning ahead and preparing for expected changes in regulation now, rather than waiting for regulations to be imposed. Trying to respond to new regulatory standards in a short space of time can be difficult, especially in a climate where forbearance may be scarce. Avinash Persaud, an independent consultant on finance and policy, commented that forthcoming regulations were likely to favor banks with larger deposits. To respond proactively to such fundamental changes may require companies to take a long view on possible regulations and consider alternate scenarios.

So information security is part of the biggest risk that businesses are facing today, but there are also lots of other issues related to regulations and compliance that are making life difficult for people in the business world. So don't be surprised if the divisions tasked with ensuring regulatory compliance grow significantly over the next few years. And also don't be surprised if most of that growth is in areas other than information security.

The US government still can't quite get information security right

According to a recent report from the US Government Accountability Office, the US government still can't quite figure out how to do a reasonable job of information security. Here's part of how the report summarized what it found:

Weaknesses in information security policies and practices at 24 major federal agencies continue to place the confidentiality, integrity, and availability of sensitive information and information systems at risk. Consistent with this risk, reports of security incidents from federal agencies are on the rise, increasing over 650 percent over the past 5 years. Each of the 24 agencies reviewed had weaknesses in information security controls. An underlying reason for these weaknesses is that agencies have not fully implemented their information security programs. As a result, they have limited assurance that controls are in place and operating as intended to protect their information resources, thereby leaving them vulnerable to attack or compromise.

I understand that government agencies work under a different set of constraints than the rest of the world does, but I can't quite understand how they can keep failing reviews of their information security programs year after year. Well, I actually can understand that. Maybe what I can't quite understand is how the CIOs at the government agencies keep their jobs after failing for so many consecutive years. In the real world, they almost certainly wouldn't. 

Maybe they need something more than the fear of having to testify before Congress about their failures to motivate them. After all, it certainly looks like no matter how good a job the bureaucrats do there's always some politician willing to try to make them look bad to score a few political points. Because of this, the bureaucrats probably quickly learn to suffer through meetings with Congress and ignore what's said at them.  

So maybe this is yet another area in which the government needs to learn a lesson or two from the private sector. Information security isn't just managed differently in the private sector - it's also managed better.

A disturbing development in the Common Criteria

According to a post on Josh Brickman's blog, from what we say at the most recent International Common Criteria Confererence, it looks like countries are starting to weasel out of their commitments to recognize Common Criteria certifications. There are supposed to be exceptions to the recognition of CC certifications, but as far as I can tell, the exceptions are supposed to be limited to classified information. Here's what Article 3 (Exceptions) of the CCRA Agreement (PDF) say about this:

If to recognise a Common Criteria certificate would cause a Participant to act in a manner inconsistent with applicable national, international or European Community law or regulation, that Participant may decline to recognise such a certificate. In particular, in cases where an IT product or a protection profile is being considered for an application which involves the protection of information attracting a security classification or equivalent protective marking required or authorised under the provisions of national law, subsidiary legislation, administrative regulation or official obligation, Participants may decline, in respect of that application only, to recognise a certificate.

The way that countries are trying to avoid really making CC certifications common seems to be requiring that certifications that they recognize are only against protection profiles that they recognize (i.e., write themselves). From my reading of the CCRA Agreement, that's actually not a valid approach. Here's Article 2 (Scope) of the CCRA that leads me to believe this:

It is mutually understood that, in respect of IT products and protection profiles, the Participants plan to recognise the Common Criteria certificates which have been authorised by any other certificate authorising Participant in accordance with the terms of this Arrangement and in accordance with the applicable laws and regulations of each Participant. This Arrangement covers claims of compliance against any of the Common Criteria assurance components required for Evaluation Assurance Levels 1 through 4. Extension of the scope may be agreed by the Participants in this Arrangement at any time, in accordance with the provisions of Article 14, by adding other assurance levels or components.

I don't see how the approach that Brinkman sees countries trying is consistent with that.

The Common Criteria doesn't really give a very useful evaluation from the security point of view. Its big benefit is that lots of countries recognize it. So instead of getting several expensive and meaningless certifications done (one for each country whose government you're trying to sell to), you only need to get one expensive and meaningless certification done. This makes life much easier for vendors. It also saves governments money because they don't end up absorbing the additional costs that getting lots of different certifications causes. The approach that countries seem to want to try seems to make like easier for neither vendors nor national governments. Vendors will get stuck doing multiple CC evaluations and they'll pass the costs of these evaluations on to their government customers who will then end up paying for for evaluated products.

The governments who are trying to essentially eliminate the value of getting a CC certification should really think about the implications of what they're trying to do. What they're proposing won't actually benefit anyone.

The CWE Bug Barrel

If you've attended recent security conferences you might have seen t-shirts with this code snippet on them:

1 printf("<title>Blissfully Ignorant, Inc.</title>");
2 ftype = Get_Query_Param("MessageType");
3 strcpy(fname, "/home/cwe/");
4 strcat(fname, ftype);
5 strcat(fname, ".dat");
6 handle = fopen(fname, "r");
7 while(fgets(line, 512, handle)) {
8   if (strncmp(line,"<script>",8)) {
9     printf(line); } }
10 return(200);

This is the CWE "Bug Barrel" and it's designed to illustrate lots of the common coding errors that can cause application vulnerabilities. This example actually has examples of 10 CWEs, or an average of one per line of code.

You can get MITRE's list of the weaknesses in this code and the attacks that could be carried out based on them here. But you should definitely try to find them yourself before looking at the solution.  

What do hackers like to talk about?

According to Impervia's recent Hacker Intelligence Initiative, Monthly Trend Report #5 (PDF), hackers like to talk about DOS/DDOS, SQL injection and spam. According to what Impervia learned by monitoring hacker forums, hackers spend over half their time talking about those three topics. Here's the overall breakdown of what hackers talk about (by the number of forum threads on the various topics):

The Impervia report contains lots of other interesting bits of trivia about hackers, like the fact that an estimated one on four US hackers is an informant for the FBI or Secret Service. It's well worth downloading and spending a few minutes reading.

Are successful CISOs good or just lucky?

A while ago I noted how information security is probably more like poker than craps because there's more than just chance involved. Recent research (PDF) by Steven Levitt and Thomas Miles seems to indicate that this is actually true. They found that more successful players tend to win more at poker than average players do. That's something that you wouldn't expect to see in games that were just games of chance.

But not all successes that we might think of as being due to skill are really due to skill. Some research has suggested (PDF), for example, that the performance of successful mutual fund managers is more easily explained as good luck instead of a higher level of skill or superior knowledge.

What about CISOs? Do successful CISOs have superior skills or knowledge that significantly affect the performance of their organizations? Or are they just lucky?

I haven't seen any research that tries to answer this question, but I'd guess that the element of luck is getting more and more important. Today's software is extremely complicated, and with that complexity comes all sorts of bugs, some of which affect security. And because all software has bugs, it's probably possible for a clever hacker to find them and exploit them in any software. You might be able to find strategies that minimize your chance of hackers finding and exploiting them, but the chances of this happening never drops to zero. This means that no matter how good a CISO is, there's always a chance of their systems being hacked. And because the chance of being hacked is always there, maybe it's more luck than CISO skill that determines whether or not a particular business gets hacked.

And because so many decisions are now made for compliance reasons instead of a CISO thinking that a particular strategy is good, I wouldn't be surprised if the affects of chance are getting greater and the affects of CISO skill are getting smaller. And because software is likely to get more complicated in the future and regulatory compliance is likely to become a bigger factor in information security strategies than it is now, it might also become more and more difficult for good CISOs to make a difference in the future.

That's a lot of laws and regulations

From an article in Government Computer News:

There currently are at least 20 bills dealing with cybersecurity and information security pending in the Senate, and at least 13 more in the House.

That's a lot of laws and regulations.

Gaffney v. TRICARE: legal wrangling begins over the SAIC/TRICARE data breach

It looks like a Maryland law firm has already filed a class-action suit (Virginia E. Gaffney , J.G. , E.G.  and Adrienne Taylor v. TRICARE Management Activity, United States Department of Defense and Leon E. Panetta, or Gaffney v. TRICARE for short) that tries to recover damages of $1,000 per person affected by the recent data breach that exposed the personal information of roughly 4.9 million TRICARE members. That's a total of $4.9 billion in damages, of which the lawyers will no doubt try to keep a significant fraction.

But courts have been very reluctant to award anything to victims of data breaches who can't show that actual financial damages resulted from a breach. Just saying that your risk of damage has increased usually isn't enough. So unless some judge somehow discovers a new interpretation of the law that applies to this particular breach, I expect to see this suit eventually dismissed.

Engineering Security

 

Peter Gutmann's book Engineering Security (PDF) is one of the best single books that I've found on the topic of information security. It collects all sorts of information that's both useful and interesting, and it seems to be the only place where this type of information is collected. If you read a chapter of this book, you're able to amaze and astound people with the fascinating information security knowledge that you have.

My memory's not as good as it used to be, so for me, this effect wears off after a couple of weeks. But for those couple of weeks, I look much smarter than I really am.

I don't know if this book has found a publisher yet, but it's definitely the sort of book that deserves to be printed.

Problems with the Ponemon data breach studies

 

The Ponemon data breach studies are one of the few sources of information that we have about data breaches, but their results may either overestimate or underestimate the true cost of a data breach because the breaches that are looked at in these studies aren't really representative of all breaches.

As I've noted before, the size of data breaches follows a lognormal distribution fairly closely. Historically this distribition has had a logmean (base 10) of about 3.4 and a logdeviation (base 10) of about 1.2. In other words, the base 10 logarithm of the breach size follows a normal distribution or "bell curve."

But when we look at the breaches that the Ponemon studies look at, the breaches don't seem to be representative of all breaches. The 2010 report (PDF), for example, looked at US breaches that exposed between 5,010 and 101,000 records. Here's what we get when we graph that range (of the log) of breach sizes:

 
    

So it certainly looks like that range of breaches isn't really representative of all breaches. It only includes breaches that are above-average in size but aren't too big, and it only represents about 31 percent of all breaches.

The Ponemon reports claim that they're carefully tailored to be representative of companies that suffer data breaches. As their 2010 U.S. Cost of a Data Breach report said,

This benchmark study examines data breach costs resulting in the loss or theft of protected personal data. As a benchmark study, Cost of a Data Breach differs greatly from the standard survey study, which typically requires hundreds of respondents for the findings to be statistically valid. Benchmark studies are valid because the sample is designed to represent the population studied. They intentionally limit the number of organizations participating and involve an entirely different data-gathering process.

A more representative sample of breaches would also include companies that suffered breaches that are both much larger and smaller than those interviewed for the 2010 report. Because those breaches weren't considered in this report, there's a good chance that the report either overestimates or underestimates the true cost of data breaches. Maybe we'll find out which one in a future report.

Social Networking Security Awareness

As part of National Cyber Security Awareness Month, there's a webinar on October 20 from noon to 1 pm (Pacific) on the topic of Social Networking Security Awareness. Here's a summary of what will be discussed:

Social Networking sites like Facebook, MySpace, Twitter, and LinkedIn are a topic on everyone's lips today – our kids communicate with them, our customers are on them, our employees request access to them, but what are the risks associated with using these sites? This session will discuss the security and technology concerns related to Social Networking sites and how to safely use them.  Special attention will be given to Facebook.

If that sounds interesting, you can sign up for this event here. 

Medical identity theft is the worst in Miami

The World Privacy Forum has an interesting interactive map that shows how common medical identity theft is. You can pan around the map and zoom in and out to get an idea of how common medical identity theft is. The highest level view of the map certainly seems to say that Florida is the worst place for it.

And if we zoom in on Florida, it looks like Miami is where the worst of it happens.

The WPF even has a more detailed white paper ("MEDICAL IDENTITY THEFT: The Information Crime That Can Kill You" (PDF)) that you can read to learn more about this subject. Here's a summary of what the report says:

This report finds that medical identity theft is deeply entrenched in the health care system. Identity theft may be done by criminals, doctors, nurses, hospital employees, and increasingly, by highly sophisticated crime rings. The report finds that medical identity theft victims need an expanded right to correct their medical files in order to recover from this crime, and need more specialized consumer education that is focused on correcting the specific harms of medical identity theft. Key recommendations in the report include:

• Individuals’ rights to correct errors in their medical histories and files need to be expanded to allow them to remove false information from their files.
• Individuals should have the right to receive one free copy of their medical file.
• Individuals should have expanded rights to obtain an accounting of disclosures of health information.
• Studies are needed to determine what the incidence of medical identity theft is, how and where it is occurring, and how it can be detected and prevented.
• Notification of medical data breaches to consumers has the potential to save lives, protect health, and prevent losses.
• All working prototypes for the National Health Information Network need
  comprehensive risk assessments focused on preventing medical identity theft while protecting patient privacy.

If you're interested in the subjects of privacy and identity theft, this paper's probably worth reading.

Is PKI really that complicated?

X.509-based PKI has a reputation for being bad in many ways - expensive, hard to use, too complicated, etc.

But is it really that complicated?

To find out, I looked at the number of RFCs that the IETF's PKIX working group has published to date. Then I made the mistake of making a table of them. That took quite a while. There are actually 62 of them, which certainly seems like enough documents to make the technology qualify as "complicated."

Here's what's been written so far:

Document	Title
RFC 2459	Internet X.509 Public Key Infrastructure Certificate and CRL Profile
RFC 2510	Internet X.509 Public Key Infrastructure Certificate Management Protocols
RFC 2511	Internet X.509 Certificate Request Message Format
RFC 2527	Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework
RFC 2528	Internet X.509 Public Key Infrastructure Representation of Key Exchange Algorithm (KEA) Keys in Internet X.509 Public Key Infrastructure Certificates
RFC 2559	Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2
RFC 2560	X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP
RFC 2585	Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP
RFC 2587	Internet X.509 Public Key Infrastructure LDAPv2 Schema
RFC 2797	Certificate Management Messages over CMS
RFC 2875	Diffie-Hellman Proof-of-Possession Algorithms
RFC 3029	Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols
RFC 3039	Internet X.509 Public Key Infrastructure Qualified Certificates Profile
RFC 3161	Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)
RFC 3279	Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
RFC 3280	Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
RFC 3281	An Internet Attribute Certificate Profile for Authorization
RFC 3379	Delegated Path Validation and Delegated Path Discovery Protocol Requirements
RFC 3628	Policy Requirements for Time-Stamping Authorities (TSAs)
RFC 3647	Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework
RFC 3709	Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates
RFC 3739	Internet X.509 Public Key Infrastructure: Qualified Certificates Profile
RFC 3770	Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN)
RFC 3779	X.509 Extensions for IP Addresses and AS Identifiers
RFC 3820	Internet X.509 Public Key Infrastructure (PKI) Proxy Certificate Profile
RFC 3874	A 224-bit One-way Hash Function: SHA-224
RFC 4043	Internet X.509 Public Key Infrastructure Permanent Identifier
RFC 4055	Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
RFC 4059	Internet X.509 Public Key Infrastructure Warranty Certificate Extension
RFC 4158	Internet X.509 Public Key Infrastructure: Certification Path Building
RFC 4210	Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)
RFC 4211	Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)
RFC 4325	Internet X.509 Public Key Infrastructure Authority Information Access Certificate Revocation List (CRL) Extension
RFC 4334	Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN)
RFC 4386	Internet X.509 Public Key Infrastructure Repository Locator Service
RFC 4387	Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTP
RFC 4476	Attribute Certificate (AC) Policies Extension
RFC 4491	Using the GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms with the Internet X.509 Public Key Infrastructure Certificate and CRL Profile
RFC 4630	Update to DirectoryString Processing in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
RFC 4683	Internet X.509 Public Key Infrastructure Subject Identification Method (SIM)
RFC 4985	Internet X.509 Public Key Infrastructure Subject Alternative Name for Expression of Service Name
RFC 5019	The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments
RFC 5055	Server-Based Certificate Validation Protocol (SCVP)
RFC 5272	Certificate Management over CMS (CMC)
RFC 5273	Certificate Management over CMS (CMC): Transport Protocols
RFC 5274	Certificate Management Messages over CMS (CMC): Compliance Requirements
RFC 5280	Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
RFC 5480	Elliptic Curve Cryptography Subject Public Key Information
RFC 5636	Traceable Anonymous Certificate
RFC 5697	Other Certificates Extension
RFC 5755	An Internet Attribute Certificate Profile for Authorization
RFC 5756	Updates for RSAES-OAEP and RSASSA-PSS Algorithm Parameters
RFC 5758	Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA
RFC 5816	ESSCertIDv2 Update for RFC 3161
RFC 5877	The application/pkix-attr-cert Media Type for Attribute Certificates
RFC 5912	New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)
RFC 5913	Clearance Attribute and Authority Clearance Constraints Certificate Extension
RFC 5914	Trust Anchor Format
RFC 5934	Trust Anchor Management Protocol (TAMP)
RFC 6024	Trust Anchor Management Requirements
RFC 6025	ASN.1 Translation
RFC 6170	Internet X.509 Public Key Infrastructure -- Certificate Image

Effective information security doesn't have to be expensive

I just came an interesting article ("Case study: security on a shoestring budget") on the web site of CSO magazine. This article tells how Michael Dent, the CISO of Fairfax County Government in Virginia, managed to start an enterprise-wide IT security program without spending the millions of dollars such programs typically cost: he asked for $1.3 million, but managed to get an effective program going for only $250K. If you're one of the many people in IT security who are trying to do more with less, this case study might be of interest to you.

IARPA's Reynard project

It looks like IARPA's Reynard project is well under way at this point. This project is looking for ways to correlate things in virtual worlds, like World of Warcraft, with things in the real world. Here's how IARPA described what they're looking for:

Starting from the premise that Real World (RW) characteristics are reflected in VW behavior, the IARPA Reynard program seeks to identify behavioral indicators in VWs and MMOGs that are related to the RW characteristics of the users. Performers in the Reynard program will be expected to produce one or more VW behavioral indicators that serve to identify RW attributes of individuals or groups. Attributes of interest include the following: gender, approximate age, economic status, educational level, occupation, ideology or "world view", degree of influence, "digital native" vs "digital immigrant," approximate physical geographic location, native language, and culture. Other RW characteristics might also be empirically deduced through behavioral indicators. VW behavioral indicators may be examined in the areas of Avatars and Representation, Communication, Things That Avatars Do, Group Formation and Dynamics, Money and Economics, and Cultural Differences.

Because it's IARPA, the US government agency that funds research that the intelligence community is interested in, is sponsoring this research, they're probably trying to do things like find which people in a WoW game are really terrorists or similar things. That's what the ODNI's 2008 Data Mining Report (PDF) seems to suggest that they're interested in. But because the intelligence community is sponsoring this research, we'll probably never find out what they learned. That's too bad. This might actually be some interesting results from this project.

Encrypted QR codes for Android

I just came across an interesting application that's available for Android devices. This particular app let's you create and read encrypted QR (quick response) codes.

QR codes are those images that you see that look something like this:

These were created by Toyota back in 1994 to help track vehicles while they were begin manufactured, but now they're widely used in cell phones and other portable devices. Just take a picture of the QR code and many portable devices can easily translate that picture into a URL, phone number, or whatever was encoded in it. If you're really interested in how these work, you can find out in ISO/IEC 18004:2006 ("Information technology -- Automatic identification and data capture techniques -- QR Code 2005 bar code symbology specification").

The good thing about QR codes is that they're a standard, so anyone with a standards-compliant device can read one. But that also means that there's no privacy for information in QR codes because anyone with a standard-compliant device can read one. One workaround for this is to encrypt the data in a QR code, and that's just what QR Droid lets you do. It uses password-based encryption, so a typical use might be to encrypt those potentially-compromising pictures that you post on Facebook and to only share the password with your friends, thereby keeping any nosy HR people from blackballing you from future jobs because of what you did on your vacation to Cozumel.

Password-based encryption isn't very secure, of course, but it might be secure enough to protect the privacy of what you post on Facebook. If that's what you need, then QR Droid might be just what you're looking for.

Another breach of 1M+ records

There's been yet another data breach that exposed over 1 million records. This time it was at Nemours, an organization based in Delaware, Florida, New Jersey and Pennsylvania that provides health care for children. From the official announcement of the breach:

Three unencrypted computer backup tapes containing patient billing and employee payroll data have been reported missing from a Nemours facility in Wilmington, Delaware. The tapes were stored in a locked cabinet following a computer systems conversion completed in 2004. The tapes and locked cabinet were reported missing on September 8, 2011 and are believed to have been removed on or about August 10, 2011 during a facility remodeling project.

and

The information on the tapes dates principally between 1994 and 2004 and relates to approximately 1.6 million patients and their guarantors, vendors, and employees at Nemours facilities in Delaware, Pennsylvania, New Jersey and Florida.  The missing backup tapes contained information such as name, address, date of birth, Social Security number, insurance information, medical treatment information, and direct deposit bank account information.

Financial Website Passwords

Back in June, I wrote about my experience with a financial website and their rules that made it tough to use strong passwords. There were three parts, here are the links to one, two, and three. The people I talked to assured me that they were updating their security and better passwords would be allowed.

Well, they rolled out their new security measures. Sure enough, stronger passwords are allowed. They allow special characters and passwords can be as many as 20 characters (the old limit was 10).

This is much better. I wonder why there is still a character limit. Why not allow someone to go hog wild and use the password, "I remember the vacation I took to the Great Smoky Mountains. It was great"? My guess is that they are afraid people will forget longer passwords, or their website building software has a box in which users enter the password and the software requires a limit, or both.

There are other financial websites I use that disallow special characters. I need to call them up and request changes. I certainly hope anyone reading this blog will also check the financial websites they use, see if there are any that make it hard to use strong passwords, and call them up demanding change.

A Simpler Approach to Encrypting z/OS Data

To some, mainframes are seen as dinosaurs, technology that is obsolete or should be. However, this veteran platform has shown its resilience in enterprise computing for a reason. The benefits it offers to the corporate infrastructure - extreme scalability, high throughout, high availability - are matchless.

However, as IT executives responsible for running mainframes or other platforms with z/OS can attest - there are issues regarding complexity. For example, traditional encryption solutions can require hundreds of lines of code to acquire and store keys and perform cryptographic operations. And that isn't even the biggest problem; it's the knowledge required of all the moving parts of an application to ensure effective operation. And of course, with all that code and other complexities, there's more room for error. 

That's why developing an encryption solution based on Format-Preserving Encryption to address the mainframe environment was an interesting challenge - and it's been met. 

In response to customer requests, Voltage has now developed command line tools and a simple API that dramatically reduces the number of lines of code needed - from hundreds to just three. Now, companies of all sizes benefit from using Format-Preserving Encryption on the mainframe, including the ability to "encrypt here, decrypt there." This helps avoid the ASCII/EBCDIC issues that plague most cross-platform encryption solutions.

But that's not all. Engineers at IBM Hursley - the software development lab in Winchester, U.K., home to many of these technologies - point out that 80% of z/OS customers use CICS, the transaction server that's critical for mainframe operation. Unfortunately, many vendors still don't support CICS. Even IBM, which provides advanced encryption interfaces built into z/OS, has no developer abstraction to make it easy to encrypt within CICS environments. Traditional solutions for encrypting data rely on POSIX facilities, which are incompatible with CICS. 

Now, in a major step forward for cryptographic operations encompassing CICS and other z/OS environments, Voltage is introducing z/Protect, part of the Voltage SecureData product family. z/Protect provides even higher application data-level abstraction, requiring just one line of code to accomplish what used to take hundreds. More to the point, no one likes to mess with mainframe applications, and the z/Protect approach means even fewer modifications. 

To learn more about this innovative approach, which perfectly complements IBM's advanced cryptography on z/OS, here's a presentation introducing Voltage SecureData z/Protect.

PKI: Lemon Markets and Lemonade

Just in case you missed Peter Gutmann's talk "PKI: Lemon Markets and Lemonade" at the 2011 RSA Conference, the slides from his talk are now available (PDF) on his web site.

This talk had some interesting things to say about some of the problems that PKI faced in its early years and how the that vendors dealt with these problems led to disaster. It's easy to reconstruct the talk from just the slides, and there's lots of interesting material in them.

Statistical Analysis of Texas Hold'em

I just came across an interesting paper ("Statistical Analysis of Texas Hold'em" (PDF)) by application security consultants Cigital that tries to determine whether poker is a mainly game of skill or chance. Their conclusion is that it's mainly a game of skill. Here's how the executive summary of this paper describes what they found:

The effect of luck (i.e., the dealing of the cards) in Texas Hold’Em is a subject of much debate in the legal community. This study seeks to establish clear numbers derived from a significant sample of actual play. This study does not quantify the effect that luck has on Texas Hold’Em, but it provides compelling statistics about the way that the outcomes of games are largely determined by players’ decisions rather than chance.

Cigital examined 103 million hands of Texas Hold’Em poker played at PokerStars. In the majority of cases, 75.7% of the time, the game’s outcome is determined with no player seeing more than his/her own cards and some or all of the community cards. In these games all players fold to a single remaining player who wins the pot. In the 24.3% of cases that see a showdown (where cards are revealed to determine a winner), only 50.3% of showdowns are won by the player who could make the best 5-card hand. The other roughly half of the showdowns are won by someone with an inferior 5-card hand because the player with the best 5-card hand folded prior to showdown.

Much like poker, information security also deals with making decisions in the face of uncertainty, so a reasonable question to ask is: Is luck or skill more important in information security? Is it possible to make 75.7% of hackers not even try to attack your systems because they think that it's a waste of time because your security would be too tough for them to crack? And if that's possible, exactly how would you do it?

Government security incidents up dramatically

According to a recent report (PDF) from the US Government Accountability Office, the number of security incidents reported by government agencies has increased dramatically over the past few years. Here's a graph from this report that shows the recent trend.

 
 

Some of this trend can probably be explained as being caused by better reporting of incidents, but I doubt that all of it can. It certainly looks to me like the government needs to learn a lesson or two from the private sector when it comes to information security.