It's basically what you would expect: Appoint a national cyber security advisor, invest in math and science education, establish standards for critical infrastructure, spend money on enforcement, establish national standards for securing personal data and data-breach disclosure, and work with industry and academia to develop a bunch of needed technologies.

I could comment on the plan, but with security the devil is always in the details -- and, of course, at this point there are few details. But since he brought up the topic -- McCain supposedly is "working on the issues" as well -- I have three pieces of policy advice for the next president, whoever he is. They're too detailed for campaign speeches or even position papers, but they're essential for improving information security in our society. Actually, they apply to national security in general. And they're things only government can do.

One, use your immense buying power to improve the security of commercial products and services. One property of technological products is that most of the cost is in the development of the product rather than the production. Think software: The first copy costs millions, but the second copy is free.

You have to secure your own government networks, military and civilian. You have to buy computers for all your government employees. Consolidate those contracts, and start putting explicit security requirements into the RFPs. You have the buying power to get your vendors to make serious security improvements in the products and services they sell to the government, and then we all benefit because they'll include those improvements in the same products and services they sell to the rest of us. We're all safer if information technology is more secure, even though the bad guys can use it, too.

Two, legislate results and not methodologies. There are a lot of areas in security where you need to pass laws, where the security externalities are such that the market fails to provide adequate security. For example, software companies who sell insecure products are exploiting an externality just as much as chemical plants that dump waste into the river. But a bad law is worse than no law. A law requiring companies to secure personal data is good; a law specifying what technologies they should use to do so is not. Mandating software liabilities for software failures is good, detailing how is not. Legislate for the results you want and implement the appropriate penalties; let the market figure out how -- that's what markets are good at.

Three, broadly invest in research. Basic research is risky; it doesn't always pay off. That's why companies have stopped funding it. Bell Labs is gone because nobody could afford it after the AT&T breakup, but the root cause was a desire for higher efficiency and short-term profitability -- not unreasonable in an unregulated business. Government research can be used to balance that by funding long-term research.

Spread those research dollars wide. Lately, most research money has been redirected through DARPA to near-term military-related projects; that's not good. Keep the earmark-happy Congress from dictating how the money is spent. Let the NSF, NIH and other funding agencies decide how to spend the money and don't try to micromanage. Give the national laboratories lots of freedom, too. Yes, some research will sound silly to a layman. But you can't predict what will be useful for what, and if funding is really peer-reviewed, the average results will be much better. Compared to corporate tax breaks and other subsidies, this is chump change.

If our research capability is to remain vibrant, we need more science and math students with decent elementary and high school preparation. The declining interest is partly from the perception that scientists don't get rich like lawyers and dentists and stockbrokers, but also because science isn't valued in a country full of creationists. One way the president can help is by trusting scientific advisers and not overruling them for political reasons.

Oh, and get rid of those post-9/11 restrictions on student visas that are causing (.pdf) so many top students to do their graduate work in Canada, Europe and Asia instead of in the United States. Those restrictions will hurt us immensely in the long run.

Those are the three big ones; the rest is in the details. And it's the details that matter. There are lots of serious issues that you're going to have to tackle: data privacy, data sharing, data mining, government eavesdropping, government databases, use of Social Security numbers as identifiers, and so on. It's not enough to get the broad policy goals right. You can have good intentions and enact a good law, and have the whole thing completely gutted by two sentences sneaked in during rulemaking by some lobbyist.

Security is both subtle and complex, and -- unfortunately -- it doesn't readily lend itself to normal legislative processes. You're used to finding consensus, but security by consensus rarely works. On the internet, security standards are much worse when they're developed by a consensus body, and much better when someone just does them. This doesn't always work -- a lot of crap security has come from companies that have "just done it" -- but nothing but mediocre standards come from consensus bodies. The point is that you won't get good security without pissing someone off: The information broker industry, the voting machine industry, the telcos. The normal legislative process makes it hard to get security right, which is why I don't have much optimism about what you can get done.

