A FRAMEWORK FOR OPERATIONAL SECURITY

A FRAMEWORK FOR OPERATIONAL SECURITY
Because of its sheer ubiquity, the Windows operation system is likely to be touched by
many people, processes, and other technologies during the course of its duty cycle. Thus,
any consideration of Windows security would be incomplete if it did not start with an
acknowledgment that it is just one piece of a much larger puzzle.
Of course, heres where the challenge arises. This book covers the bits and bytes that
make up Windows security, a finite universe of measures that can be taken to prevent
bad things from happening. However, as any experienced IT professional knows, a lot
more than bits and bytes are needed for a good security posture. What are some key non-
technical considerations for security? Another book probably needs to be written here,
but well try to outline some of the big pieces in the following discussion to reduce the
confusion to a minimum so that readers can focus on the meat and potatoes of Windows
security throughout the rest of this book.
Figure 1-1 illustrates a framework for operational security within a typical
organization. The most telling thing to note about this framework at first glance is that it
iscyclical. This aligns the model with the notion of security as a journey, not a destination.
New security threats are cropping up all the time (just tap into any of the popular security
mailing lists, such as Bugtraq, to see this), and thus any plan to address those threats
must be ongoing, or cyclic.
The four elements of the fisecurity wheelfl shown in Figure 1-1 are Plan, Prevent,
Detect, and Respond. While such frameworks are sometimes criticized as fione size fits
allfl thinking that may not align with established organizational structures or cultures,
weve found that these four simple building blocks are the most resonant with our
consulting clients who run IT shops of all sizes, and they generally encompass all the
various components of their security efforts. Lets talk about each one of these in turn.  

Plan
Security is a challenging concept, especially when it comes to technology. When
considering how to provide security, you need to begin planning around the following
questions:
What asset am I trying to secure?
What are the assets security requirements?
What are the risks unique to that assets security requirements?
How do I prioritize and most ef? ciently address those risks (especially those
with heavy impact such as industry and regulatory compliance requirements)?
These questions describe a risk-based approach to security, popularized by many
modern practitioners. Well-known risk-based security methodologies include the CERTs
Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE) Method.
Microsoft also promotes their own approach to risk management in software development
scenarios, which they call threat modeling. We will articulate an oversimplified adaptation
of common risk management best practices here, and we encourage readers interested in
more details to consult the fiReferences and Further Readingfl section at the end of this
chapter.
Lets start with the determination of assets. This exercise is not as straightforward as
you might thinkassets can be server hardware, information in a database, or even
proprietary manufacturing practices. In fact, we are often amazed when our consulting
clients are sometimes unable to provide a coherent answer to the simple question, fiWhat
are your most important assets?fl We often find it helpful to scope the answer to this
question narrowly at first, perhaps limiting the scope to digital information assets
considered valuable to the organization. Of course, the physical vessels upon which the
digital assets travel (be they computer servers, or USB thumb drives, or kiosk computer
monitors, or paper printouts) are also of critical importance to security, but weve found
that its easier to consider those relationships later in the risk assessment process. We also
recommend postponing consideration of less tangible assets such as reputation until
youve first acquired some practice at the risk-management game.
Sensitive digital information asset categories to consider include credentials (such as
passwords and private cryptographic keys), personally identifiable information (remember
that sensitivity can depend on whether consent is granted for specific uses), liquid financial
instruments or information (such as credit card data), proprietary information (including
unreported financial results or business methodologies), and the availability of productive
functionality (including access to functional systems, electricity, and so on).
Once you have determined what assets you are trying to secure, your next step is to
identify each assets security requirements, if any. As with assets, its quite helpful to
classify security requirements into their most generic categories. Most modern definitions
of information system security center around protecting the confidentiality, integrity, and
availability (CIA) of important assets, so this is our recommendation. One might consider
another A, for accountability, to capture the notion that the system must also faithfully
record activity so that it can be subsequently examined or audited (such as through audit
logging).
Tip
At this point, you may consider grouping assets into classes based on their perceived sensitivity to the
organization. This can yield a system of policies and supporting controls for each asset type. For
example, High Sensitivity assets such as credit card information may require encryption when stored
or transmitted, whereas Low Sensitivity assets would not. Here again, compliance requirements
should be considered (such as with credit card data that likely falls under the Payment Card Industry
Data Security Standard, or PCI DSS).
With assets and security requirements in place, it is time to consider the risks that
each asset faces. This process is commonly called risk assessment. Several approaches to
risk assessment exist, but the one we recommend is the least formal: logically diagram
the system in question, decomposed into its constituent parts, paying close attention to
boundaries and interfaces between each component as well as key assets, and brainstorm
the possible threats to CIAA that they face.
Some more systematic (but not necessarily superior) approaches to conceptualizing threats
include attack trees and Microsofts threat modeling methodology. See fiReferences and Further
Reading.