Tag Archives: breach

Closing the Barn Door – Software Security

All the ways that hackers can get in
All the ways that hackers can get in
In the second part of my series on what we can do to contain and combat the recent rash of security breaches I’d like to focus the software development side. I’m going to layout some of the reasons why we’ve got such vulnerable software today and what we can do about it. Part one of this series discussed things you can do personally as a consumer to better protect yourself.

Let’s start with some of the most common reasons why we aren’t getting secure software. Here’s the short-list in no particular order:

  • Training
  • Security mindset
  • Not required
  • Test-it-in mentality

The list is actually very intertwined, but I’ll try to separate these issues out the best I can. I’m focusing primarily on software security, rather than network or physical. They’re just as important, but we seem to be doing a better job there than in the code itself.

It seems obvious that training is critical, but in the software business nothing can be taken for granted. I’ll talk more about the myth of “software engineering” in the near future, but for now just remember that software is NOT engineering, not at most organizations. Sure, there are plenty of engineers who write software, but their engineering credentials are not for software development, and somehow they leave sound engineering practices at the door when they come to work.

Developers need to be trained in security. This means they need to understand the role of prevention by avoiding unsafe constructs and practices. They need to be able to spot ways in which their code can be vulnerable. They need to be more paranoid than they currently are. They need to know what standards and tools are out there and how to make the best use of them.

Recently I was at AppSec in Denver and had a discussion with a developer at a security company about input validation. Sadly, he was arguing that certain parts of the application were safe, because he personally hadn’t thought of a way to attack them. We MUST move past this kind of thinking, and training is where it starts.

You can’t do what you don’t know how to do.

Security mindset
When developers write code, they often don’t think at all about security. In the security mindset we think “How safe is this?” and “How could this be attacked?” and “What happens when things go wrong?”

Being good at software security requires a lot of expertise. Great security comes with input from database experts, networking experts, sysadmins, developers, and every other piece of the application ecosystem. As each talks about the attack surfaces they understand, the developers gain valuable information about how to secure their code.

A great resource for learning about common weaknesses and their consequences is CWE. Many have heard of the “CWE/SANS Top 25” coding standard, which is the 25 most dangerous issues out of about 800 that they have currently listed. These items help us get in the security mindset because they list weaknesses in terms of technical impact meaning what bad thing can happen to me if I leave this weakness in the code. Technical impact includes things like unwanted code execution, data exposure and denial-of-service.

Each CWE items lays out clearly why you need to worry about it. When someone tells me they don’t think a particular weakness in their code matters, I usually have them Google the name of the error like “Uncaught exception” and “CWE” and then go to the relevant CWE to show them how dangerous it can be. This is “Scared Straight” for programmers.

Thinking about security leads to secure code.

Not required
The lack of a security mindset comes from not having security as a serious requirement, or even not a requirement at all. We have to start making security part of the standard requirements for all software, and measuring it in a consistent meaningful way.

There are those who say that security isn’t a quality issue, but they’re wrong. I see their point, that security requires specialized thinking and training, but in the end it is absolutely a quality issue. If When you get hacked the first thing in peoples mind is that you’ve got poor quality.

A great thing to do is add software security requirements to your development plan. That way everyone knows what to do, and expects that it will be scheduled properly and tested. If you’ve never done security before add 3 simple requirements:

  • Secure coding standard such as CWE Top 25 or OWASP Top 10
  • Security peer code review
  • Security testing such as penetration testing

It won’t cover everything and it won’t be perfect, but it’ll get you started on a very solid foundation.

You get what you ask for. Ask for security.

Test-it-in mentality
Testing is important, in fact it’s critical. But we have learned for over 50 years that testing does not improve quality, it simply measures it. The old adage “You can’t test quality into a product” is equally true for software security, namely “You can’t test security into a product”.

When you’re trying to improve something like quality or security (remember, security is a quality issue) you have to make sure that you being at the beginning. Quality and security must pervade the development process. It may seem old at this point, but Deming’s 14 points is still chock full of useful effective advice. Especially point 3:

Cease dependence on inspection to achieve quality [security]. Eliminate the need for inspection on a mass basis by building quality [security] into the product in the first place.

All too often organizations are creating a security group (good idea) and only empowering them to test at the end of the cycle (bad idea). If you want your security group to be effective, they’ve got to get at the root causes behind the vulnerabilities in your software. When they find something during testing, chase it upstream, eliminate the root cause, and then eliminate all other instances of the same problem, rather than just the one you were lucky enough to find during testing.

