Page 11 of 33
Interesting blog post on the security costs for the $50B Air Force bomber program—estimated to be $8B. This isn’t all computer security, but the original article specifically calls out Chinese computer espionage as a primary threat.
Scareware is fraudulent software that uses deceptive advertising to trick users into believing they’re infected with some variety of malware, then convinces them to pay money to protect themselves. The infection isn’t real, and the software they buy is fake, too. It’s all a scam.
Here’s one scareware operator who sold “more than 1 million software products” at “$39.95 or more,” and now has to pay $8.2 million to settle a Federal Trade Commission complaint.
Seems to me that $40 per customer, minus $8.20 to pay off the FTC, is still a pretty good revenue model. Their operating costs can’t be very high, since the software doesn’t actually do anything. Yes, a court ordered them to close down their business, but certainly there are other creative entrepreneurs that can recognize a business opportunity when they see it.
Cyber War: The Next Threat to National Security and What to do About It by Richard Clarke and Robert Knake, HarperCollins, 2010.
Cyber War is a fast and enjoyable read. This means you could give the book to your non-techy friends, and they’d understand most of it, enjoy all of it, and learn a lot from it. Unfortunately, while there’s a lot of smart discussion and good information in the book, there’s also a lot of fear-mongering and hyperbole as well. Since there’s no easy way to tell someone what parts of the book to pay attention to and what parts to take with a grain of salt, I can’t recommend it for that purpose. This is a pity, because parts of the book really need to be widely read and discussed.
The fear-mongering and hyperbole is mostly in the beginning. There, the authors describe the cyberwar of novels. Hackers disable air traffic control, delete money from bank accounts, cause widespread blackouts, release chlorine gas from chemical plants, and—this is my favorite—remotely cause your printer to catch on fire. It’s exciting and scary stuff, but not terribly realistic. Even their discussions of previous “cyber wars”—Estonia, Georgia, attacks against U.S. and South Korea on July 4, 2009—are full of hyperbole. A lot of what they write is unproven speculation, but they don’t say that.
Better is the historical discussion of the formation of the U.S. Cyber Command, but there are important omissions. There’s nothing about the cyberwar fear being stoked that accompanied this: by the NSA’s General Keith Alexander—who became the first head of the command—or by the NSA’s former director, current military contractor, by Mike McConnell, who’s Senior Vice President at Booz Allen Hamilton, and by others. By hyping the threat, the former has amassed a lot of power, and the latter a lot of money. Cyberwar is the new cash cow of the military-industrial complex, and any political discussion of cyberwar should include this as well.
Also interesting is the discussion of the asymmetric nature of the threat. A country like the United States, which is heavily dependent on the Internet and information technology, is much more vulnerable to cyber-attacks than a less-developed country like North Korea. This means that a country like North Korea would benefit from a cyberwar exchange: they’d inflict far more damage than they’d incur. This also means that, in this hypothetical cyberwar, there would be pressure on the U.S. to move the war to another theater: air and ground, for example. Definitely worth thinking about.
Most important is the section on treaties. Clarke and Knake have a lot of experience with nuclear treaties, and have done considerable thinking about how to apply that experience to cyberspace. The parallel isn’t perfect, but there’s a lot to learn about what worked and what didn’t, and—more importantly—how things worked and didn’t. The authors discuss treaties banning cyberwar entirely (unlikely), banning attacks against civilians, limiting what is allowed in peacetime, stipulating no first use of cyber weapons, and so on. They discuss cyberwar inspections, and how these treaties might be enforced. Since cyberwar would be likely to result in a new worldwide arms race, one with a more precarious trigger than the nuclear arms race, this part should be read and discussed far and wide. Sadly, it gets lost in the rest of the book. And, since the book lacks an index, it can be hard to find any particular section after you’re done reading it.
In the last chapter, the authors lay out their agenda for the future, which largely I agree with.
This is great stuff, and a fine starting place for a national policy discussion on cybersecurity, whether it be against a military, espionage, or criminal threat. Unfortunately, for readers to get there, they have to wade through the rest of the book. And unless their bullshit detectors are already well-calibrated on this topic, I don’t want them reading all the hyperbole and fear-mongering that comes before, no matter how readable the book.
Note: I read Cyber War in April, when it first came out. I wanted to write a review then, but found that while my Kindle is great for reading, it’s terrible for flipping back and forth looking for bits and pieces to write about in a review. So I let the review languish. Finally, I borrowed a paper copy from my local library.
Some other reviews of the book Cyber War. See also the reviews on the Amazon page.
That’s no less sensational than the Calgary Herald headline: “Total cyber-meltdown almost inevitable, expert tells Calgary audience.” That’s former NSA Technical Director Brian Snow talking to a university audience.
“It’s long weeks to short months at best before there’s a security meltdown,” said Snow, as a guest lecturer for the Institute for Security, Privacy and Information Assurance, an interdisciplinary group at the university dedicated to information security.
“Will a bank failure be the wake-up call before we act? It’s a global problem—not just the U.S., not just Canada, but the world.”
I know Brian, and I have to believe his definition of “security meltdown” is more limited than the headline leads one to believe.
Last week, I gave a talk on cyberwar and cyberconflict at the Institute for International and European Affairs in Dublin. Here’s the video.
It was only the second time I’ve given the talk. About three quarters in, I noticed that I didn’t have my fourth and final page of notes. So if the ending feels a bit scattered, that’s why.
Last month, Scott Charney of Microsoft proposed that infected computers be quarantined from the Internet. Using a public health model for Internet security, the idea is that infected computers spreading worms and viruses are a risk to the greater community and thus need to be isolated. Internet service providers would administer the quarantine, and would also clean up and update users’ computers so they could rejoin the greater Internet.
This isn’t a new idea. Already there are products that test computers trying to join private networks, and only allow them access if their security patches are up-to-date and their antivirus software certifies them as clean. Computers denied access are sometimes shunned to a limited-capability sub-network where all they can do is download and install the updates they need to regain access. This sort of system has been used with great success at universities and end-user-device-friendly corporate networks. They’re happy to let you log in with any device you want—this is the consumerization trend in action—as long as your security is up to snuff.
Charney’s idea is to do that on a larger scale. To implement it we have to deal with two problems. There’s the technical problem—making the quarantine work in the face of malware designed to evade it, and the social problem—ensuring that people don’t have their computers unduly quarantined. Understanding the problems requires us to understand quarantines in general.
Quarantines have been used to contain disease for millennia. In general several things need to be true for them to work. One, the thing being quarantined needs to be easily recognized. It’s easier to quarantine a disease if it has obvious physical characteristics: fever, boils, etc. If there aren’t any obvious physical effects, or if those effects don’t show up while the disease is contagious, a quarantine is much less effective.
Similarly, it’s easier to quarantine an infected computer if that infection is detectable. As Charney points out, his plan is only effective against worms and viruses that our security products recognize, not against those that are new and still undetectable.
Two, the separation has to be effective. The leper colonies on Molokai and Spinalonga both worked because it was hard for the quarantined to leave. Quarantined medieval cities worked less well because it was too easy to leave, or—when the diseases spread via rats or mosquitoes—because the quarantine was targeted at the wrong thing.
Computer quarantines have been generally effective because the users whose computers are being quarantined aren’t sophisticated enough to break out of the quarantine, and find it easier to update their software and rejoin the network legitimately.
Three, only a small section of the population must need to be quarantined. The solution works only if it’s a minority of the population that’s affected, either with physical diseases or computer diseases. If most people are infected, overall infection rates aren’t going to be slowed much by quarantining. Similarly, a quarantine that tries to isolate most of the Internet simply won’t work.
Fourth, the benefits must outweigh the costs. Medical quarantines are expensive to maintain, especially if people are being quarantined against their will. Determining who to quarantine is either expensive (if it’s done correctly) or arbitrary, authoritative and abuse-prone (if it’s done badly). It could even be both. The value to society must be worth it.
It’s the last point that Charney and others emphasize. If Internet worms were only damaging to the infected, we wouldn’t need a societally imposed quarantine like this. But they’re damaging to everyone else on the Internet, spreading and infecting others. At the same time, we can implement systems that quarantine cheaply. The value to society far outweighs the cost.
That makes sense, but once you move quarantines from isolated private networks to the general Internet, the nature of the threat changes. Imagine an intelligent and malicious infectious disease: That’s what malware is. The current crop of malware ignores quarantines; they’re few and far enough between not to affect their effectiveness.
If we tried to implement Internet-wide—or even countrywide—quarantining, worm-writers would start building in ways to break the quarantine. So instead of nontechnical users not bothering to break quarantines because they don’t know how, we’d have technically sophisticated virus-writers trying to break quarantines. Implementing the quarantine at the ISP level would help, and if the ISP monitored computer behavior, not just specific virus signatures, it would be somewhat effective even in the face of evasion tactics. But evasion would be possible, and we’d be stuck in another computer security arms race. This isn’t a reason to dismiss the proposal outright, but it is something we need to think about when weighing its potential effectiveness.
Additionally, there’s the problem of who gets to decide which computers to quarantine. It’s easy on a corporate or university network: the owners of the network get to decide. But the Internet doesn’t have that sort of hierarchical control, and denying people access without due process is fraught with danger. What are the appeal mechanisms? The audit mechanisms? Charney proposes that ISPs administer the quarantines, but there would have to be some central authority that decided what degree of infection would be sufficient to impose the quarantine. Although this is being presented as a wholly technical solution, it’s these social and political ramifications that are the most difficult to determine and the easiest to abuse.
Once we implement a mechanism for quarantining infected computers, we create the possibility of quarantining them in all sorts of other circumstances. Should we quarantine computers that don’t have their patches up to date, even if they’re uninfected? Might there be a legitimate reason for someone to avoid patching his computer? Should the government be able to quarantine someone for something he said in a chat room, or a series of search queries he made? I’m sure we don’t think it should, but what if that chat and those queries revolved around terrorism? Where’s the line?
Microsoft would certainly like to quarantine any computers it feels are not running legal copies of its operating system or applications software.The music and movie industry will want to quarantine anyone it decides is downloading or sharing pirated media files—they’re already pushing similar proposals.
A security measure designed to keep malicious worms from spreading over the Internet can quickly become an enforcement tool for corporate business models. Charney addresses the need to limit this kind of function creep, but I don’t think it will be easy to prevent; it’s an enforcement mechanism just begging to be used.
Once you start thinking about implementation of quarantine, all sorts of other social issues emerge. What do we do about people who need the Internet? Maybe VoIP is their only phone service. Maybe they have an Internet-enabled medical device. Maybe their business requires the Internet to run. The effects of quarantining these people would be considerable, even potentially life-threatening. Again, where’s the line?
What do we do if people feel they are quarantined unjustly? Or if they are using nonstandard software unfamiliar to the ISP? Is there an appeals process? Who administers it? Surely not a for-profit company.
Public health is the right way to look at this problem. This conversation—between the rights of the individual and the rights of society—is a valid one to have, and this solution is a good possibility to consider.
There are some applicable parallels. We require drivers to be licensed and cars to be inspected not because we worry about the danger of unlicensed drivers and uninspected cars to themselves, but because we worry about their danger to other drivers and pedestrians. The small number of parents who don’t vaccinate their kids have already caused minor outbreaks of whooping cough and measles among the greater population. We all suffer when someone on the Internet allows his computer to get infected. How we balance that with individuals’ rights to maintain their own computers as they see fit is a discussion we need to start having.
This essay previously appeared on Forbes.com.
EDITED TO ADD (11/15): From an anonymous reader:
In your article you mention that for quarantines to work, you must be able to detect infected individuals. It must also be detectable quickly, before the individual has the opportunity to infect many others. Quarantining an individual after they’ve infected most of the people they regularly interact with is of little value. You must quarantine individuals when they have infected, on average, less than one other person.
Just as worm-writers would respond to the technical mechanisms to implement a quarantine by investing in ways to get around them, they would also likely invest in outpacing the quarantine. If a worm is designed to spread fast, even the best quarantine mechanisms may be unable to keep up.
Another concern with quarantining mechanisms is the damage that attackers could do if they were able to compromise the mechanism itself. This is of especially great concern if the mechanism were to include code within end-user’s TCBs to scan computers essentially a built-in root kit. Without a scanner in the end-user’s TCB, it’s hard to see how you could reliably detect infections.
How often should you change your password? I get asked that question a lot, usually by people annoyed at their employer’s or bank’s password expiration policy: people who finally memorized their current password and are realizing they’ll have to write down their new password. How could that possibly be more secure, they want to know.
The answer depends on what the password is used for.
The downside of changing passwords is that it makes them harder to remember. And if you force people to change their passwords regularly, they’re more likely to choose easy-to-remember—and easy-to-guess—passwords than they are if they can use the same passwords for many years. So any password-changing policy needs to be chosen with that consideration in mind.
The primary reason to give an authentication credential—not just a password, but any authentication credential—an expiration date is to limit the amount of time a lost, stolen, or forged credential can be used by someone else. If a membership card expires after a year, then if someone steals that card he can at most get a year’s worth of benefit out of it. After that, it’s useless.
This becomes less important when the credential contains a biometric—even a photograph—or is verified online. It’s much less important for a credit card or passport to have an expiration date, now that they’re not so much bearer documents as just pointers to a database. If, for example, the credit card database knows when a card is no longer valid, there’s no reason to put an expiration date on the card. But the expiration date does mean that a forgery is only good for a limited length of time.
Passwords are no different. If a hacker gets your password either by guessing or stealing it, he can access your network as long as your password is valid. If you have to update your password every quarter, that significantly limits the utility of that password to the attacker.
At least, that’s the traditional theory. It assumes a passive attacker, one who will eavesdrop over time without alerting you that he’s there. In many cases today, though, that assumption no longer holds. An attacker who gets the password to your bank account by guessing or stealing it isn’t going to eavesdrop. He’s going to transfer money out of your account—and then you’re going to notice. In this case, it doesn’t make a lot of sense to change your password regularly—but it’s vital to change it immediately after the fraud occurs.
Someone committing espionage in a private network is more likely to be stealthy. But he’s also not likely to rely on the user credential he guessed and stole; he’s going to install backdoor access or create his own account. Here again, forcing network users to regularly change their passwords is less important than forcing everyone to change their passwords immediately after the spy is detected and removed—you don’t want him getting in again.
Social networking sites are somewhere in the middle. Most of the criminal attacks against Facebook users use the accounts for fraud. “Help! I’m in London and my wallet was stolen. Please wire money to this account. Thank you.” Changing passwords periodically doesn’t help against this attack, although – of course – change your password as soon as you regain control of your account. But if your kid sister has your password—or the tabloid press, if you’re that kind of celebrity—they’re going to listen in until you change it. And you might not find out about it for months.
So in general: you don’t need to regularly change the password to your computer or online financial accounts (including the accounts at retail sites); definitely not for low-security accounts. You should change your corporate login password occasionally, and you need to take a good hard look at your friends, relatives, and paparazzi before deciding how often to change your Facebook password. But if you break up with someone you’ve shared a computer with, change them all.
Two final points. One, this advice is for login passwords. There’s no reason to change any password that is a key to an encrypted file. Just keep the same password as long as you keep the file, unless you suspect it’s been compromised. And two, it’s far more important to choose a good password for the sites that matter—don’t worry about sites you don’t care about that nonetheless demand that you register and choose a password—in the first place than it is to change it. So if you have to worry about something, worry about that. And write your passwords down, or use a program like Password Safe.
This essay originally appeared on DarkReading.com.
EDITED TO ADD (11/14): Microsoft Research says the same thing.
“The Security of Modern Password Expiration: An Algorithmic Framework and Empirical Analysis.”
Those with either an engineering or management background are aware that one cannot optimize everything at once that requirements are balanced by constraints. I am not aware of another domain where this is as true as it is in cybersecurity and the question of a policy response to cyber insecurity at the national level. In engineering, this is said as “Fast, Cheap, Reliable: Choose Two.” In the public policy arena, we must first remember the definition of a free country: a place where that which is not forbidden is permitted. As we consider the pursuit of cybersecurity, we will return to that idea time and time again; I believe that we are now faced with “Freedom, Security, Convenience: Choose Two.”
Computer security experts are often surprised at which stories get picked up by the mainstream media. Sometimes it makes no sense. Why this particular data breach, vulnerability, or worm and not others? Sometimes it’s obvious. In the case of Stuxnet, there’s a great story.
As the story goes, the Stuxnet worm was designed and released by a government—the U.S. and Israel are the most common suspects—specifically to attack the Bushehr nuclear power plant in Iran. How could anyone not report that? It combines computer attacks, nuclear power, spy agencies and a country that’s a pariah to much of the world. The only problem with the story is that it’s almost entirely speculation.
Here’s what we do know: Stuxnet is an Internet worm that infects Windows computers. It primarily spreads via USB sticks, which allows it to get into computers and networks not normally connected to the Internet. Once inside a network, it uses a variety of mechanisms to propagate to other machines within that network and gain privilege once it has infected those machines. These mechanisms include both known and patched vulnerabilities, and four “zero-day exploits”: vulnerabilities that were unknown and unpatched when the worm was released. (All the infection vulnerabilities have since been patched.)
Stuxnet doesn’t actually do anything on those infected Windows computers, because they’re not the real target. What Stuxnet looks for is a particular model of Programmable Logic Controller (PLC) made by Siemens (the press often refers to these as SCADA systems, which is technically incorrect). These are small embedded industrial control systems that run all sorts of automated processes: on factory floors, in chemical plants, in oil refineries, at pipelines—and, yes, in nuclear power plants. These PLCs are often controlled by computers, and Stuxnet looks for Siemens SIMATIC WinCC/Step 7 controller software.
If it doesn’t find one, it does nothing. If it does, it infects it using yet another unknown and unpatched vulnerability, this one in the controller software. Then it reads and changes particular bits of data in the controlled PLCs. It’s impossible to predict the effects of this without knowing what the PLC is doing and how it is programmed, and that programming can be unique based on the application. But the changes are very specific, leading many to believe that Stuxnet is targeting a specific PLC, or a specific group of PLCs, performing a specific function in a specific location—and that Stuxnet’s authors knew exactly what they were targeting.
It’s already infected more than 50,000 Windows computers, and Siemens has reported 14 infected control systems, many in Germany. (These numbers were certainly out of date as soon as I typed them.) We don’t know of any physical damage Stuxnet has caused, although there are rumors that it was responsible for the failure of India’s INSAT-4B satellite in July. We believe that it did infect the Bushehr plant.
All the anti-virus programs detect and remove Stuxnet from Windows systems.
Stuxnet was first discovered in late June, although there’s speculation that it was released a year earlier. As worms go, it’s very complex and got more complex over time. In addition to the multiple vulnerabilities that it exploits, it installs its own driver into Windows. These have to be signed, of course, but Stuxnet used a stolen legitimate certificate. Interestingly, the stolen certificate was revoked on July 16, and a Stuxnet variant with a different stolen certificate was discovered on July 17.
Over time the attackers swapped out modules that didn’t work and replaced them with new ones—perhaps as Stuxnet made its way to its intended target. Those certificates first appeared in January. USB propagation, in March.
Stuxnet has two ways to update itself. It checks back to two control servers, one in Malaysia and the other in Denmark, but also uses a peer-to-peer update system: When two Stuxnet infections encounter each other, they compare versions and make sure they both have the most recent one. It also has a kill date of June 24, 2012. On that date, the worm will stop spreading and delete itself.
We don’t know who wrote Stuxnet. We don’t know why. We don’t know what the target is, or if Stuxnet reached it. But you can see why there is so much speculation that it was created by a government.
Stuxnet doesn’t act like a criminal worm. It doesn’t spread indiscriminately. It doesn’t steal credit card information or account login credentials. It doesn’t herd infected computers into a botnet. It uses multiple zero-day vulnerabilities. A criminal group would be smarter to create different worm variants and use one in each. Stuxnet performs sabotage. It doesn’t threaten sabotage, like a criminal organization intent on extortion might.
Stuxnet was expensive to create. Estimates are that it took 8 to 10 people six months to write. There’s also the lab setup—surely any organization that goes to all this trouble would test the thing before releasing it—and the intelligence gathering to know exactly how to target it. Additionally, zero-day exploits are valuable. They’re hard to find, and they can only be used once. Whoever wrote Stuxnet was willing to spend a lot of money to ensure that whatever job it was intended to do would be done.
None of this points to the Bushehr nuclear power plant in Iran, though. Best I can tell, this rumor was started by Ralph Langner, a security researcher from Germany. He labeled his theory “highly speculative,” and based it primarily on the facts that Iran had an unusually high number of infections (the rumor that it had the most infections of any country seems not to be true), that the Bushehr nuclear plant is a juicy target, and that some of the other countries with high infection rates—India, Indonesia, and Pakistan—are countries where the same Russian contractor involved in Bushehr is also involved. This rumor moved into the computer press and then into the mainstream press, where it became the accepted story, without any of the original caveats.
Once a theory takes hold, though, it’s easy to find more evidence. The word “myrtus” appears in the worm: an artifact that the compiler left, possibly by accident. That’s the myrtle plant. Of course, that doesn’t mean that druids wrote Stuxnet. According to the story, it refers to Queen Esther, also known as Hadassah; she saved the Persian Jews from genocide in the 4th century B.C. “Hadassah” means “myrtle” in Hebrew.
Stuxnet also sets a registry value of “19790509” to alert new copies of Stuxnet that the computer has already been infected. It’s rather obviously a date, but instead of looking at the gazillion things—large and small—that happened on that the date, the story insists it refers to the date Persian Jew Habib Elghanain was executed in Tehran for spying for Israel.
Sure, these markers could point to Israel as the author. On the other hand, Stuxnet’s authors were uncommonly thorough about not leaving clues in their code; the markers could have been deliberately planted by someone who wanted to frame Israel. Or they could have been deliberately planted by Israel, who wanted us to think they were planted by someone who wanted to frame Israel. Once you start walking down this road, it’s impossible to know when to stop.
Another number found in Stuxnet is 0xDEADF007. Perhaps that means “Dead Fool” or “Dead Foot,” a term that refers to an airplane engine failure. Perhaps this means Stuxnet is trying to cause the targeted system to fail. Or perhaps not. Still, a targeted worm designed to cause a specific sabotage seems to be the most likely explanation.
If that’s the case, why is Stuxnet so sloppily targeted? Why doesn’t Stuxnet erase itself when it realizes it’s not in the targeted network? When it infects a network via USB stick, it’s supposed to only spread to three additional computers and to erase itself after 21 days—but it doesn’t do that. A mistake in programming, or a feature in the code not enabled? Maybe we’re not supposed to reverse engineer the target. By allowing Stuxnet to spread globally, its authors committed collateral damage worldwide. From a foreign policy perspective, that seems dumb. But maybe Stuxnet’s authors didn’t care.
My guess is that Stuxnet’s authors, and its target, will forever remain a mystery.
This essay originally appeared on Forbes.com.
My alternate explanations for Stuxnet were cut from the essay. Here they are:
Note that some of these alternate explanations overlap.
EDITED TO ADD (10/7): Symantec published a very detailed analysis. It seems like one of the zero-day vulnerabilities wasn’t a zero-day after all. Good CNet article. More speculation, without any evidence. Decent debunking. Alternate theory, that the target was the uranium centrifuges in Natanz, Iran.
This list is from Malcolm Harkins, Intel’s chief information security officer, and it’s a good one (from a talk at Forrester’s Security Forum):
His dig at open source software is just plain dumb, though:
Harkins cited mobile apps: “What kind of security do we think is in something that sells for 99 cents? Not much.”
Sidebar photo of Bruce Schneier by Joe MacInnis.