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.

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.

Disappearing domain names

According to the information at dailchanges.com, the number of domain names actually decreased recently. The most recent data shows that although there were over 77,000 new domain names registered on January 23, 2012, there were also over 85,000 domain names deleted. That's something that I hadn't seen before. And I wouldn't be too surprised if this actually changes from day to day and isn't part of a bigger trend.

Weird risk stories from 2011

There's an interesting article at the allbusiness.com web site that talks about some unusual risks that appeared in 2011. Here's one of the incidents that this article describes:

Newspaper Burned by Exploding Donuts

Apparently crazy court decisions are not solely an American invention. A Chilean newspaper, La Tercera, was recently ordered to pay $163,000 US to 13 people who suffered burns after the churros they were cooking exploded. The court agreed that the temperature listed in the paper’s recipe was too hot, which caused the dough to explode.

The plaintiffs won’t be rolling in dough, but this is a very unique legal theory. I wonder if U.S. newspapers will discontinue printing recipes to mitigate their risk.

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.

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.

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

Are we in a post-PC world?

There's an interesting debate going on on The Economist's web site. The actual resolution being debated is, "The house believes that we are now in a post-PC world." Most people don't sound convinced: the No votes currently outnumber the Yes votes by a considerable margin. In this particular case, I definitely agree with the majority.

I've used BlackBerrys, Kindles, iPads and other mobile computing platforms from time to time, but I always return to a desktop PC or laptop for serious work. The mobile platforms are great for entertainment and finding random bits of information like how to find a good barbeque restaurant near your hotel, but for serious work they've never been good enough and I don't forsee that changing any time soon. And from the voting on The Economist's web site, it looks like most people have had similar experiences.

I don't doubt that the PC will continue to evolve, but I also believe that whatever it evolves into will still look a lot like the PCs that we have today.

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.

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. 

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.

The US monetary base

I just came across some more data that give some interesting perspective on the recent financial crisis. This is the monetary base data that the US Federal Reserve collects.

Here's how the US monetary base (roughly the amount of money in the economy) changed over the past 27 years or so. Something definitely changed recently, didn't it? And changed a lot.

 

Do neutrinos really go faster than the speed of light?

I've been asked several times today what I think about the recent research at CERN that seems to indicate that neutrinos travel faster than the speed of light. Being a big fan of the Bayesian approach to understanding things, I have to doubt that this has really been shown. Here's my totally non-rigorous explanation of why I believe this.

If neutrinos really do travel faster than the speed of light, that's inconsistent with lots of experiments that seem to indicate that Einstein's theory of relativity is correct. The recent experiment that measured frame dragging is a good example of this. This doesn't disprove that neutrinos really travel faster than the speed of light, of course, but it should lead us to believe that the probability of neutrinos traveling faster than the speed of light, given all of the evidence that seems to support relativity, is fairly low.

On the other hand, there's also a chance that there's an error in CERN's very complex experiment. This probability is probably fairly low, but it's still non-zero. And I'd guess that the probability of an error creeping in to this particular experiment is greater than the probabilities of other explanations for CERN's recent finding.  Like the probability that relativity may actually be wrong.

So although I'd love to see CERN's result be repeatable and end up being true, I doubt that we'll end up seeing that. An error of some sort in their experiment seems a more likely explanation of what they found.  

If you're really curious, you can even download the paper that describes CERN's results. You can get it here.

Money and the dot-com bubble 2.0

After yesterday's post an alert reader asked why I haven't mentioned Pink Floyd's "Money" yet. After all, the recent market in technology companies is making someone lots of money. We might even be seeing the beginning of the dot-com bubble 2.0, but this time on a global scale.

I can't think of a good reason why I haven't mentioned "Money" before, so here it is. 

How credit card debt has grown over time

The G19 data from the US Federal Reserve shows how the amount of revolving debt has grown over the past few decades. It's interesting that the only time that there's been a noticeable decrease is during the most recent recession. From this data, it's hard to even see where the other recessions happened.

 

Government IT gets a glimpse of the real world

I just came across an article ("Standardizing federal security regulations easier said than done") that talked about how hard it is for government IT managers to meet all of the security requirements that the many data security and privacy laws have recently created. This article started by saying this:

Federal information security managers could make life easier for their counterparts at state agencies by standardizing technical requirements for securing federal data, security specialists for the state of Oregon say. And federal IT managers are grappling with overlapping security concerns from multiple departments and laws.

When I read this article I felt an overwhelming lack of sympathy for the government IT managers who have to deal with this problem. Multiple overlapping security requirements are a fact of life in corporate IT. Conflicting security requirements are also. So the problems described in this article are the same ones that IT managers in the private sector aleady have to deal with. Government IT managers, get used to it. This problem isn't going away any time soon.

It looks like things are getting better for banks

Here's how the charge-off rate for US banks changed over the past few years. It looks like the worst is now behind them.

Is the UK government really preoccupied with offensive IT security?

 

I just came across the article "Expert says UK government is too preoccupied with launching cyber attacks," which quotes Cambridge professor Ross Anderson as saying

"The spooks - GCHQ- are getting 90 per cent of this new £650m for cyber security. The rest, about £65m, is going to the police."

The article then goes on to interpret this as saying that over 90 percent of the UK government's funding of IT security is for offensive instead of defensive operations.

But CESG, the part of the UK government that's responsible for defensive IT security happens to be part of GCHQ, so that interpretation of the funding seems more than a little misleading. If CESG gets funding, it comes in through GCHQ, even if absolutely none of the money is used for offensive operations.