Testing alone will not secure your software. On ounce of prevention is worth a pound of cure.

Practical suggestions

  1. Remember to focus both internally as well as externally. Many of the current breaches are a hybrid of security and physical access. This is the hacker’s holy grail.
  2. Follow basic well-known security practices. If they’re not well-known to you, then start with training.
    • Control physical access
    • Train and monitor for social engineering, because it still works way too often. Just try it on your own people using a friend and see how far she can get.
    • Never ever use default passwords. Always reset anything you buy or install. If a vendor did it for you, check their work. I know of a cable provider that uses a template based on customers addresses. Probably most of their customers don’t realize their network is essentially wide-open.
    • Encrypt private data. These days you have to figure that data is going to get out at some point, so just encrypt anything you wouldn’t want to share. Passwords yes, but also email address, social security numbers, etc.
    • Monitor for suspicious traffic and data access. Many attacks you don’t hear about are stopped this way, because someone noticed something funny going on. In some of the recent breaches monitoring was reporting bad behavior for weeks or months but no one paid attention. One organization said “We sell hammers” when told about suspicious behavior.
  3. We must move to a more proactive approach. The current trend in static analysis is to find bugs and indeed many of the leading vendors have very fancy flavor-of-the-week approaches, (called signatures) which puts their software into the position of the same old, reactive, too-late problems of anti-virus. We must start building software that isn’t susceptible.

To be proactive, we have to train people in proper tools, processes, and techniques. Then formalize the use of that training in policies. Policies that include security best practices, requirements, and testing.

In static analysis we need to supplement the bug-finding with more preventative rules such as strict input validation rather than chasing potential tainted data. All data sources, even your own database, should be validated because otherwise what a great way to lay an easter egg. (Remember that security paranoid mindset from before?) Use prepared statements and strong validation and you can avoid getting yourself into the SQL Injection Hall of Shame.

We need to start looking for root problems rather than exploits. Take the Heartbleed problem. Despite claims to the contrary, the underlying issues were available from any serious static analysis tool that takes a preventative approach. What we didn’t have was a flavor-of-the-month static analysis rule that looked for the particular implementation. All we had was a root-cause best-practice rule not being used.

Root cause should have been enough. Weak code is weak code, whether or not we have a current exploit, which is all that the “signature” approach to security provides. The time it takes to find exploits and check their validity is not only nearly impossible from a coverage perspective (Just have a talk with Richard Bender if you don’t believe me) but is certainly more than the time to build hardened software.

That’s right, it’s both faster and easier to just code to a strict safe coding standard than it is to try and figure out that your code is safe, or chase defects from a weak unsafe application. Stop chasing bugs and work to build security in instead. Get yourself a good static analysis tool (Or use the SWAMP) and a copy of CWE and get started.

PC Security Software

Book Resources

Put Your Money Under Your Mattress – Tips for Security

Money Stuffed in Between the Mattresses

The rash of security breaches continues unabated, especially in the retail sector. It’s getting to the point where I feel like just pulling my money out of the bank and putting it under my mattress. I had slowly transitioned to using my ATM for all my daily purchases and now I’m back to carrying more cash.

To highlight just a few recent events:

Kmart has a blue light special on malware

Why the Home Depot breach is worse than you think

Chase warns customers about massive data breach

Staples is investigating a possible data breach

If you go back even a year the list is waaaay too long. ATM hacks abound (Did you know most of them still run Windows 95?!) Gas pump card readers have been compromised for years.

I used to worry more about using a credit card at a small retailer because of the potential for employees to steal your data and use/share/sell it. Now with big software hacks in play, little guys aren’t profitable targets. Why compromise a store with hundreds of customers when you can nail a chain with millions?

In all this paranoia what can you really do about it. I’ve put together a short list of actionable things anyone can do. In a follow-up article shortly I’ll talk more about what the industry can and should be doing.

