Schneier on Security: Tagged network security

Entries Tagged "network security"

Page 11 of 11

Wi-Fi Shielding Paint

I have no idea how well this works, but it’s a clever idea. From Information Week:

Force Field Wireless makes three products that it says can dramatically reduce the leakage of wireless signals from a room or building.

One odd side-point from the article:

Force Field has been trying to interest the Department of Homeland Security, but discussions are ongoing, Wray says. “Ironically, we have had foreign governments contact us—from the Middle East. Kind of scary.” Wray says he won’t sell to them.

I wonder what’s so scary about selling metal paint to a Middle East government. Maybe the company thinks they will use the paint to “cover up” their misdeeds or poison political prisoners?

Posted on December 30, 2004 at 5:52 PM • View Comments

Safe Personal Computing

I am regularly asked what average Internet users can do to ensure their security. My first answer is usually, “Nothing—you’re screwed.”

But that’s not true, and the reality is more complicated. You’re screwed if you do nothing to protect yourself, but there are many things you can do to increase your security on the Internet.

Two years ago, I published a list of PC security recommendations. The idea was to give home users concrete actions they could take to improve security. This is an update of that list: a dozen things you can do to improve your security.

General: Turn off the computer when you’re not using it, especially if you have an “always on” Internet connection.

Laptop security: Keep your laptop with you at all times when not at home; treat it as you would a wallet or purse. Regularly purge unneeded data files from your laptop. The same goes for PDAs. People tend to store more personal data—including passwords and PINs—on PDAs than they do on laptops.

Backups: Back up regularly. Back up to disk, tape or CD-ROM. There’s a lot you can’t defend against; a recent backup will at least let you recover from an attack. Store at least one set of backups off-site (a safe-deposit box is a good place) and at least one set on-site. Remember to destroy old backups. The best way to destroy CD-Rs is to microwave them on high for five seconds. You can also break them in half or run them through better shredders.

Operating systems: If possible, don’t use Microsoft Windows. Buy a Macintosh or use Linux. If you must use Windows, set up Automatic Update so that you automatically receive security patches. And delete the files “command.com” and “cmd.exe.”

Applications: Limit the number of applications on your machine. If you don’t need it, don’t install it. If you no longer need it, uninstall it. Look into one of the free office suites as an alternative to Microsoft Office. Regularly check for updates to the applications you use and install them. Keeping your applications patched is important, but don’t lose sleep over it.

Browsing: Don’t use Microsoft Internet Explorer, period. Limit use of cookies and applets to those few sites that provide services you need. Set your browser to regularly delete cookies. Don’t assume a Web site is what it claims to be, unless you’ve typed in the URL yourself. Make sure the address bar shows the exact address, not a near-miss.

Web sites: Secure Sockets Layer (SSL) encryption does not provide any assurance that the vendor is trustworthy or that its database of customer information is secure.

Think before you do business with a Web site. Limit the financial and personal data you send to Web sites—don’t give out information unless you see a value to you. If you don’t want to give out personal information, lie. Opt out of marketing notices. If the Web site gives you the option of not storing your information for later use, take it. Use a credit card for online purchases, not a debit card.

Passwords: You can’t memorize good enough passwords any more, so don’t bother. For high-security Web sites such as banks, create long random passwords and write them down. Guard them as you would your cash: i.e., store them in your wallet, etc.

Never reuse a password for something you care about. (It’s fine to have a single password for low-security sites, such as for newspaper archive access.) Assume that all PINs can be easily broken and plan accordingly.

Never type a password you care about, such as for a bank account, into a non-SSL encrypted page. If your bank makes it possible to do that, complain to them. When they tell you that it is OK, don’t believe them; they’re wrong.

E-mail : Turn off HTML e-mail. Don’t automatically assume that any e-mail is from the “From” address.

Delete spam without reading it. Don’t open messages with file attachments, unless you know what they contain; immediately delete them. Don’t open cartoons, videos and similar “good for a laugh” files forwarded by your well-meaning friends; again, immediately delete them.

