5.3 Bad Practices

It should come as no surprise that we've provided a lengthy list of operational practices that you should avoid. As with previous lists, this one is the product of our many years of seeing innumerable mistakes made during the operations stage.

Don't pass the buck

As we mentioned at the beginning of this chapter, in our reviews of business applications, one of the things we found most frequently was the attitude, "That's someone else's job, so I don't need to worry about it." Although operations security may not be your job as an application programmer, the security of your application nonetheless depends on it. It would serve you well to learn more about how the operations personnel do their jobs and to ensure that sufficient attention is being paid to the security aspects of operations within your organization.

Of course, there are good ways and bad ways to go about doing this. Make sure to approach this in a way that fits in with your organization's overall culture and policies. The most important thing, though, is that you should never blindly assume that a security issue is being handled by someone else (until you have positive confirmation that it is).

Don't let the developers rule the roost

Although we realize that this statement might not please some of our readers, it's important to have functional boundaries between development, testing, and operations environments. Maintaining these boundaries entails some additional administrative overhead—for example, in making changes to production code—but in the long run, it's time well spent. Everyone involved in the development, deployment, and operation of an application needs to understand that the overall goal of the effort is the success of the business application. As such, spend the extra time to do things right. We've seen production environments in which the developers have no restrictions on doing such things as changing production products. Invariably, these environments are instable enough that you'd never trust an important business process to them. Expecting them to be secure is way beyond reason.

Don't assume anything

A truly responsible application developer should know and understand all aspects of his application's security. When in doubt, verify that something is as it should be, whether it's a simple file access control setting or a major operational practice that could expose your application to risks. Attention to details can make or destroy the security of an application.

Don't use back doors

It's all too common and easy for an application developer to place a simple back door on a computer system or within an application, so that he can connect to the application should something go wrong and (so he thinks) correct it. If this thought crosses your mind for even an instant, run screaming from it. It is simply inevitable that someone—the wrong person—will uncover your back door and use it to your detriment.

Avoid temporary fixes

When something goes wrong, avoid putting in place a temporary fix that alleviates the symptoms without addressing the true cause of the problem. A common example of this is to change a file's access control settings to enable a program to access the file. While doing this may indeed make the error messages go away, you need to examine the problem closely and verify that you're not creating a bigger problem than the one you set out to fix. The problem that you fix badly today may well grow to be much more serious tomorrow.

Avoid shortcuts

As with temporary fixes, avoid shortcuts like the plague. For example, you might be tempted to use a flawed (but readily accessible) network protocol to transfer data between two computers, when a more robust methodology is available but would take more time to implement.

Abandon the castle and moat mentality

We've seen dozens of data center environments in which flawed operations practices are in production use. In almost every case, the people in charge of the environment acknowledged that more secure practices were available, but they claimed that the flawed practices were sufficient because they were confined to a small network segment. Although such segmentation may well reduce the risk profile, it certainly doesn't remove it. If better tools and protocols are available, use them. If you assume that attackers could potentially compromise even your small network segment, then your overall security posture will inevitably benefit.

Beware of mission creep

We've often heard people jokingly say that any network firewall eventually becomes useless as more and more rule sets are layered on it. It's common practice to continually add rule sets to firewalls so that new applications can be accommodated in a data center. Each time this happens, another potential entry point to your application has been created. That same principle also holds true for other aspects of operations security. While you'll undoubtedly need to make exceptions from time to time to accommodate business needs, be very careful not to violate the underlying security architectures and principles.

Don't blindly trust third-party software installations

Whether it's a stand-alone package or a library of software that you're using within your software, don't ever blindly trust that third-party software has been installed securely. If you oversee the installation of your own software meticulously, then you should do the same for any third-party software that you use. After all, the installation script or program that installed the third-party application may well make a file access control choice that you would not accept from your own application. Install the software and thoroughly scrutinize its installation profile to make sure it's acceptable to you.