So this spin on the UK government's budget is a bit like saying that the US government spends over $665 billion on building dams and bridges each year. The US Department of Defense's budget may indeed be over $665 billion, but the fact that the DoD will spend $665 billion certainly doesn't mean that all of it will be spent on dams and bridges, even if the US Corps of Engineers (the guys who actually do build dams and bridges from time to time) happen to be part of the DoD.

Does it make sense to have the people who do defensive IT security part of the same organization that does offensive IT security?

This particular article seems to think that this is a bad idea, but I don't think that this is true. People who defend against attacks without knowing exactly what sort of attacks are realistic and feasible probably aren't as good at their jobs as people who don't know those sort of things. And the best place to learn that sort of thing is probably in an organization that's responsible for offensive IT security operations.

I'm filing this article under "journalist trying way too hard to make things sound controvertial that really aren't." Just like I would if I saw the article "Expert says US government is too preoccupied with building bridges and dams."

More on the DigiNotar compromise

 

The Tor project web site has an interesting update on the recent compromise of the DigiNotar CA that resulted in hundreds of bogus certificates being issued. Part of that update is a spreadsheet (CSV) of the 531 known bad certs, including which CA issued them, their serial number, the domain that the cert was for, etc.

In addition to bogus SSL certs for companies like Google, Microsoft, Twitter and FaceBook, there were also bogus certs issued for things like "VeriSign Root CA," "Comodo Root," and "Thawte Root CA." A total of 187 of the 531 bad certs actually have "Root CA" in their common name.

And there were even bad certs issued for *.*.com and *.*.org!

There's the interim report that was written by consultants hired by DigiNotar that you can get here (PDF). It looks like the DigiNotar systems weren't as secure as they could have been. As this report says,

The most critical servers contain malicious software that can normally be detected by anti-virus software. The separation of critical components was not functioning or was not in place. We have strong indications that the CA-servers, although physically very securely placed in a tempest proof environment, were accessible over the network from the management LAN.

D'oh!

The investigation into this incident isn't fnished yet, so there may be more interesting news about it in the future. Maybe we'll find our exactly how this happened.

That's a lot of bad certificates

There were apparently more bogus certificates issued by the Dutch CA DigiNotar than just the one that may have been used to carry out MITM attacks against people in Iran.

This view of the recent changes to Google's Chromium codebase shows that there were only 10 revoked certs managed by Chromium until recently but there are now 257 of them.

That's a lot of bad certs. 

SSL MITM attack on Gmail?

According to this thread on the Gmail (UK) help forum, someone in Iran may have obtained a fake SSL certificate for *.google. com from the Dutch CA DigiNotar. You can see supposedly-fake certifictate here.

The discussion thread says that the bogus certificate has been revoked, and that you can check the CRL here. Or you just look at this view of the CRL:

 

Note that although the certificate was issued on July 10, it wasn't revoked until August 29! So someone could have been masquerading as Google for quite a while. And they still could be, because revocation isn't always checked for certificates.

AES cracked - or is it?

There's new research that's being described as saying that the AES encryption algorithm has been "cracked."

I'm probably not alone in dreading these sorts of stories. Many people who work for encryption vendors probably feel the same way about them because they always end up being a distraction for a week or so as we explain to people why their sensitive data is still safe, even if hackers have access to the latest and greatest attack.

The headlines often aren't quite true, but that that doesn't stop lots of people from worring about exactly what's what. And that's understandable, because most people really don't care about the details of encryption. And they shouldn't. As Calvin Coolidge might have said if he were around today, "The business of America is business, not worrying about the arcane details of encryption."

So what's the bottom line this time and how does it affect the security of any sensitive data that you're encrypting with AES?

Here's the way that Andrey Bogdanov, one the researchers who found this weakness in AES, described the implications of this new attack:

The practical consequence is that the effective key length if AES is about 2 bits shorter than expected - it is more like AES-126, AES-190 and AES-254 instead of AES-128, AES-192 and AES-256.

So we're looking at reducing the security provided by an AES key by about 2 bits, or about a factor of 4. But because even the weakest AES keys, the 128-bit keys, require hundreds of billions of years on implausibly-powerful supercomputers to crack, knocking off 2 bits is really no big deal. That might reduce the time needed to crack a key from 100 billion years to only 25 billion years, for example, which is still isn't the sort of attack that's practical for a hacker to do. And it's one that probably never will be.

So the work by Andrey Bogdanov, Dmitry Khovratovich and Christian Rechberger (BKR) that's being described as leading to AES being cracked really isn't really worth losing sleep over. Even if hackers only have to do one-quarter of the work that they would have otherwise needed to do to crack an AES key, this still leaves them with an impossible amount of work left. So much work that they'll never try to actually carry out this attack.

So the bottom line is that if the BKR attack is the best that a hacker can do, your data's still extremely safe.

Trying older browsers on the 20th anniversary of the World-Wide Web

Because the 20th anniversary of the World-Wide Web was just a few days ago, I thought that I should commemorate this event by trying some of the older web browsers to see how well they would work today.

I first tried the Voltage web site. Here's what it looks like in the pre-dot-com-era Mosaic 1.0. It's clearly not optimized for that particular browser, is it?

It actually turned out to be fairly hard to find a web site that actually doesn't look really bad in Mosaic 1.0. The web sites that once had links to text-only sites haven't been updated in quite a while and almost all of the sites that they once linked to are gone.