And if you're going to appoint a cyber security czar, you have to give him actual budgetary authority -- otherwise he won't be able to get anything done, either.

This essay originally appeared on Wired.com.

It's basically what you would expect: Appoint a national cyber security advisor, invest in math and science education, establish standards for critical infrastructure, spend money on enforcement, establish national standards for securing personal data and data-breach disclosure, and work with industry and academia to develop a bunch of needed technologies.

I could comment on the plan, but with security the devil is always in the details -- and, of course, at this point there are few details. But since he brought up the topic -- McCain supposedly is "working on the issues" as well -- I have three pieces of policy advice for the next president, whoever he is. They're too detailed for campaign speeches or even position papers, but they're essential for improving information security in our society. Actually, they apply to national security in general. And they're things only government can do.

One, use your immense buying power to improve the security of commercial products and services. One property of technological products is that most of the cost is in the development of the product rather than the production. Think software: The first copy costs millions, but the second copy is free.

You have to secure your own government networks, military and civilian. You have to buy computers for all your government employees. Consolidate those contracts, and start putting explicit security requirements into the RFPs. You have the buying power to get your vendors to make serious security improvements in the products and services they sell to the government, and then we all benefit because they'll include those improvements in the same products and services they sell to the rest of us. We're all safer if information technology is more secure, even though the bad guys can use it, too.

Two, legislate results and not methodologies. There are a lot of areas in security where you need to pass laws, where the security externalities are such that the market fails to provide adequate security. For example, software companies who sell insecure products are exploiting an externality just as much as chemical plants that dump waste into the river. But a bad law is worse than no law. A law requiring companies to secure personal data is good; a law specifying what technologies they should use to do so is not. Mandating software liabilities for software failures is good, detailing how is not. Legislate for the results you want and implement the appropriate penalties; let the market figure out how -- that's what markets are good at.

Three, broadly invest in research. Basic research is risky; it doesn't always pay off. That's why companies have stopped funding it. Bell Labs is gone because nobody could afford it after the AT&T breakup, but the root cause was a desire for higher efficiency and short-term profitability -- not unreasonable in an unregulated business. Government research can be used to balance that by funding long-term research.

Spread those research dollars wide. Lately, most research money has been redirected through DARPA to near-term military-related projects; that's not good. Keep the earmark-happy Congress from dictating (.pdf) how the money is spent. Let the NSF, NIH and other funding agencies decide how to spend the money and don't try to micromanage. Give the national laboratories lots of freedom, too. Yes, some research will sound silly to a layman. But you can't predict what will be useful for what, and if funding is really peer-reviewed, the average results will be much better. Compared to corporate tax breaks and other subsidies, this is chump change.

If our research capability is to remain vibrant, we need more science and math students with decent elementary and high school preparation. The declining interest is partly from the perception that scientists don't get rich like lawyers and dentists and stockbrokers, but also because science isn't valued in a country full of creationists. One way the president can help is by trusting scientific advisers and not overruling them for political reasons.

Oh, and get rid of those post-9/11 restrictions on student visas that are causing (.pdf) so many top students to do their graduate work in Canada, Europe and Asia instead of in the United States. Those restrictions will hurt us (.pdf) immensely in the long run.

Those are the three big ones; the rest is in the details. And it's the details that matter. There are lots of serious issues that you're going to have to tackle: data privacy, data sharing, data mining, government eavesdropping, government databases, use of Social Security numbers as identifiers, and so on. It's not enough to get the broad policy goals right. You can have good intentions and enact a good law, and have the whole thing completely gutted by two sentences sneaked in during rulemaking by some lobbyist.

Security is both subtle and complex, and -- unfortunately -- it doesn't readily lend itself to normal legislative processes. You're used to finding consensus, but security by consensus rarely works. On the internet, security standards are much worse when they're developed by a consensus body, and much better when someone just does them. This doesn't always work -- a lot of crap security has come from companies that have "just done it" -- but nothing but mediocre standards come from consensus bodies. The point is that you won't get good security without pissing someone off: The information broker industry, the voting machine industry, the telcos. The normal legislative process makes it hard to get security right, which is why I don't have much optimism about what you can get done.

