Getting Everyone s Head in the Game

Security is a top priority needs to be a corporate dictum because, as we ve seen, the need to ship secure software is greater than ever. Your users demand that you build secure applications they see such systems as a right, not a privilege. Also, your competitor s sales force will whisper to your potential customers that your code is risky and unsafe. So where do you begin instilling security in your organization? The best place is at the top, which can be hard work. It s difficult because you ll need to show a bottom-line impact to your company, and security is generally considered something that gets in the way and costs money while offering little or no financial return. Selling the idea of building secure products to management requires tact and sometimes requires subversion. Let s look at each approach.

Using Tact to Sell Security to the Organization

The following sections describe arguments you can and should use to show that secure applications are good for your business. Also, all these arguments relate to the bottom line. Ignoring them is likely to have a negative impact on your business s success.

Secure Products Are Quality Products

This is a simple issue to sell to your superiors. All you need to do is ask them if they care about creating quality products. There s only one answer: yes! If the answer is no, find a job elsewhere, somewhere where quality is valued.

OK, I know it s not as simple as that, because we re not talking about perfect software. Perfect software is an oxymoron, just like perfect security. (As is often said in the security community, the most secure system is the one that s turned off and buried in a concrete bunker, but even that is not perfect security.) We re talking about software secure enough and good enough for the environment in which it will operate. For example, you should make a multiplayer game secure from attack, but you should spend even more time beefing up the security of an application designed to manipulate sensitive military intelligence or medical records.

Despite the fact that the need for security and the strength of security is context-driven that different situations call for different solutions what s clear in this argument is that security is a subset of quality. A product that is not appropriately secure is inferior to competing products. Some would argue that security is a subset of reliability also; however, that depends on what the user means by security. For example, a solution that protects secret data need not necessarily be reliable. If the system crashes but does so in a manner that does not reveal the data, it can still be deemed secure. As Figure 1-1 shows, if you care about quality or reliability, you care about security.

Figure 1-1

Secure software is a subset of quality software and reliable software.

Why Would You Protect a Multiplayer Game from Attack?

It might not seem obvious, but multiplayer games are also susceptible to attack. Imagine you have written and published a multiplayer strategy game, such as Microsoft Age of Empires II. Someone discovers a vulnerability in the game that allows them to kill other players by sending a bad data packet to the other player s computer. So when a player is losing a heated conflict with another player, the first player simply sends the packet of death to the other computer and kills his or her opponent. That s hardly sportsmanlike but nonetheless likely, so you should protect your users from this kind of malicious behavior.

The Media (and Your Competition) Leap on Security Issues

Like it or not, the press loves to make headlines out of security problems. And sometimes members of the press don t know what they re talking about and mischaracterize or exaggerate issues. Why let the facts get in the way of a good story? Because people often believe what they read and hear, if your product is in the headlines because of a security issue, serious or not, you can bet that your sales and marketing people will hear about the problem and will have to determine a way to explain the issue. The old adage that any news is good news simply does not hold true for security incidents. Such publicity can lead people to start looking for solutions from your competitors because they offer seemingly more secure products than you do.

People Shy Away from Products That Don t Work As Advertised

Once news gets around that your product doesn t work appropriately because it s insecure, some people will begin to shy away from your product or company. Worse yet, people who have a grudge against your product might fan the fire by amassing bad security publicity to prove to others that using your product is dangerous. They will never keep track of the good news, only the bad news. It s an unfortunate human trait, but people tend to keep track of information that complies with their biases and agendas. Again, if you do not take security seriously, the time will come when people will start looking to your competition for products.

Don t Be a Victim

There is a misguided belief in the market that people who can break into systems are also the people who can secure them. Hence, there are a lot of would-be consultants who believe that they need some trophies mounted on their wall for people to take them seriously. You don t want your product to be a head on someone s wall!

Security Vulnerabilities Are Expensive to Fix

Like all engineering changes, security fixes are expensive to make late in the development process. It s hard to determine a dollar cost for a fix because there are many intangibles, but the price of making one includes the following:

The cost of the fix coordination. Someone has to create a plan of attack to get the fix completed.
The cost of developers finding the vulnerable code.
The cost of developers fixing the code.
The cost of testers testing the fix.
The cost of testing the setup of the fix.
The cost of creating and testing international versions.
The cost of digitally signing the fix if you support signed code, such as Authenticode.
The cost to post the fix to your Web site.
The cost of writing the supporting documentation.
The cost of handling bad public relations.
Bandwidth and download costs if you pay an ISP to host fixes for you.
The cost of loss of productivity. Chances are good that everyone involved in this process should be working on new code instead. Working on the fix is time lost.
The cost to your customers to apply the fix. They might need to run the fix on a nonproduction server to verify that it works as planned. Once again, the people testing and applying the fix would normally be working on something productive!
Finally, the potential cost of lost revenue, from likely clients deciding to either postpone or cancel using your product.

As you can see, the potential cost of making one security fix could easily be in the tens, if not hundreds, of thousands of dollars. If only you had had security in mind when you designed and built the product in the first place!


	While it is difficult to determine the exact cost of issuing a security fix, the Microsoft Security Response Center believes a security bug that requires a security bulletin costs in the neighborhood of $100,000.

Another source of good reasons to make security a priority is the Department of Justice s Computer Crime and Intellectual Property Section (CCIPS) Web site at www.cybercrime.gov. This superb site summarizes a number of prosecuted computer crime cases, outlining some of the costs necessitated and damages inflicted by the criminal or criminals. Take a look, and then show it to the CEO. He should realize readily that attacks happen often and that they are expensive.

Now let s turn our attention to something a little more off-the-wall: using subversion to get the message across to management that it needs to take security seriously.

Using Subversion

Luckily, I have had to use this method of instilling a security mind-set in only a few instances. It s not the sort of thing you should do often. The basic premise is you attack the application or network to make a point.

For example, many years ago I found a flaw in a new product that allowed an attacker (and me!) to shut down the service remotely. The product team refused to fix it because they were close to shipping the product and did not want to run the risk of not shipping the product on time. My arguments for fixing the bug included the following:

The bug is serious: an attacker can remotely shut down the application.
The attack can be made anonymously.
The attack can be scripted, so script kiddies are likely to download the script and attack the application en masse.
The team will have to fix the bug one day, so why not now?
It will cost less in the long run if the bug is fixed soon.
I ll help the product team put a simple, effective plan in place with minimal chance of regression bugs.


	What s a regression bug? When a feature works fine, a change is made, and then the feature no longer works in the correct manner, a regression is said to have occurred. Regression bugs can be common when security bugs are fixed. In fact, based on experience, I d say regressions are the number one reason why testing has to be so intensive when a security fix is made. The last thing you need is to make a security fix, only to find that it breaks some other feature.

Even with all this evidence, the product group ignored my plea to fix the product. I was concerned because this truly was a serious problem; I had already written a simple Perl script that could shut down the application remotely. So I pulled an evil trick: I shut down the application running on the team s server they used each day for testing purposes. Each time the application came back up, I shut it down again. This was easy to do. When the application started, it opened a specific Transmission Control Protocol (TCP) port, so I changed my Perl script to look for that port and as soon as the port was live on the target computer, my script would send the packet to the application and shut it down. The team fixed the bug because they realized the pain and anguish their users would feel. As it turned out, the fix was trivial; it was a simple buffer overrun.

Refer to Chapter 3, Public Enemy #1: The Buffer Overrun, for more information on buffer overruns.

Another trick, which I recommend you never use except in the most dire situations, is to attack the application you want fixed while it s running on a senior manager s laptop. A line you might use is, Which vice president s machine do I need to own to get this fixed?


	What does own mean? Own is hacker slang for having complete and unauthorized access to a computer. It s common to say a system is 0wn3d. Yes, the spelling is correct! Hackers tend to mix numerals and letters when creating words. For example, 3 is used to represented e, zero is used to represent o, and so on. You also often hear that a system was rooted or that someone got root. These terms stem from the superuser account under Unix named root. Administrator or System account on Microsoft Windows NT, Windows 2000, and Windows XP has an equivalent level of access.

Of course, such action is drastic. I have never pulled this stunt, and I would probably e-mail the VP beforehand to say that the product she oversees has a serious security bug that no one wants to fix and that if she doesn t mind, I d like to perform a live demonstration. The threat of performing this action is often enough to get bugs fixed.


	Never use subversive techniques except when you know you re dealing with a serious security bug. Don t cry wolf.

Now let s change focus. Rather than looking at how to get the top brass into the game, let s look at some ideas and concepts for instilling a security culture in the rest of your organization.