But I finally found one that worked - the web site of the Kennedy Center. Here's what it looks like in Mosaic 1.0.

Now that's a user experience that I hadn't had in quite a while. Back in the pre-dot-com era things weren't as fancy as today's Internet, but they were definitely a lot less annoying. No advertising. And no social networking sites.

Massachusetts has problems with error rates for biometrics

According to an article on the IEEE Spectrum Risk Factor blog, people in the state of Massachusetts are being inconvenienced a bit by the error rates of a biometric system that the state uses to identify people suspected of having a fake identity. Here's how Spectrum summarized what happened in one particular case:

John H. Gass is still not a happy person. On the 5th of April, he received a letter dated the 22nd of March from the Massachusetts Registry of Motor Vehicles telling him that his driving license had been revoked, and that he must immediately stop driving.

Mr. Gass, who had not received a traffic violation for years, was identified by the RMV as a person suspected of having a fake identity by an automated anti-terrorism facial recognition system, an article in the Boston Globe reported. At least 34 other states use the same or similar software, the Globe says, much of it paid for in part by grants from the US Department of Homeland Security.

It turns out that the face recognition software flagged Mr. Gass's picture as looking like another Massachusetts driver, hence the letter from the Massachusetts RMV. The Globe says that it took Mr. Gass ten days of wrestling with the RMV bureaucracy to prove to them that he was indeed who he said he was before he was able to get his license back.

According to the Globe story, based on results of the recognition system, last year the "State Police obtained 100 arrest warrants for fraudulent identity, and 1,860 licenses were revoked as a result of the software."

Neither the Spectrum article nor the Globe article that it refers to say how many off those arrest warrents and license revocations turned out to be due to the non-zero false match rate for the facial recognition system that the state government uses.

Based on the error rates of biometric systems that I'm familliar with, I wouldn't be surprised if Mr. Gass isn't alone in having a problem with being inaccurately identified by one of these systems. The Globe article leads you to believe, however, that the state isn't very sympathetic in these situations at all. It quotes a state spokesman saying that, "protecting the public far outweighs any inconvenience Gass or anyone else might experience."

More questionable data

There was an article in a recent issue of IEEE Spectrum that made me think about how well the government would do if they tried to collect information about information security incidents. This article was “One Million Plug-in Cars by 2015?” and it discussed how realistic the US government’s goal is of having 1 million electric cars in use by 2015.

This article describes how study of this by industry experts reported (PDF) that the goal of 1 million was probably unattainable. The experts based this conclusion on things like announced production volumes and the experts’ own projections of consumer demand.

Shortly after the industry experts released their report, the US Department of Energy released their own study (PDF). Theirs concluded that 1.22 million electric cars was attainable by 2015.

But what did the DOE base their projection on?

According to IEEE Spectrum, it was based on media reports of auto makers’ plans.

So we’re left wondering which is more accurate: the auto makers’ plans or media reports of their plans.