And if you're going to appoint a cyber security czar, you have to give him actual budgetary authority -- otherwise he won't be able to get anything done, either.

---

Bruce Schneier is chief security technology officer of BT, and author of Beyond Fear: Thinking Sensibly About Security in an Uncertain World.

I wanted to share my slides from the recent Layer One conference [link], where I talked about "SDL Threat Modeling: Past, Present and Future."

There are a few points that I wanted to emphasize. The first is that I'm talking about threat modeling from the perspective of the SDL. We have other threat modeling processes here at Microsoft, and we're working to bring you more clarity in how we speak about them. For my part, I'll try to clearly say "SDL threat modeling," or be explicit when I'm talking about threat modeling in broad terms.

Which brings me to my second point, and a slide I wanted to emphasize. (Shown here)

I no longer think of threat modeling as one thing. I see it as a label for a set of ways to address the question of "what could go wrong" with a design or set of requirements. The SDL has one process. The folks in ACE and Patterns and Practices each have another. All are customized to meet various needs. Much like we have lots of programming languages which address different problems, we're going to have lots of threat modeling processes.

Anyway, I hope you enjoy the slides.

It’s common to see charts similar to the one below used to communicate risk.  On one axis we have Impact, and on the other we have Likelihood.  We’ll save a discussion regarding Impact for another post, but in this post I’d like to point out a couple of subtle but important limitations with the term “likelihood”.

Likelihood connotes the probability of an event occurring.  In fact, you may see explicit probability ranges assigned to each qualitative label (e.g., “Very High = 90% to 100% probable”).   And, while this seems to be on the right track, there are two problems with it:

• It often doesn’t include a timeframe reference.  In other words, does the likelihood statement refer to the probability of the event occurring this week, this year, in this lifetime?  
• It doesn’t provide the means to differentiate between something that may happen once vs. something that may happen multiple times.  For example, a statement; “The likelihood of a virus infection is Very High” doesn’t differentiate whether the event is likely to happen once or many times.

These two limitations become critical when we’re trying to quantify and/or compare risk issues.  

Using frequency, we can account for events that occur many times within the defined timeframe as well as those that occur fewer than once in the timeframe (e.g., .01 times per year, or once in one hundred years).  Of course, this raises the question of how we determine frequency, particularly for infrequent events.  In the interest of keeping this post to a reasonable length, I’ll cover that another time (soon).

Drawing lines

You may have seen charts like the ones below, with lines drawn to differentiate High from Medium, etc.  

(NOTE:  Magnitude scales will vary based on the risk capacity/tolerance of the organization)

These can be useful, but a few challenges I’ve encountered with this approach include:

• If the risk point falls barely on one side of the line or the other, do the lines really serve a useful purpose, at least from the perspective of being able to assign a qualitative value?
• Who drew the lines?  At one place I’ve worked, I couldn’t get management to provide guidance on where to draw the lines so I took a stab at drawing them based on what I thought management’s risk tolerance was given their earlier decisions.  This seemed to work okay, as I didn’t experience much push-back from management, but you need to constantly look for evidence that the lines need to be changed.
• Particularly in larger companies with multiple affiliates or subsidiaries, line placement will vary because each part of the enterprise will have its own risk tolerance.  A “critical” loss at the subsidiary level might not equate to a rounding error at the enterprise level.  I’ve dealt with this by plotting results on two charts; one scaled to the enterprise risk tolerance, and another drawn to the subsidiary’s tolerance.

Of course, the fact that the point isn’t really a point at all, but the intersection of two ranges or distributions further affects the utility of lines. 

I’ve found two ways of charting risk that seem to be well received by management (below).  

(NOTE: These charts were created using Monte Carlo analyses within FAIR-based applications)

My preference is the scatter plot, which does a nice job of visualizing the uncertainty that is a part of any risk analysis.  A couple of things to note:

• No lines have been drawn to label the result “High”, “Medium”, etc.  
• I haven’t used a green-to-red background on the charts.

