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 doing—securely developing and implementing your
application—could 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
camps—application or operations—we encourage you to open
yourself up to learning why the other folks' work
and your work are two sides of the same coin.
|