Towards More Secure Software
So I was just reading about a vulnerability found with the BlackBerry Internet Server, and started thinking about the general state of software security.I often bemoan the state of the art in computer security. Rather than being a highly "scientific" field where solutions are found simply by cranking through a few formula, it's really more of an "art". Don't get me wrong, there are plenty of places where you have simple answers to simple questions. But anytime you get something more than a Commodore 64 connecting to BBS over a 1200 baud modem, thing get complicated quickly. And rather than formulas to drive us to mathematically verifiable solutions, we get rules of thumb that are applied (often incorrectly.)
When developing commercial products, security frequently gets short shrift because it's very easy for project managers to look at the schedule and say, "uh... guys... we've got to release something in less than a month... why don't you just wait until later to implement all this security stuff?" And then the marketing and business development guys chime in to say, "hey! we could make security a third-party opportunity! we could turn our product into a platform where we get a secondary revenue stream by selling developer tools!" On the off chance that engineering is given any time to implement anything more than baseline security features, you often hear from QA or the User Experience group saying something like... "uh... what's all this security stuff? why do I need to always change my password when I first pull the product out of the box? Isn't that going to confuse the user?"
When engineering groups respond to such questions, we frequently are left explaining things in vague generalities... "uh... this idea violates the concept of defense in depth," or "yeah... we could cut this corner but it would violate the principle of least privilege." Management gets involved to try to resolve the scheduling issue and you often find people in charge wondering why am I risking a schedule slip to prevent violating an abstract rule of thumb when no-one can show me how violating this principle leads to a practical attack?
Project managers, salespeople, marketing professionals and CEO's are rewarded when products ship. If the product isn't shipped, there's no reward. If you manage a group that frequently doesn't ship products, then you wind up getting penalized (usually with a bad reputation around town or by not getting a raise the next time performance reviews happen.) Engineering security people generally aren't singled out for reward when a product ships. At enlightened development shops, they're added to the engineering team and share the team's rewards for shipping, but you rarely hear people talk about the heroic efforts of the security team that led to such and such a product being released on time and under budget. What you do hear about is what happens when a vulnerability is discovered.
Often what happens is you hear some quiet rumblings on the Bugtraq mailing list or in the forums of various hacker websites. Or maybe you read about critical vulnerabilities announced at computer security conventions ( like the Sklyarov / Adobe / Def Con Controversy and the Lynn / Cisco / BlackHat Controversy.) News of a vulnerability eventually seeps out to IT managers who start getting nervous. CEOs start asking CIOs if their systems are secure; many nervous phone calls are made to product reps and sales people. On good days patches are released before the system cracker community learns about the vulnerability.
In an ideal world software would be shipped without security vulnerabilities. Software companies would have time during development to consider all potential security flaws; not only in their software, but also in other packages used with their software. The holes would be fixed prior to shipping; everyone would be happy.
But the interesting thing about the software marketplace is that customers are willing to accept a small amount of risk to get features implemented faster; they're also willing to accept a lower degree of overall quality as long as the package does "just enough" to provide value. For instance, I use blogger.com to manage my blog for me. I have friends that frequently tell me I should be using WordPress or even Joomla to manage my blog. They are both clearly technically superior, but come with an added administrative burden. Simply put managing my blog via blogger.com provides me "just enough" capability with a minimum of administration.
I'll leave it as an exercise for the reader to ponder this concept with respect to software from a very large software organization in Redmond.
So we have a world where the underlying reality is consumers want new features as fast as they can get them. Apart from new features being fun, they're seen to provide incremental value either by increasing organizational efficiency or allowing people or organizations to do things they couldn't do without them. Software engineering organizations are pressured to implement new features as quickly as possible and with the minimum resources necessary to enhance an organization's return on investment. More features in new versions made with fewer resources being sold more often is music to the ears of Silicon Valley entrepreneurs. Engineering security developers working to add new security features or to enhance the security of non-security features tend to have a limited picture of how a particular piece of software will be integrated into a system delivered to an end user ( this is one of the reasons why "Security is Hard". ) Without a specific vulnerability in the code-base, it's very difficult to sell the idea that a product's release date should be pushed back to work on security or general quality aspects.
What we get from this is a stream of products with unidentifiable levels of quality and security.
On good days security researchers who discover vulnerabilities are "white hats." Classic hackers who put their talents to use for good, not evil. In the ideal world when a "White Hat Hacker" finds a vulnerability, they warn the developer of the vulnerable product, frequently including an exploit to demonstrate the problem. They give the developer time to develop and distribute a patch, and then go public with the vulnerability report.
In the old days there was a lot of controversy between software developers and security researchers (and plain 'ol hackers who simply enjoy taking things apart.) Commercial software developers didn't like the way frequent vulnerability reports made them look. The simplest way to approach this problem, they thought, was simply to shoot the messenger. The Sklyarov Controversy from several years back was the most perverse example of this line of thought. Eventually both communities (the white-hat security researchers and the software developers) realized they could co-exist and that's why you frequently find public disclosure of a security flaw immediately after the affected company releases a security patch to eliminate the vulnerability.
It's not a perfect system, but it seems to work well... until you're the victim of a security exploit and unknown attackers have made off with sensitive information. If you want to talk about having egg on your face, just take a look at the list of people who have been forced by the California Security Breach Information Act to tell their customers they weren't able to properly care for the security of sensitive information placed in their care.
If it were only the case that credit card numbers were being stolen, we might be able to say "it's not so big of a deal." Credit cards in the US come with caps on liability for fraud. Often the credit card companies will waive even that small liability. But we're seeing more than just credit card number stolen. A recent story in the Washington Post informs us that Marriott failed to properly protect Social Security Numbers for close to 206,000 members of the Marriott Vacation Club International. Can anyone say Identity Theft?
We're at an inflection point in the adoption curve of online technologies. Some people I know have stopped purchasing things online or providing sensitive information to online services. This is the first activity in what I suspect will be the "technology disownment curve." There's no clear metric to define the risks from using online services that require you to enter sensitive information. There's no security equivalent to Google's Page Rank algorithm. A lot of online vendors will point to their use of SSL as proof of their commitment to security. But I hate to tell you... SSL is just the beginning of web application security. It's the easy part. You still have to worry about Cross Site Scripting, SQL Injection and privilege escalation. The mobile phone industry has only recently started taking baby-steps into the world of wireless data access. In Japan, the EDY project allows mobile phone subscribers to use their phones as cash-cards. How long before this gets hacked? There's no indication that mobile phones are especially vulnerable, but I can tell you from personal experience it's been a long, uphill road advocating for enhanced security solutions for mobile phone handsets. (Let me say, however, that my employer, PalmSource, takes it pretty serious... that's one of the reasons I'm working there.)
Some people have suggested we'll start seeing more attention to security when software vendors are held to a higher degree of liability. I would agree with this, but I don't see it happening anytime soon. There are non-negligible costs associated with pumping up the quality and security of commercial software, and these costs are going to be passed on to the end user. Before we have something like this, we must know what the effect of enhanced security is on people's buying behavior.
And I've got to say... the state of the art is pretty abysmal. Microsoft's much ballyhooed "security stand-down" a couple years ago did nothing to eliminate security vulnerabilities in their products. As I write this, Windows users world-wide are scrambling to figure out what to do about the WMF Vulnerability. The problem is so acute, some people aren't waiting on Microsoft to deliver patches but are instead getting them from third parties.
So here's my two cents.
We all agree that secure software is a good thing, but no one wants to pay for it. We have no objective measure for what is secure and what is not secure. There are few easily quantifiable penalties for shipping insecure software, and I'm not entirely convinced that software can be made especially secure without detailed knowledge of the environment in which it will run. Every day we build larger and more flexible software systems, layering component on component, increasing the vulnerability signature of common systems. Work on "formal methods" for testing software security continues, but few researchers are tackling the problems of validating the security of common development environments from Microsoft, Borland, Oracle or Sun. And in the end, validating the security of software outside the context of the environment in which it runs may end up being a fools errand.
What can we do to enhance the security and quality of our software?
First off... as a consumer, demand better. Every now and again refuse to buy the latest version of Microsoft Office or Oracle Financials or even Adobe Acrobat unless the vendor has a "security story" that isn't pure BS. Refuse to buy a new mobile phone unless your carrier can tell you how it won't leak your AIM account information. Read up about information security and don't let salespeople get away with repeating unfounded BS about product security.
As a software developer, read more about how vulnerabilities creep into systems. There are several good books about designing and implementing secure software. Read them.
As a manager of a software development project, establish base quality and security objectives. If you don't know how to do this, find out.
As a researcher, develop metrics to evaluate quality, robustness, and resistance to attack of software and systems.
As an industry, we're going to have to think about the whole software liability issue. We might want to start talking to actuaries and insurance professionals to find out how businesses manage risk. Is there a way for ISVs (Independent Software Vendors) to assume limited liability and still remain in business? What will this do to the cost of our products? How will the market value warrantees on software?
I don't know if any of these actions will lead us to the promised land, but you never know...
0 Comments:
Post a Comment
<< Home