Author interview: Steven Bellovin on Thinking Security

Share

In the face of relentless security attacks, is it possible to keep systems, data, and networks protected? Yes, says respected security expert Steven Bellovin, but it requires more than a static checklist of standard security measures. It requires looking ahead of current technology to anticipate vulnerabilities and understand how and why they exist; only then is it possible to identify the most effective defense mechanism and guard against new attacks. To help security specialists and other IT professionals foster a security mindset, Bellovin in his latest book, Thinking Security: Stopping Next Year’s Hackers, describes fundamental security principles that are true no matter the computing environment or how much technology changes. It’s a pragmatic approach that presents security as a systems issue while considering cost, the value of the assets being protected, the actual threat, and employees’ need to be productive.

bellovin-200x200
Steven Bellovin (Photo credit Eileen Barroso)

Why did you write Thinking Security?

Dissatisfaction with how security is practiced in the real world. Security today tends to rely on checklists based on yesterday’s technology and yesterday’s threats. Checklists can’t cover every situation, and they can’t anticipate new types of attacks.

After years of seeing misleading and simplistic security recommendations in the mainstream press, I started thinking about underlying principles and what security advice is always going to be the same no matter what happens in technology; it’s the way I try to get my students to think about security. All those things together went into the book.

What is an example of misleading security advice?

That a strong password will protect you. The rules on picking strong passwords go back to a paper in 1979, so this is not new technology and there are ways to bypass strong passwords. Keystroke loggers and phishing attacks, for example, don’t care how strong your password is.

The underlying vulnerability here is the reuse that occurs when you’re sending something to one site that can be stolen from that site and reused against you. In RSA SecurID—generally considered very secure—a cryptographic secret is embedded in the token but a server somewhere has a copy of that secret. Anyone hacking into that server can impersonate the file of tokens kept there. Some will say, Lock down the server. If you can lock down the server, why can’t you lock down your password file? Why is that server more secure than a password file? It’s not.

A one-time password if done right is secure, not because it is hard to guess, but because it can’t be reused.

Your most valuable password is your email account password, because that’s used for all the password resets. Anyone having your email password can potentially learn any password emailed to you, no matter how strong the password.

Passwords are ubiquitous. Can they be used safely?

I use and recommend password managers, though there are some bad designs out there. The book discusses the characteristics that make for a good password manager.

Thinking Security is written for network and security administrators, but some security advice applies to everybody.

Use a password manager to securely store a different credential for every site and avoid reuse of keys.

Look for password managers that encrypt URLs and that add “salt” (a random string of data) to each password to add an extra layer of protection.

Though web access to a password collection is convenient, it is also more dangerous, especially when using potentially insecure machines.

One nice feature is the ability to copy a password to the clipboard for easy pasting into web forms; however, check that the clipboard gets automatically cleared.

The more integrated the manager is with a browser, the more risk there is that malware can abuse it to steal your credentials.

If your bank offers an online access to your account, use it. By regularly logging in, you’ll detect fraudulent activity more quickly.

Use a credit card rather than a debit card when making purchases, especially when you don’t completely trust a site. US law limits cardholders to $50 liability in the case of unauthorized card use. (For debit cards, which are covered under a different law, you’re liable for up to $50 if you report within two days; after two days, you’re liable for up to $500. After 60 days, you’re liable for the entire stolen amount.)

Debit cards have the added risk of being a direct line into your bank account.

If checklists are too static to be useful, how should people go about ensuring their systems are secure?

It starts with two fundamental questions: what are you protecting, and against whom are you protecting it.

If you don’t answer those questions, you’re doing security just to do security, forgetting that the purpose of security is not to increase security, but to prevent loss.

Defenses have to be matched to the likely attacks. If you’re protecting a single database accessed only by employees, a firewall will probably suffice. However, if it’s 17 databases all tied together and made to function as a single resource while also needing to be accessible by those inside and outside the company, a firewall is not going to work.

Nor will a firewall protect you from an attack launched from inside. Even employees might work against a firewall if it prevents them from getting their work done.

People might be surprised to see you say firewalls may not provide needed security. You and William Cheswick wrote the first book on firewalls (Firewalls and Internet Security: Repelling the Wily Hacker).

That book was written in 1994. Networks and systems are more complicated and interconnected these days. From a security perspective, complexity is fatal.
Firewalls work well when there is a clear distinction between the inside and outside of what you’re protecting. Today it’s not always clear-cut. Companies often make their databases and parts of their network accessible to outside contractors, vendors, or auditors. In such cases, a firewall is not appropriate, but not having a firewall creates vulnerabilities that can be exploited.

Which is what happened in the breach at Target. Attackers obtained the network credentials used by Target’s HVAC vendor, which had external access to Target’s network. Once inside, hackers were able to move freely over Target’s network, which from all accounts was rather loosely structured with little segmentation. Internal firewalls should have been used to cordon off sensitive parts of the network, like the payment system, which is how the attackers were ultimately able to steal credit card information.

Legacy systems are a problem; an internal network might have started off simple but just then grew, with security put in this one spot here and another spot over there, but never with any overarching vision of how it should be done; before too long it’s too late to do a coordinated plan.

The Target breach was one of many big ones in the last couple of years. Federal agencies were attacked multiple times, Home Depot, Anthem Health, even Chase. Attackers seem to be always one step ahead . . .

. . . mostly, but not completely. We don’t hear about the attacks that get repulsed.

With all the risks, would you recommend people not use online banking?

No. And I’ll tell you why. As a matter of practice, banks don’t hold customers liable for money hacked from their bank accounts because the next bank down the street won’t. It’s the competitive landscape.

Merchants and businesses, however, are generally liable. A customer is not. There are a lot of things I will do if I’m not liable.

Many things come down to economics, and security is one of them.

That is one of the main themes in the book.

Yes, security costs money. Companies have to spend resources, understand the need, and they have to be willing to accept inconvenience in order to protect themselves. If it takes two signatures to fully protect something, do the extra bit of work to get two signatures.

But companies are under other pressures. Online vendors need to make their sites easy to use for customers.

Amazon for instance generally does make you go through the extra step of inputting the 3- or 4-digit card security code that other sites require because Amazon has made one-click ordering a business priority to make it easy as possible for people to buy things. Less secure verification will incur some loss, but Amazon is willing to eat those losses, figuring net profit is greater than the loss if it’s easy for people to buy.

Insecurity is not a state of sin; it’s part of running a business and business can be risky.

Are you optimistic people can secure sites and data?

Yes and no. The biggest cause of security problems is buggy code. This is not a new thought of mine. It was true 20 years ago, and though code is better written today, programs are bigger and more complex. It’s hard to imagine what a defense against buggy code would look like.

Any system must also be periodically re-evaluated for vulnerabilities, something that rarely happens.

When I came to Columbia ten years ago, sandboxing was known to have good properties, but it was not then in general use. Today it’s a mainstream part of all operating systems.

Digital rights management has also been more successful at protecting proprietary content than I thought it would be. It works because most of the content that people were pirating can now be bought at reasonable prices online.

From a technological perspective, digital rights management doesn’t seem to be something that should work, but it works from an economic perspective. Not perfectly, of course, but good enough.

I’m morally certain that right now someone in Silicon Valley or Tel Aviv or Hyderabad or Beijing or Accra or somewhere is devising something that 10 years from now, we’ll find indispensable, but will have as profound an effect on security as today’s smartphones have had on communications and society. We just don’t know what it is yet.

 

Posted: 2/25/2016
Photo credit: Eileen Barroso
Linda Crane

 

Share