Never click links in e-mail unless you’re sure about the e-mail; copy and paste the link into your browser instead. Don’t use Outlook or Outlook Express. If you must use Microsoft Office, enable macro virus protection; in Office 2000, turn the security level to “high” and don’t trust any received files unless you have to. If you’re using Windows, turn off the “hide file extensions for known file types” option; it lets Trojan horses masquerade as other types of files. Uninstall the Windows Scripting Host if you can get along without it. If you can’t, at least change your file associations, so that script files aren’t automatically sent to the Scripting Host if you double-click them.

Antivirus and anti-spyware software : Use it—either a combined program or two separate programs. Download and install the updates, at least weekly and whenever you read about a new virus in the news. Some antivirus products automatically check for updates. Enable that feature and set it to “daily.”

Firewall : Spend $50 for a Network Address Translator firewall device; it’s likely to be good enough in default mode. On your laptop, use personal firewall software. If you can, hide your IP address. There’s no reason to allow any incoming connections from anybody.

Encryption: Install an e-mail and file encryptor (like PGP). Encrypting all your e-mail or your entire hard drive is unrealistic, but some mail is too sensitive to send in the clear. Similarly, some files on your hard drive are too sensitive to leave unencrypted.

None of the measures I’ve described are foolproof. If the secret police wants to target your data or your communications, no countermeasure on this list will stop them. But these precautions are all good network-hygiene measures, and they’ll make you a more difficult target than the computer next door. And even if you only follow a few basic measures, you’re unlikely to have any problems.

I’m stuck using Microsoft Windows and Office, but I use Opera for Web browsing and Eudora for e-mail. I use Windows Update to automatically get patches and install other patches when I hear about them. My antivirus software updates itself regularly. I keep my computer relatively clean and delete applications that I don’t need. I’m diligent about backing up my data and about storing data files that are no longer needed offline.

I’m suspicious to the point of near-paranoia about e-mail attachments and Web sites. I delete cookies and spyware. I watch URLs to make sure I know where I am, and I don’t trust unsolicited e-mails. I don’t care about low-security passwords, but try to have good passwords for accounts that involve money. I still don’t do Internet banking. I have my firewall set to deny all incoming connections. And I turn my computer off when I’m not using it.

That’s basically it. Really, it’s not that hard. The hardest part is developing an intuition about e-mail and Web sites. But that just takes experience.

This essay previously appeared on CNet

Posted on December 13, 2004 at 9:59 AM • View Comments

Computer Security and Liability

Information insecurity is costing us billions. We pay for it in theft: information theft, financial theft. We pay for it in productivity loss, both when networks stop working and in the dozens of minor security inconveniences we all have to endure. We pay for it when we have to buy security products and services to reduce those other two losses. We pay for security, year after year.

The problem is that all the money we spend isn’t fixing the problem. We’re paying, but we still end up with insecurities.

The problem is insecure software. It’s bad design, poorly implemented features, inadequate testing and security vulnerabilities from software bugs. The money we spend on security is to deal with the effects of insecure software.

And that’s the problem. We’re not paying to improve the security of the underlying software. We’re paying to deal with the problem rather than to fix it.

The only way to fix this problem is for vendors to fix their software, and they won’t do it until it’s in their financial best interests to do so.

Today, the costs of insecure software aren’t borne by the vendors that produce the software. In economics, this is known as an externality, the cost of a decision that’s borne by people other than those making the decision.

There are no real consequences to the vendors for having bad security or low-quality software. Even worse, the marketplace often rewards low quality. More precisely, it rewards additional features and timely release dates, even if they come at the expense of quality.

If we expect software vendors to reduce features, lengthen development cycles and invest in secure software development processes, it needs to be in their financial best interests to do so. If we expect corporations to spend significant resources on their own network security—especially the security of their customers—it also needs to be in their financial best interests.

Liability law is a way to make it in those organizations’ best interests. Raising the risk of liability raises the costs of doing it wrong and therefore increases the amount of money a CEO is willing to spend to do it right. Security is risk management; liability fiddles with the risk equation.

Basically, we have to tweak the risk equation so the CEO cares about actually fixing the problem, and putting pressure on his balance sheet is the best way to do that.