For consumers the list includes many things that don’t have anything to do with your computers.

  1. Use more cash. The software that is being used in these breaches is just to cheap, readily available, and easy to use. Expect to continue hearing about major breaches, and eventually more minor ones as well. Trickle-down hacking.
  2. Don’t pay at the pump. I know, this is a pain, but seriously this is the one I hear about the most from real people I actually know who have been affected. It was the card reader at the pump. So pay inside, and don’t forget, most stations are part of large organizations, making them tempting targets for the same POS attacks we keep hearing about. Use cash for gas. Or drive an electric, like I do.
  3. Don’t pay at suspicious places. Well I guess I don’t mean dine-and-dash, but don’t pay at credit cards at places that you’re unsure of. Look around and ask yourself if you’d leave your wallet or phone on the table unattended while using the restroom. If not, pay in cash.
  4. Big retailers are at least as unsafe as small ones. Hacks are happening just as often at big reputable places because it’s simply more profitable. More customers = more cards. It’s simple economics. So pay cash when you can, and keep track of announcements from retailers you use, including silly looking envelopes in the mail that look like junk mail. They could be security alerts.
  5. Don’t click links in unsolicited email. This is a corollary to above – be extremely careful clicking on email alerts about password updates, account info, etc. Phishing is too easy and too common. When in doubt, either put the URL in by hand (always a good idea) or get on the old-fashioned phone and actually call: Did you guys just email a security alert? The time you spend on hold (you know you will) is better than getting hacked.
  6. Use good passwords. I’ll be writing more about this at some point, but for now remember that longer is better. I’m shocked that some organizations still don’t allow really good passwords. In terms of complication longer is often more important and secure than the old adage of numbers, letters, and special characters. But the bigger the better. If your password is 8 characters, even with all of the above, it’s hackable, nearly instantly. Just remember that.
  7. Change passwords when a hack occurs. Even if you don’t get a notice from the company, just change it. If for example you heard about Staples today and are sitting around waiting for an email or letter, remember that the hackers aren’t waiting, in fact they may have had your data for weeks or even months. Just change your password now. This is a great case of better safe than sorry.
  8. Use a password manager You need something to manage all your passwords and other important secure data, otherwise you’ll never do steps 5 and 6 above as you should. There are quite a few good ones out there. Just make sure it’s got good encryption, comes from a reputable company, and supports ALL of the platforms you need so that you’ll use it. A few off the top of my head are Lastpass, 1Password, and Msecure. Some of them even support a USB dongle to make sure that your password manager data is secure.
  9. Use two-step authentication. This is a configuration option you can get from Microsoft, Apple, Google, etc. where they send a text message to your phone when you try to login. Sometimes they also have an authenticator app instead of the text message, which is nice because you don’t need a data connection like you would with a text message. Google announced security key support today, which is a USB device you put on your keychain instead of a text to your phone.
  10. Keep software up-to-date. This is especially important for both your operating system and your browsers. Major PC OS vendors like Microsoft and Apple issue regular security updates once a week or month. Phone vendors like Google do likewise, although updates depend greatly on both your phone manufacturer and your service provider. I know, it’s crazy, but it’s true. Android phones are frequently out of date and cannot be updated for no good reason. This is on advantage of an Apple or Nexus device – frequent OS updates. Watch Adobe too – that flash engine is a common attack surface.
  11. Get rid of old hardware that can’t be updated. Old phones, old computers running insecure operating systems, etc. It’s all more dangerous than it’s worth. How old – simple, if it isn’t supported with regular security updates, it’s time to junk it. I know you think you’re saving money, but the cost of a hack is bigger, not to mention the time you spend keeping old hardware running. And yes, there are all kinds of tech geeks that can keep stuff running forever. That’s fine as long as they’ve made sure it’s secure. When in doubt, throw it out. (Like in politics.)
  12. Avoid websites that don’t support secure connections. This means look for “https” instead of just “http” in the URL. Plus depending on your browser you should see some kind of lock that indicates a secure connection. Facebook had this problem for way too long, and what it means is that although you need a password to login, your password is sent over the internet unencrypted, just waiting for that pimply kid across the table at Starbucks to steal it. For a list of sites that you’d think are secure but aren’t, check the HTTP Shaming blog.
  13. Use a prepaid credit card for internet purchases. Come to think of it, that’s not a bad idea for gas pumps and restaurants either. You can get a “credit card” that you can reload at any grocery or convenience store. T-mobile has one that is particularly nice because it has no reload or monthly fees. The prepaid card severely limits your exposure in a breach, and it’s easy for you to walk away from by just getting a new one. They can’t take more out of it than you have sitting on it.

If you’ve got more tips, let me know and I’ll add them to the list. In the meantime, keep safe.