I will use those illustrative tools if requested by management, but I tend not to use them otherwise.  Besides the challenges I noted above regarding lines, my rationale is that lines and colors tend to bias interpretation of the results.  In other words, if someone sees a risk point plotted in a red background or in the “High” section of the chart, they equate those results as “unacceptable”.  The fact is, the acceptability of a risk condition is often dependent on the value proposition of the situation, the cost to mitigate risk, etc.  I’ve found management is intelligent enough to know that the upper-right part of the chart means more risk than the lower-left.

It was hyped as the first cyberwar: Russia attacking Estonia in cyberspace. But nearly a year later, evidence that the Russian government was involved in the denial-of-service attacks still hasn't emerged. Though Russian hackers were indisputably the major instigators of the attack, the only individuals positively identified have been young ethnic Russians living inside Estonia, who were pissed off over the statue incident.

You know you've got a problem when you can't tell a hostile attack by another nation from bored kids with an axe to grind.

Separating cyberwar, cyberterrorism and cybercrime isn't easy; these days you need a scorecard to tell the difference. It's not just that it’s hard to trace people in cyberspace, it's that military and civilian attacks -- and defenses -- look the same.

The traditional term for technology the military shares with civilians is "dual use." Unlike hand grenades and tanks and missile targeting systems, dual-use technologies have both military and civilian applications. Dual-use technologies used to be exceptions; even things you'd expect to be dual use, like radar systems and toilets, were designed differently for the military. But today, almost all information technology is dual use. We both use the same operating systems, the same networking protocols, the same applications, and even the same security software.

And attack technologies are the same. The recent spurt of targeted hacks against U.S. military networks, commonly attributed to China, exploit the same vulnerabilities and use the same techniques as criminal attacks against corporate networks. Internet worms make the jump to physically-separate classified military networks in less than 24 hours, even if those networks are physically separate. The Navy Cyber Defense Operations Command uses the same tools against the same threats as any large corporation.

Because attackers and defenders use the same IT technology, there is a fundamental tension between cyberattack and cyberdefense. The National Security Agency has referred to this as the "equities issue," and it can be summarized as follows: When a military discovers a vulnerability in a dual-use technology, they can do one of two things. They can alert the manufacturer and fix the vulnerability, thereby protecting both the good guys and the bad guys. Or they can keep quiet about the vulnerability and not tell anyone, thereby leaving the good guys insecure but also leaving the bad guys insecure.

The equities issue has long been hotly debated inside the NSA. Basically, the NSA has two roles: eavesdrop on their stuff, and protect our stuff. When both sides use the same stuff, the agency has to decide whether to exploit vulnerabilities to eavesdrop on their stuff or close the same vulnerabilities to protect our stuff.

In the 1980s and before, the tendency of the NSA was to keep vulnerabilities to themselves. In the 1990s, the tide shifted, and the NSA was starting to open up and help us all improve our security defense. But after the attacks of 9/11, the NSA shifted back to the attack: vulnerabilities were to be hoarded in secret. Slowly, things in the U.S. are shifting back again.

So now we're seeing the NSA help secure Windows Vista and releasing their own version of Linux. The DHS, meanwhile, is funding a project to secure popular open source software packages, and across the Atlantic the UK’s GCHQ is finding bugs in PGPDisk and reporting them back to the company. (NSA is rumored to be doing the same thing with BitLocker.)

I'm in favor of this trend, because my security improves for free. Whenever the NSA finds a security problem and gets the vendor to fix it, our security gets better. It's a side-benefit of dual-use technologies.

But I want governments to do more. I want them to use their buying power to improve my security. I want them to offer countrywide contracts for software, both security and non-security, that have explicit security requirements. If these contracts are big enough, companies will work to modify their products to meet those requirements. And again, we all benefit from the security improvements.

The only example of this model I know about is a U.S. government-wide procurement competition for full-disk encryption, but this can certainly be done with firewalls, intrusion detection systems, databases, networking hardware, even operating systems.