Clearly, this isn’t all or nothing. There are many parties involved in a typical software attack. There’s the company that sold the software with the vulnerability in the first place. There’s the person who wrote the attack tool. There’s the attacker himself, who used the tool to break into a network. There’s the owner of the network, who was entrusted with defending that network. One hundred percent of the liability shouldn’t fall on the shoulders of the software vendor, just as 100% shouldn’t fall on the attacker or the network owner. But today, 100% of the cost falls directly on the network owner, and that just has to stop.

We will always pay for security. If software vendors have liability costs, they’ll pass those on to us. It might not be cheaper than what we’re paying today. But as long as we’re going to pay, we might as well pay to fix the problem. Forcing the software vendor to pay to fix the problem and then pass those costs on to us means that the problem might actually get fixed.

Liability changes everything. Currently, there is no reason for a software company not to offer feature after feature after feature. Liability forces software companies to think twice before changing something. Liability forces companies to protect the data they’re entrusted with. Liability means that those in the best position to fix the problem are actually responsible for the problem.

Information security isn’t a technological problem. It’s an economics problem. And the way to improve information technology is to fix the economics problem. Do that, and everything else will follow.

This essay originally appeared in Computerworld.

An interesting rebuttal of this piece is here.

Posted on November 3, 2004 at 3:00 PM • View Comments

Computer Security and Liability

The problem is that all the money we spend isn’t fixing the problem. We’re paying, but we still end up with insecurities.

And that’s the problem. We’re not paying to improve the security of the underlying software. We’re paying to deal with the problem rather than to fix it.

The only way to fix this problem is for vendors to fix their software, and they won’t do it until it’s in their financial best interests to do so.

Basically, we have to tweak the risk equation so the CEO cares about actually fixing the problem, and putting pressure on his balance sheet is the best way to do that.

This essay originally appeared in Computerworld.

An interesting rebuttal of this piece is here.

Posted on November 3, 2004 at 3:00 PM • View Comments

Security Information Management Systems (SIMS)

The computer security industry is guilty of overhyping and underdelivering. Again and again, it tells customers that they must buy a certain product to be secure. Again and again, they buy the products—and are still insecure.

Firewalls didn’t keep out network attackers—in fact, the notion of “perimeter” is severely flawed. Intrusion detection systems (IDSs) didn’t keep networks safe, and worms and viruses do considerably damage despite the prevalence of antivirus products. It’s in this context that I want to evaluate Security Information Management Systems, or SIMS, which promise to solve a serious network problem: log analysis.

Computer logs are a goldmine of security information, containing not just IDS alerts, but messages from firewalls, servers, applications, and other network devices. Your network produces megabytes of these logs every day, and hidden in them are attack footprints. The trick is finding and reacting to them fast enough.

Analyzing log messages can determine how the attacker broke in, what he accessed, whether any backdoors were added, and so on. The idea behind log analysis is that if you can read the log messages in real time, you can figure out what the attacker is doing. And if you can respond fast enough, you can kick him out before he does damage. It’s security detection and response. Log analysis works, whether or not you use SIMS.

Even better, it works against a wide variety of risks. Unlike point solutions, security monitoring is general. Log analysis can detect attackers regardless of their tactics.

But SIMS don’t live up to the hype, because they’re missing the essential ingredient that so many other computer security products lack: human intelligence. Firewalls often fail because they’re configured and maintained improperly. IDSs are often useless because there’s no one to respond to their alerts—or to separate the real attacks from the false alarms. SIMS have the same problem: unless there’s a human expert monitoring them, they’re not defending anything. The tools are only as effective as the people using them.

SIMS require vigilance: attacks can happen at any time of the day and any day of the year. Consequently, staffing requires five fulltime employees; more, if you include supervisors and backup personnel with more specialized skills. Even if an organization could find the budget for all of these people, it would be very difficult to hire them in today’s job market. And attacks against a single organization don’t happen often enough to keep a team of this caliber engaged and interested.

Back in 1999, I founded Counterpane Internet Security; we sell an outsourced service called Managed Security Monitory, in which trained security analysts monitor IDS alerts and log messages. Because of the information our analysts received from the network—in real time—as well as their training and expertise, the analysts could detect attacks in progress and provide customers with a level of security they were incapable of achieving otherwise.

