Chapter 5. Operations

   

We didn't install the [Code Red] patch on those DMZ systems because they were only used for development and testing.

Anonymous client, shortly after spending roughly 48 continuous hours removing 2001's Code Red worm from internal corporate servers

Throughout our careers, we've assessed the security of literally hundreds of major business applications. One of our most surprising (and disturbing ) discoveries has been the apparent and thorough separation of application development staff from operating system and operations staff in major enterprises . In many of them, it seems as deeply rooted as the Constitutional separation of church and state in the U.S.

At one Fortune 500-level enterprise we examined, there was a nearly complete separation. The applications staff knew little of what the operations staff did and vice versa. There was even a separation of the security components of the applications and of the operating systems. In a number of cases, relatively secure applications were being placed upon unsecured operating systems and vice versa. It was evident that applications were not being deployed by a unified team. What particularly concerned us about this practice was the way that the employees we spoke with would thoroughly pass the buck of security to their counterparts, with no apparent desire to know the answers to the questions we were asking. We came away with the impression that this sterile separation would ultimately undermine the overall security of the enterprise.

Consider how an organization such as this might respond to the SYN flood attacks we've discussed throughout this book. Do you think that the application developers would think for a moment that a problem arising in the operating system's TCP subsystem should be their concern? And yet, do you think that their applications would be any less unavailable for legitimate use if they were hit with an attack?

Now that several years have passed, we feel all the more strongly that the security of an application and the security of an operational environment are inextricably tied to one another. To attend to one at the expense of the other is to neglect your duty to ensure that your overall business is secure.

Let's put it another way: if you're a software author, all the good work that you've been doingsecurely developing and implementing your applicationcould be wasted if you don't take the time to ensure that you're deploying the application in a secure environment. And that environment isn't limited to the operating system. You also need to ensure that your application resides in a securely networked environment and one that practices secure operations practices as well.

This is a daunting challenge, particularly because one small mistake can have such far-reaching ramifications . We'll discuss the implications in some detail in this chapter. For now, though, if you should happen to fall into one of those two campsapplication or operationswe encourage you to open yourself up to learning why the other folks' work and your work are two sides of the same coin.

   


Secure Coding[c] Principles and Practices 2003
Secure Coding[c] Principles and Practices 2003
ISBN: 596002424
EAN: N/A
Year: 2004
Pages: 81

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net