When it comes to IT technologies, the equities issue should be a no-brainer. The good uses of our common hardware, software, operating systems, network protocols, and everything else vastly outweigh the bad uses. It's time that the government used its immense knowledge and experience, as well as its buying power, to improve cybersecurity for all of us.

This essay originally appeared on Wired.com.

It was hyped as the first cyberwar: Russia attacking Estonia in cyberspace. But nearly a year later, evidence that the Russian government was involved in the denial-of-service attacks still hasn't emerged. Though Russian hackers were indisputably the major instigators of the attack, the only individuals positively identified have been young ethnic Russians living inside Estonia, who were pissed off over the statue incident.

You know you've got a problem when you can't tell a hostile attack by another nation from bored kids with an axe to grind.

Separating cyberwar, cyberterrorism and cybercrime isn't easy; these days you need a scorecard to tell the difference. It's not just that it’s hard to trace people in cyberspace, it's that military and civilian attacks -- and defenses -- look the same.

The traditional term for technology the military shares with civilians is "dual use." Unlike hand grenades and tanks and missile targeting systems, dual-use technologies have both military and civilian applications. Dual-use technologies used to be exceptions; even things you'd expect to be dual use, like radar systems and toilets, were designed differently for the military. But today, almost all information technology is dual use. We both use the same operating systems, the same networking protocols, the same applications, and even the same security software.

And attack technologies are the same. The recent spurt of targeted hacks against U.S. military networks, commonly attributed to China, exploit the same vulnerabilities and use the same techniques as criminal attacks against corporate networks. Internet worms make the jump to classified military networks in less than 24 hours, even if those networks are physically separate. The Navy Cyber Defense Operations Command uses the same tools against the same threats as any large corporation.

Because attackers and defenders use the same IT technology, there is a fundamental tension between cyberattack and cyberdefense. The National Security Agency has referred to this as the "equities issue," and it can be summarized as follows: When a military discovers a vulnerability in a dual-use technology, they can do one of two things. They can alert the manufacturer and fix the vulnerability, thereby protecting both the good guys and the bad guys. Or they can keep quiet about the vulnerability and not tell anyone, thereby leaving the good guys insecure but also leaving the bad guys insecure.

The equities issue has long been hotly debated inside the NSA. Basically, the NSA has two roles: eavesdrop on their stuff, and protect our stuff. When both sides use the same stuff, the agency has to decide whether to exploit vulnerabilities to eavesdrop on their stuff or close the same vulnerabilities to protect our stuff.

In the 1980s and before, the tendency of the NSA was to keep vulnerabilities to themselves. In the 1990s, the tide shifted, and the NSA was starting to open up and help us all improve our security defense. But after the attacks of 9/11, the NSA shifted back to the attack: vulnerabilities were to be hoarded in secret. Slowly, things in the U.S. are shifting back again.

So now we're seeing the NSA help secure Windows Vista and releasing their own version of Linux. The DHS, meanwhile, is funding a project to secure popular open source software packages, and across the Atlantic the UK’s GCHQ is finding bugs in PGPDisk and reporting them back to the company. (NSA is rumored to be doing the same thing with BitLocker.)

I'm in favor of this trend, because my security improves for free. Whenever the NSA finds a security problem and gets the vendor to fix it, our security gets better. It's a side-benefit of dual-use technologies.

But I want governments to do more. I want them to use their buying power to improve my security. I want them to offer countrywide contracts for software, both security and non-security, that have explicit security requirements. If these contracts are big enough, companies will work to modify their products to meet those requirements. And again, we all benefit from the security improvements.

The only example of this model I know about is a U.S. government-wide procurement competition for full-disk encryption, but this can certainly be done with firewalls, intrusion detection systems, databases, networking hardware, even operating systems.

When it comes to IT technologies, the equities issue should be a no-brainer. The good uses of our common hardware, software, operating systems, network protocols, and everything else vastly outweigh the bad uses. It's time that the government used its immense knowledge and experience, as well as its buying power, to improve cybersecurity for all of us.

This essay originally appeared on Wired.com.