When building the Counterpane monitoring service in 1999, we examined log-monitoring appliances from companies like Intellitactics and e-Security. Back then, they weren’t anywhere near good enough for us to use, so we developed our own proprietary system. Today, because of the caliber of the human analysts who use the Counterpane system, it’s much better than any commercial SIMS. We were able to design it with our expert detection-and-response analysts in mind, and not the general sysadmin market.

The key to network security is people, not products. Piling more security products, such as SIMS, only our network won’t help. This is why I believe that network security will eventually be outsourced. There’s no other cost-effective way to reliably get the experts you need, and therefore no other cost-effective way to reliably get security.

This originally appeared in the September/October 2004 issue of IEEE Security and Privacy Magazine.

Posted on October 20, 2004 at 6:03 PM • View Comments

Schneier: Security outsourcing widespread by 2010

Bruce Schneier is founder and chief technology officer of Mountain View, Calif.-based MSSP Counterpane Internet Security Inc. and author of Applied Cryptography, Secrets and Lies, and Beyond Fear. He also publishes Crypto-Gram, a free monthly newsletter, and writes op-ed pieces for various publications. Schneier spoke to SearchSecurity.com about the latest threats, Microsoft’s ongoing security struggles and other topics in a two-part interview that took place by e-mail and phone last week. In this installment, he talks about the safety of open source vs. closed source, the future of security management and spread of blogs.

Are open source products more secure than closed source?

Schneier: It’s more complicated than that. To analyze the security of a software product you need to have software security experts analyze the code. You can do that in the closed-source model by hiring them, or you can do that in the open-source model by making the code public and hoping that they do so for free. Both work, but obviously the latter is cheaper. It’s also not guaranteed. There’s lots of open-source software out there that no one has analyzed and is no more secure than all the closed-source products that no one has analyzed. But then there are things like Linux, Apache or OpenBSD that get a lot of analysis. When open-source code is properly analyzed, there’s nothing better. But just putting the code out in public is no guarantee.

A recent Yankee Group report said enterprises will outsource 90% of their security management by 2010; that more businesses have made security a priority to meet growing threats and comply with laws like HIPAA and Sarbanes-Oxley. Do you agree?

Schneier: I think that network security will largely be outsourced by 2010 regardless of compliance issues. It’s infrastructure, and infrastructure is always outsourced … eventually. I say eventually because it often takes years for companies to come to terms with it. But Internet security is no different than tax preparation, legal services, food services, cleaning services or phone service. It will be outsourced. I do believe that the various compliance issues, like the laws you mention, are causing companies to increase their security budgets. It’s the same economic driver that I talked about in your question about Microsoft. By increasing the penalties to companies if they don’t have adequate security, the laws induce companies to spend more on security. That’s good for everyone.

How is Crypto-Gram doing?

Schneier: Crypto-Gram currently has about 100,000 readers; 75,000 get it in e-mail every month and another 25,000 read it on the Web. When I started it in 1998, I had no idea it would get this big. I actually thought about charging for it, which would have been a colossal mistake. I think the key to Crypto-Gram’s success is that it’s both interesting and honest. Security is an amazingly rich topic, and there are always things in the news to talk about. Last month I talked about airline security, the Olympics and cellphones. This month I’m going to talk about academic freedom, the security of elections, and RFID chips in passports.

Some people compare Crypto-Gram to a blog. Is that a reasonable comparison?

Schneier: It’s reasonable in the sense that it’s one person writing on topics that interests him. But the form-factor is different. Blogs are Web-based journals, updated regularly. Crypto-Gram is a monthly e-mail newsletter. Sometimes I wish I had the immediacy of a blog, but I like the discipline of a regular publishing schedule. And I think I have more readers because I push the content to my readers’ e-mail boxes.

Do you think blogs have become more useful than traditional media as a way to get the latest security news to IT managers?

Schneier: Blogs are faster, but they’re unfiltered. They’re definitely the fastest way to get the latest news—on security or any other topic—as long as you’re not too concerned about accuracy. Traditional news sources are slower, but there’s higher quality. So they’re both useful, as long as you understand their relative strengths and weaknesses.