There’s might be a political agenda behind the DOE report. There might also be one behind the industry report. But when I see politics apparently influencing things to this degree, I’m led to believe that the government probably wouldn’t do a very good job of collecting and reporting statistics on information security incidents. If the government’s goal was to reduce incidents by 25 percent by a certain time, for example, there’s a good chance that there’ll be a report that shows that they met that goal. (Unless the GAO did the reporting. They seem about as unbiased as you can get. But this seems outside the scope of what they're allowed to do.)

So I wouldn't be surprised if political pressure would lead the government produce more questionable studies if they were in charge of reporting on information security incidents.  The information security industry already has lots of studies of questionable accuracy. To avoid getting even more of them, I'd say that the government shouldn't try to consolidate and report on security incidents.

Comments on NIST's proposal to approve FFX

What's on the NIST web site seems to say everything that needs to be said:

On June 9, 2011, NIST announced a period of public comment on a proposal to approve two schemes of the FFX framework for format preserving encryption: FFX[radix] and VAES3. The public comments that NIST received in response to this request are collected here.

Oddly enough, the comments are all very positive. In situations like these you usually get negative comments by vendors who don't have an interest in the technology which give either weak or obscure technical reasons why a particular proposal is bad.

Spammers create fake shortened URLs

I was reading a recent edition (PDF) of Symantec's MessageLabs Intelligence report when I came across this interesting bit of information:

This month, MessageLabs Intelligence uncovered evidence of spammers establishing their own fake URL-shortening services for the first time. Shortened links created on these fake URL-shortening sites are not included directly in spam messages; instead, the spam emails contain shortened URLs created on legitimate URL-shortening sites. Rather than leading directly to the spammer’s final Web site, these links actually point to a shortened URL on the spammer’s fake URL-shortening Web site, which in turn redirects to the spammer’s final Web site.

So services like TinyURL are apparently so useful that spammers have created their own versions. That's probably the best endorsement that TinyURL could get. As Charles Caleb Colton once said, "Imitation is the sincerest of flattery."

The future of information security at ASF 2011

At the recent Aspen Security Forum there was an interesting discussion of the future of information security. This particular part of the ASF included remarks by Michael V. Hayden, the former director of both the CIA and the NSA, about how government information security operations could get privatized in the future. He imagines the possibility of a sort of Internet version of Blackwater, the for-profit paramilitary organization that was involved in some ugly situations in Iraq back in 2007.

 

Because lots of governments are likely to regard hacks of their computer systems by other governments (or their contractors) as an act of war if they're able to prove a connection between a serious hack and a particular government, this certainly seems like a situation that could easily get out of hand.

Is there a shortage of information security professionals?

 
 
I just read "A Human Capital Crisis in Information Security," a report written by the Center for Strategic & International Studies. It says that it's a "Report of the CSIS Commission on Cybersecurity for the 44th Presidency."

This report paints a fairly dire picture of the lack of skilled information security professionals and what the implications of this shortage might be. Here's how this report describes this problem:

A critical element of a robust cybersecurity strategy is having the right people at every level to identify, build and staff the defenses and responses. And that is, by many accounts, the area where we are the weakest. According to interviews conducted with Jim Gosler, NSA Visiting Scientist and founding director of the CIA’s Clandestine Information Technology Office, there are only about 1,000 security specialists in the United States who have the specialized skills to operate effectively in cyberspace; however, the United States needs about 10,000 to 30,000 such individuals.

The problem is both of quantity and quality, especially when it comes to highly skilled “red teaming” professionals. We not only have a shortage of the highly technically skilled people required to operate and support systems already deployed, but also an even more desperate shortage of people who can design secure systems, write safe computer code, and create the ever more sophisticated tools needed to prevent, detect, mitigate and reconstitute from damage due to system failures and malicious acts.

The cybersecurity workforce to which we speak in this report consists of those who self-identify as cybersecurity specialists as well as those who build and operate our systems and networks. That workforce includes not only workers on government payrolls, but also those contractors who operate as part of the extended government workforce. It also includes those who build and maintain the critical infrastructure on which the public and private sectors have come to rely.

But I have to wonder how accurate this really is.

Are there really only 1,000 people for which there are between 10,000 and 30,000 jobs? The law of supply and demand tells us that market forces would correct this problem fairly quickly: if there's really a shortage of that many people then employers would increase what they pay information security professionals until they get enough of them. And because I don't see a dramatic upward trend in salaries for information security jobs, I'm left believing that there's probably no real shortage of people for these jobs.  

How much does PKI really cost?

PKI is legendary for being very expensive and hard to use. Usability is hard to quantify, but the claim that it's expensive is fairly easy to justify. If you look at the US Government Accountability Office's report "Status of Federal Public Key Infrastructure Activities at Major Federal Departments and Agencies" (PDF), you'll see some truly impressive estimates for the cost per certificate that some government agencies have experienced. The USDA had spent $46,853.56 per certificate when the original report was written, for example.

The GAO actually seems to do a good job of being an impartial auditor for the US government, so their estimates for the cost of the government's use of PKI so far (over $1 billion) is probably the best that they could do, but its accuracy depends on the data that the federal departments and agencies provided to the GAO. I started to wonder about exactly how accurate that data was when I read an article in the Wall Street Journal about the costs of the space shuttle program.

According to this article, the government doesn't actually know how much the space shuttle program cost. Estimates range from roughly $115 billion to $230 billion. For 135 launches, that comes to somewhere between $850 million and $1.7 billion per launch. That's a lot for a program that was supposed to cost more like $7 million per launch, even accounting for inflation. 

So if government agencies can't actually get an accurate estimate of how much they spent on the space shuttle, how accurate do you suppose those PKI cost estimates really are?

How did I miss Data Privacy Day 2011?

I just learned that I somehow missed Data Privacy Day 2011. It was actually January 28. But I don't feel too bad about missing it - the US Senate's resolution supporting it wasn't actually introduced until January 31. (It passed the same day by Unanimous Consent.)

Even worse, it turns out that this is the third annual Data Privacy Day, so I also managed to miss the events in 2010 and 2009.

I'm guessing that this event wasn't actually very helpful. It's probably important to increase people's awareness of the data privacy risks that they face, but I'm not sure that Data Privacy Day is a very effective way to do this.

Encrypted CPU stolen?

You keep using that word. I do not think it means what you think it means.

Inigo Montoya, The Princess Bride

A hospital in Spartanburg, South Carolina, has had another computer stolen. Here's how the local news reported this story:

Police are investigating the theft of a computer unit from Spartanburg Regional Medical Center.

According to an incident report, a nurse reported the CPU stolen to hospital security on Saturday.

The unit, according to the report, was taken from the emergency center major care room 50.

Hospital staff told police that the CPU was last online on Friday morning.

Police say they have no leads.

Hospital representative, Chad Lawson, told News4's Mike McCormick that the CPU was encrypted and contained no patient information. The representative said the unit was used primarily to access various programs that are password protected.

I'm fairly sure that the term "CPU" isn't being used quite correctly here.

The likely outcome of Cristina Wong v. Dropbox

Not too long ago, start-up Dropbox had a security bug that let people access the data of other users. The bug went unpatched for about four hours. According to Dropbox, during that time the data of fewer than 100 users was accessed and only a single person exploited the bug. But that didn't stop Cristine Wong from filing a class-action suit (PDF) against Dropbox. In this suit Wong claims that

As a result of the Defendant's breach of its warranties, Plaintiff and the Class have been damaged in the amount of the purchase price of Defendant's services they purchased.

That seems like an overly-broad definition of damages to me, and one that might not stand up to much scrutiny. If this suit makes it to trial, I wouldn't be surprised if any damages are limited to the 100 or fewer people whose data was actually accessed before Dropbox's bug was patched. And that might actually disqualify this from being a class-action suit.

When you're allowed to expose SSNs

I've been asked lots of questions in the past day or two about Ostergren v. Cuccinelli (PDF), a case in Virginia where a judge ruled that it was OK for a woman to post official documents on her web site that contained Social Security numbers of Virginia residents. The ruling in this particular case is an interesting balancing act between privacy and freedom of speech. I'm not sure that I agree with the judge's conclusion in this particular case, but here's my understanding of what happened and why.

Betty Ostergren, a privacy activist, noticed that some of the official documents for the state of Virginia that were publicly available contained SSNs. The state government then tried to clean up the documents, but there were still some SSNs that weren't cleaned up.

To get the state to do a better job of this, Ostergren decided to post examples of the still-unsanitized documents on the Internet. The state objected, claiming that this violated the existing privacy laws that protect SSNs. A judge finally ruled that Ostergren had the right to post the documents, even though they clearly contained SSNs that would otherwise be illegal to expose.

The judge's reason for doing this seems to be based on the idea that the right of freedom of speech was "designed to allow individuals to criticize their government without fear." And because Ostergren's motivation for exposing SSNs was to criticize the government's inaction on protecting sensitive information, it's protected by the First Amendment.

I don't like the way that this particular case turned out. It seems to set the precedent that it's OK to expose my SSN as long as you're doing it in a way that's protesting the government's actions. And it seems to me that there are just too many ways in which that could be abused.

What Experi-Metal v. Comerica tells us

There was another interesting ruling last week concerning who's responsible if fraudulent transactions are made using a business' Internet banking account. This time the ruling was in Experi-Metal v. Comerica Bank. The situation was very similar to Patco Construction v. People's United Bank that I recently commented on.

In Patco, malware was used to steal authentication credentials. In Experi-Metal, a phishing attack was used to steal authentication credentials. The courts ruled that the bank wasn't responsible for the fraudulent transactions in the case of Patco, but they were in the case of Experi-Metal.

The big difference was that in the case of Experi-Metal, the judge ruled that the behavior of Comerica didn't appear to be in "good faith:"

[After the phishing attack], the criminal initiated 97 wire transfer payment orders from Experi-Metal’s Sweep Account, totaling more than $1.9 million. There are a number of considerations relevant to whether Comerica acted in good faith with respect to this incident: the volume and frequency of the payment orders and the book transfers that enabled the criminal to fund those orders; the $5 million overdraft created by those book transfers in what is regularly a zero balance account; Experi-Metal’s limited prior wire activity; the destinations and beneficiaries of the funds; and Comerica’s knowledge of prior and the current phishing attempts. This trier of fact is inclined to find that a bank dealing fairly with its customer, under these circumstances, would have detected and/or stopped the fraudulent wire activity earlier. Comerica fails to present evidence from which this Court could find otherwise.

So because the pattern of behavior for the fraudulent wire transfers was so different from the pattern of Experi-Metal's usual behavior, the bank should have noticed it if it was actually acting in good faith.

How does that differ from Patco?

Apparently in the case of Patco, the fraud wasn't quite as obvious, while in the case of Experi-Metal, the court ruled that it should have been obvious to the bank. And because there's still no clear definition of what level of fraudulent activity should be obvious to banks, we'll probably see more litigation in this area in the future. Maybe that's what Experi-Metal v. Comerica really tells us.

Security theater for DNSSEC

The recent DNSSEC workshop in Singapore got some interesting coverage in the San Jose Mercury News:

The Singapore event included an elaborate technical ceremony to create and then securely store numerical keys that will be kept in three hardened data centers there, in San Jose, Zurich and Singapore. The keys and data centers are working parts of a technology known as Secure DNS, or DNSSEC. DNS refers to the Domain Name System, which is a directory that connects names to numerical Internet addresses. Preliminary work on the security system had been going on for more than a year, but this was the first time the system went into operation, even though it is not quite complete.

The three centers are fortresses made up of five layers of physical, electronic and cryptographic security, making it virtually impossible to tamper with the system. Four layers are active now. The fifth, a physical barrier, is being built inside the data center.

As the recent compromises of RAs at Comodo showed us, the weak link in PKI is almost never the CA itself, and a clever hacker will always go after one of the weaker links instead of trying to get the CA's private keys. And it certainly looks like the fortresses that are being built in San Jose, Zurich and Singapore are really designed to keep hackers away from those very keys.

So if a hacker wants to compromise DNSSEC, they almost certainly won't try to beat the security of one of the fortresses. They'll do something much easier like compromising an RA. That means that all of the expensive layers of security around the DNSSEC root keys are probably just for show. They may make people feel better about the security of DNSSEC, but they probably don't really add much actual security because they're designed to defeat attacks that never happen. And these attacks still wouldn't happen if the security measures around the keys weren't as tight.

Highway sign hacked in Ohio to warn of zombies

 

Not all hacks involve stealing millions of credit card numbers. An example of one that doesn't is the hack that reconfigured one of the highway signs near Cincinnati to read "ZOMBIES AHEAD" instead of "ROAD WORK AHEAD" this morning. State officials were not amused. At least not officially.

You can read the local coverage of this hack here.

Update: As an alert reader pointed out, this hack actually took place in Kentucky, not Ohio. I hope that I didn't cause any unnecessary panic in Ohio. "Oh no! They're on this side of the river too!"

Identify theft and State of Oregon v. Kevin Martin

The Court of Appeals of the State of Oregon just issued a ruling that relates to identify theft. If seems that when Kevin Martin was arrested for burglary he had an Oregon DMV identification card for someone else in his pocket. He was subsequently convicted of both burglary and identity theft, but the Court of Appeals reversed the conviction for identity theft.

As the Court noted, a person commits the crime of identity theft under ORS 165.800(1) when the person, "with the intent to deceive or to defraud, obtains, possesses, transfers, creates, utters or converts to the person's own use the personal identification of another person." And the Court ruled that just having someone else's identification card in your possession isn't enough to establish that you had planned to use it for identity theft. Here's how the Court described their reasoning:

The state's argument fails to withstand scrutiny under the above legal principles. Generally, proof of a defendant's mental state focuses on inferences drawn from evidence concerning the acts of the defendant as they relate to the "action" element of the offense. State v. Beason, 170 Or App 414, 425-26, 12 P3d 560 (2000), rev den, 331 Or 692 (2001). Here, the "action" element of the offense with which defendant is charged is his possession of the card at the time of his arrest. Defendant's mere possession of the card is not by itself probative of an intent to use the card to deceive or defraud. Moreover, defendant was under no legal obligation to explain further his possession of another person's identification card to the police, and his disclosure that he had found the card in a wallet that had been lost implies no criminal wrongdoing on his part. The state also points to the fact that the card was loose in his pocket rather than in a wallet and to the fact that he had refused to disclose the whereabouts of the wallet. In addition, the state relies on the fact that the picture of the person on the identification card is of a white male about the approximate age and height as defendant. However, those facts, whether considered individually or together with all the other circumstances in this case, do not rise to the level of an inference beyond a reasonable doubt that defendant intended to use the card to deceive or defraud another at the time that he possessed it. Rather, they require a factfinder to speculate as to what action, if any, that defendant might take with the card in the future. It follows that the trial court erred when it denied defendant's motion for a judgment of acquittal on the identity theft charge.

Some people are saying how this ruling is going to make it much more difficult to convict people for identity theft. There will probably need to be some additional investigation done to verify that a suspect actually used someone else's identification to commit identity theft, but that's probably a good thing. Convicting someone of what they might do in the future is something that really belongs in one of the failed communist states of the twentieth century, not in a modern democracy.

Distribute.IT - an example of why you need to back up your data

Don't forget that information security deals with ensuring the confidentiality, availability and integrity of your data. Of these three, availability is often overlooked, probably because systems that support it often come from a different part of budgets that systems that provide the confidentiality and integrity of data. But if you overlook ensuring availability, bad things can happen.

A good example of this is what recently happened to Australian web hosting company and domain registrar Distribute.IT, who actually ended up losing lots of their data in a recent attack on their systems. And because their data wasn't adequately backed up, this meant that their data was gone for good when this happened:

Our Data Recovery teams have been working around the clock in an attempt to recover data from the affected servers shared Servers. At this time, We regret to inform that the data, sites and emails that were hosted on Drought, Hurricane, Blizzard and Cyclone can be considered by all the experts to be unrecoverable. While every effort will be made to continue to gain access to the lost information from those hosting servers, it seems unlikely that any usable data will can be salvaged from these platforms.

Don't let this happen to you. Availability is just as important as confidentiality and integrity.

The DIB Cyber Pilot

The US Department of Defense just announced the Defense Industrial Base Cyber Pilot. This is a program

in which the Defense Department, in partnership with the Department of Homeland Security, shares classified threat information and the know-how to employ it with participating defense companies or their Internet service providers to help them in defending their computer networks from attack or exploitation.

So it looks like the DoD and DHS are going to try sharing classified threat data with the private sector. That might be a good idea, but I have serious doubts of the government's ability to actually do it in a useful way. Government agencies have a long history of not sharing information, even when it makes sense to, and I doubt that this initiative will change that.

NIST announces proposal to approve two FFX schemes

NIST just announced a proposal to approve two modes of format-preserving encryption for use in FIPS 140-2. Here's the announcement from NIST's web site:

Announcement of Proposal to Approve Two FFX schemes

June 9, 2011

NIST is pleased to announce a proposal to specify and approve two block cipher modes of operation for format preserving encryption (FPE). FPE is emerging as a useful cryptographic tool, whereby certain kinds of data, such as social security numbers or credit card numbers, may be selectively encrypted without changing their format. Consequently, FPE can be seamlessly retrofitted to existing applications to support the encryption of sensitive data.

Both of the modes that NIST proposes to approve are schemes that are compliant with the FFX framework that was submitted to NIST by Mihir Bellare of the University of California, San Diego, Philip Rogaway of the University of California, Davis, and Terence Spies of Voltage Security, Inc. The submission documentation for FFX is available at the modes development page, under the heading "Encryption Modes." The FFX framework is described in detail in the body of the specification [SP]. One FFX compliant scheme that NIST proposes to approve, called FF[radix] is specified in the addendum to the specification [SP2]. The second scheme that NIST proposes to approve, called VAES, is described in the additional documentation [AD] submitted by Joachim Vance of VeriFone Systems, Inc.

Also included in the documentation are Letters of Assurance from Voltage Security, Inc. and VeriFone Systems, Inc. [IP1 and IP2] in connection with intellectual property that those companies identified as possibly relevant to the implementation of FFX[radix] or VAES.

NIST proposes to recommend FFX[radix] as the preferred FPE scheme for interoperability. NIST will also consider approving other FFX schemes, in addition to VAES, on a case-by-case basis.

NIST requests comments on the proposal by July 8, 2011; comments may be submitted to EncryptionModes@nist.gov.

If NIST moves forward with the proposal, an additional period of public comment will be initiated on a draft special publication that specifies the modes.

FPE has proven to be very useful for encrypting data in complex legacy environments. In these situations, there's often at least one component of an installed system that can't easily handle encrypted data if its format if different than the plaintext. National governments are good examples of places where such complex legacy environments appear, so it's not too surprising that NIST is interested in approving FPE for government use.

What Dimitriy Simonoffs v. Expedia tells us about printed receipts

There's been some discussion recently about exactly what a recent court ruling means about merchants' ability to send credit card numbers over email. Like in most of these cases, lots of what's being said isn't supported by the facts. Here's what really happened and what it probably means.

Dimitriy Simonoffs received an email receipt from travel web site Expedia that contained the expiration date of the credit card that he used for a purchase. Believing that this violated the Fair and Accurate Credit Transactions Act of 2003 (FACTA) (PDF), he filed a suit against Expedia. This suit eventually made its way to the United States Court of Appeals for the Ninth Circuit, which issued an Opinion on Simonoffs v. Expedia on May 24, 2011. Simonoffs claimed that FACTA's provision that

no person that accepts credit cards or debit cards for the transaction of business shall print more than the last 5 digits of the card number or the expiration date upon any receipt provided to the cardholder at the point of the sale or transaction. 

applied to email receipts as well as physical receipts. The court disagreed, finding that the wording of FACTA clearly does not apply to electronic receipts:

In enacting FACTA, Congress did not use language that would have clearly extended FACTA’s protection to electronically mailed receipts. For example, Congress could have applied FACTA to "electronically printed or transmitted" receipts, to "electronically printable" receipts, or to "electronically displayed" receipts. See Simonoff v. Kaplan, Inc., No. 10 Civ. 2923, 2010 WL 4823597, at *7 (S.D.N.Y. Nov. 29. 2010). Congress, however, chose not to do so, even though it has referred to digital methods of communication and commerce in numerous other statutes. See Shlahtichman, 615 F.3d at 801-02 (canvassing various other federal statutes that use terms such as "Internet," "Internet websites," "electronic mail," and "online service," among others). We can’t fill in the blanks with words that Congress didn’t supply.

In other words, it looks like Congress probably wasn't very careful when they wrote FACTA, and this is reflected in the fact that the wording that they used omitted coverage of electronic receipts even though other laws have addressed them.

That seems fairly straightforward.

Does this mean that merchants can't print credit card numbers but are now free to send credit card numbers over email?

No. Not even close.

The PCI DSS clearly says that that's not allowed. So even if there's an oversight in the wording of FACTA that makes it legal, merchants still can't do this. So if anyone tells you that Simonoffs v. Expedia means that merchants are now free to send credit numbers over email, they probably either haven't thought about it very carefully or are hoping to get their 15 minutes of fame by misrepresenting the facts.

Multifactor authentication and Patco Construction v. People's United Bank

There was an interesting ruling (PDF) by the United States District Court District of Maine in Patco Construction v. People’s United Banka few days ago. It seems that back in 2009, someone at Patco Construction managed to install Zeus malware on the computer that Patco used to initiate electronic funds transfers. This let hackers capture the answers to the challenge/response questions that Patco used to authenticate to their on-line banking system. The hackers then used this information to complete about $345,000 in fraudulent transactions. Patco sued to recover the lost money, claiming that the bank’s security measures were not "commercially reasonable." The court disagreed, and Patco’s suit to recover the money lost in the fraudulent transactions was dismissed.

What I find interesting about this particular ruling is part of why the bank’s security measures were found to be commercially reasonable. FFIEC’s guidance "Authentication in an Internet Banking Environment" (PDF) recommends multifactor authentication for financial transactions, but exactly what that means isn’t as clear as you might expect it to be. In this particular case, the bank claimed that in addition to a username and password plus the answers to challenge/response questions, that

its security procedures also employed "something the user has": device identification information specific to the client’s personal computer and its use of the Bank’s application, and "something the user is": taking into account user behavior.

But when the hackers compromised the username and password plus the challenge/response answers, they didn’t compromise these other factors. They didn’t get the ability to spoof device authentication information and they didn’t get the ability to spoof the behavior of the legitimate user. But that’s apparently OK. As the bank pointed out, in their legal arguments, Patco

attempt[ed] to manufacture an additional "requirement" for multifactor authentication, unsupported in the FFIEC guidance or in case law, by arguing that the system must respond in a certain way to each of the factors, for example, by blocking a transaction if one of the factors fails.

So it looks like the bank claimed, and that the court agreed, that it’s OK for some of the factors in a multifactor authentication to fail yet for the overall authentication to succeed. I haven’t carefully considered all of the implications of that, but my first reaction is that this is probably just an oversight on the part of the people who wrote the FFIEC’s guidance, and it’s something that the next version should probably address.

It also looks like people writing other standards should also think about this and consider explicitly requiring success from more than one of the factors in multifactor authentication for an authentication attempt to succeed. Maybe that’s something that the ASC X9F4 working group should consider, for example.

The recent financial crisis and information security

I was recently talking to a former coworker about how the information security industry is doing. My former coworker claimed that the success or failure of the industry was correlated with the recent financial crisis because so many big consumers of information security technology are financial institutions.

I wasn't convinced that this was the case, so I looked at some of the data on the US financial system that's available from the US Federal Reserve. In particular, I looked at the H.8 data, Assets and Liabilities of Commercial Banks in the United States, and the H.3 Historical Table 5 data, Aggregate Reserves of Depository Institutions and the Monetary Base. When I plotted the amount of loans at commercial banks and the monetary base over the past few years, here's what I found. Both tell different stories. Together they tell a entirely different story, but that's probably getting to far off topic.

 

 

I don't think that there's a correlation between either of those sets of data and how the information security industry has done. Instead, I'm fairly sure that the demand for information security products has been driven by the need to comply with the data security and privacy laws and regulations that have proliferated in the past several years.

Was iPhone encryption cracked?

I've heard lots of discussions today about how clever researchers at Russian computer security company ElcomSoft managed to crack the AES-256 encryption used to protect data on iPhones.

But this wasn't really an attack on AES-256.

Instead, it's an attack on the weak 4-digit PINs that most users use to control access to their keys. If you try to buy the application that does this attack for you, you'll find that this is actually part of the ElcomSoft Phone Password Breaker application.

Controlling access to keys is part of key management, not encryption. That means that this particular attack is really an attack on weak key management, not on encryption. Cracking an AES-256 key is still so hard that it's essentially impossible.

So the lesson learned from this particular attack should be that if you protect a 256-bit key with a 4-digit PIN, you're not getting 256 bits of cryptographic strength. Instead, you're getting more like 13 bits of strength: 10⁴ PINs = 2^13.3 PINs, so a 4-digit PIN gives about 13 bits of cryptographic strength. And because 13 bits of strength isn't enough to resist even an attacker with access to a low-cost desktop PC, it's not really providing a meaningful level of protection at all.   

What could Silicon Valley become?

I just read Chief Excutive magazine's annual Best/Worst States for Business survey and learned that for the seventh year in a row, California placed dead last - 50 out of 50. You can find details on the rankings of the states here.

Silicon Valley has managed to create lots of game-changing innovations over the past few decades. What sort of innovations have we missed out on because it's become more difficult to do business in the Valley since the dot-com boom?

The remote timing attack against OpenSSL's ECDSA

I've been asked lots of questions about recent research that shows that it's possible to do a remote timing attack against a particular version of ECDSA that OpenSSL uses. Here's my take on this.

Here's the abstract of the paper that describes this attack:

For over two decades, timing attacks have been an active area of research within applied cryptography. These attacks exploit cryptosystem or protocol implementations that do not run in constant time. When implementing an elliptic curve cryptosystem that provides side-channel resistance, the scalar multiplication routine is a critical component. In such instances, one attractive method often suggested in the literature is Montgomery's ladder that performs a fixed sequence of curve and field operations. This paper describes a timing attack vulnerability in OpenSSL's ladder implementation for curves over binary fields. We use this vulnerability to steal the private key of a TLS server where the server authenticates with ECDSA signatures. Using the timing of the exchanged messages, the messages themselves, and the signatures, we mount a lattice attack that recovers the private key. Finally, we describe and implement an effective countermeasure.

If we look more closely at the paper, here's what we find:

• This IS very clever work. It's stuff that I wish that I could have thought of first.
• This IS an attack against a particular implementation of ECDSA.
• This is NOT an attack against all implementations of TLS.
• This is NOT an attack against all implementations of ECC.
• This is NOT an attack against all implementations of ECDSA.

So does it make sense to panic and ban all uses of TLS/ECDSA/ECC?

Absolutely not.

There might not even be anyone who this attack actually affects. For this to affect you, you need to be using ECDSA in OpenSSL's TLS, and you need to be using it over a binary field. That's probably fairly rare. The version of ECDSA that's specified in the NSA's Suite B cryptography only uses prime fields (curves P-256 and P-384), for example. But if it applies to you, you might want to switch to a different signing algorithm before you're exploited.  

Linda Ronstadt sings about the SEC's email security

The Securities and Exchange Commission recently had a data breach that was caused by the failure of their email encryption product to actually encrypt when it was supposed to. This breach resulted in the exposure of the Social Security numbers and other payroll information of over 4,000 of their employees. 

Here's what the story in the LA Times about the breach said:

The May 4 email was sent by a contractor at the department's National Business Center, which manages payroll, human resources and financial reporting for dozens of federal agencies, Malcomb said. Interior Department policies require that sensitive personnel information be encrypted when emailed.

But the contractor neglected to encrypt the email, and the software in place to catch such errors did not work properly, Malcomb said.

"It was a twofold thing," he said. "The contractor forgot, and then the software failed or malfunctioned." 

I don't know which email encryption product the SEC was using when this incident happened, but it might be what Linda Ronstadt was singing about in this YouTube video.

Keep the URL bar

I just read that the next generation of browsers may hide the URL bar, or at least provide an option for users to hide it. The URL bar is the part of a browser window that tells you what URL you're at.

It typically looks something like this

 

or this

 

Hiding the URL bar is an extremely bad idea from the security point of view. It's easy enough to trick people into installing malware by tricking them into thinking that they're really at a trusted web site, and either removing or hiding the URL bar would make this much easier for hackers. This is definitely one feature that deserves to NOT be included in the next generation browsers.

The Senate thinks about privacy and mobile devices

Earlier today, one of the Senate Subcommittees of the Commerce Committee heard testimony about Consumer Privacy and Protection in the Mobile Marketplace. If you're interested in this, you can find a webcast of the testimony archived here. It certainly looks like they want to pass laws regulating what mobile devices can and can't do with things like location information.

There's certainly lots of innovation happening in the mobile market right now, and I hope that the government doen't stop this by regulating things too much. I still have almost two more years on my current phone contract and I want things to be much more advanced in two years than they are now when I go shopping for a newer phone.