By Bill Brenner, News Writer
05 Oct 2004 | SearchSecurity.com

Posted on October 8, 2004 at 4:52 PM • View Comments

Keeping Network Outages Secret

There’s considerable confusion between the concept of secrecy and the concept of security, and it is causing a lot of bad security and some surprising political arguments. Secrecy is not the same as security, and most of the time secrecy contributes to a false feeling of security instead of to real security.

In June, the U.S. Department of Homeland Security urged regulators to keep network outage information secret. The Federal Communications Commission already requires telephone companies to report large disruptions of telephone service, and wants to extend that requirement to high-speed data lines and wireless networks. But the DHS fears that such information would give cyberterrorists a “virtual road map” to target critical infrastructures.

This sounds like the “full disclosure” debate all over again. Is publishing computer and network vulnerability information a good idea, or does it just help the hackers? It arises again and again, as malware takes advantage of software vulnerabilities after they’ve been made public.

The argument that secrecy is good for security is naive, and always worth rebutting. Secrecy is only beneficial to security in limited circumstances, and certainly not with respect to vulnerability or reliability information. Secrets are fragile; once they’re lost they’re lost forever. Security that relies on secrecy is also fragile; once secrecy is lost there’s no way to recover security. Trying to base security on secrecy is just plain bad design.

Cryptography is based on secrets—keys—but look at all the work that goes into making them effective. Keys are short and easy to transfer. They’re easy to update and change. And the key is the only secret component of a cryptographic system. Cryptographic algorithms make terrible secrets, which is why one of cryptography’s most basic principles is to assume that the algorithm is public.

That’s the other fallacy with the secrecy argument: the assumption that secrecy works. Do we really think that the physical weak points of networks are such a mystery to the bad guys? Do we really think that the hacker underground never discovers vulnerabilities?

Proponents of secrecy ignore the security value of openness: public scrutiny is the only reliable way to improve security. Before software bugs were routinely published, software companies routinely denied their existence and wouldn’t bother fixing them, believing in the security of secrecy. And because customers didn’t know any better, they bought these systems, believing them to be secure. If we return to a practice of keeping software bugs secret, we’ll have vulnerabilities known to a few in the security community and to much of the hacker underground.

Secrecy prevents people from assessing their own risks.

Public reporting of network outages forces telephone companies to improve their service. It allows consumers to compare the reliability of different companies, and to choose one that best serves their needs. Without public disclosure, companies could hide their reliability performance from the public.

Just look at who supports secrecy. Software vendors such as Microsoft want very much to keep vulnerability information secret. The Department of Homeland Security’s recommendations were loudly echoed by the phone companies. It’s the interests of these companies that are served by secrecy, not the interests of consumers, citizens, or society.

In the post-9/11 world, we’re seeing this clash of secrecy versus openness everywhere. The U.S. government is trying to keep details of many anti-terrorism countermeasures—and even routine government operations—secret. Information about the infrastructure of plants and government buildings is secret. Profiling information used to flag certain airline passengers is secret. The standards for the Department of Homeland Security’s color-coded terrorism threat levels are secret. Even information about government operations without any terrorism connections is being kept secret.

This keeps terrorists in the dark, especially “dumb” terrorists who might not be able to figure out these vulnerabilities on their own. But at the same time, the citizenry—to whom the government is ultimately accountable—is not allowed to evaluate the countermeasures, or comment on their efficacy. Security can’t improve because there’s no public debate or public education.

Recent studies have shown that most water, power, gas, telephone, data, transportation, and distribution systems are scale-free networks. This means they always have highly connected hubs. Attackers know this intuitively and go after the hubs. Defenders are beginning to learn how to harden the hubs and provide redundancy among them. Trying to keep it a secret that a network has hubs is futile. Better to identify and protect them.

We’re all safer when we have the information we need to exert market pressure on vendors to improve security. We would all be less secure if software vendors didn’t make their security vulnerabilities public, and if telephone companies didn’t have to report network outages. And when government operates without accountability, that serves the security interests of the government, not of the people.

Security Focus article
CNN article

Another version of this essay appeared in the October Communications of the ACM.

Posted on October 1, 2004 at 9:36 PM • View Comments