Overseeing Compliance of Security Operations ◾  179
© 2011 by Taylor & Francis Group, LLC
Downloading patches from the vendor to a central location saves on bandwidth
that would otherwise be necessary to support downloading from the vendor to each
individual desktop. e central repository may then facilitate the forced installation of
patches throughout the enterprise from within the enterprise. Patch management soft-
ware provides a means to test patches prior to deployment throughout the enterprise.
e patch management software also provides a database of software, current versions,
and patched systems that provides input to overall enterprise situational awareness.
Part of the benet of creating a policy and standards for a common desktop
environment (CDE) is to facilitate the capability to test once, deploy many. If a patch
works well with the CDE, then deploying the patch enterprise-wide should not cre-
ate problems. e CDE is a standard that enumerates permissible software and oper-
ating system settings. Managing PCs enterprise-wide is greatly simplied, though
still far from simple, if you implement and enforce an enterprise CDE standard.
Patch Management, Risk Posture, and Security Posture
e enterprise security posture is the aggregation of all the safeguards and precautions
that mitigate risk. e enterprise risk posture is the formal articulation of an inten-
tionally assumed position on dealing with potential negative impact. Awareness
of a new vulnerability does not change the security posture, i.e., no safeguard or
precaution is any dierent than it was. Likewise, this vulnerability awareness does
not change the risk posture, i.e., the enterprise still has the same stance on risk
that it did before. Risk exposure does not change either, i.e., the enterprise has the
same degree of risk exposure. What does change is the risk awareness, which is
the level of conscious knowledge of potential negative impact. is new awareness
starts a sequence of events that evaluates risk exposure (e.g., yes, this vulnerability
does indeed represent a high degree of risk exposure to the enterprise), evaluates the
risk posture (e.g., yes, we should modify our risk posture to mitigate this risk), and
modies the security posture accordingly (i.e., we will install a patch to eliminate
the vulnerability).
e reason for distinguishing among security posture, risk posture, risk expo-
sure, and risk awareness is to point out nuances of consideration for installing the
patch. Often, installing patches is like squeezing jelly; every time you tighten up
one area of your st, jelly shoots out another. Installing the patch may take care
of the risk you are now aware of, but it may introduce new risk to other parts of
business operations. How do you know if this happens? One method is to set up a
test lab, install the patch on a mirror of the production system, and test the eects
on system and application operations. Another is to install the patch directly on
the production system and be prepared with back-out procedures. Establishing a
test lab requires an investment of time and resources. Using a test lab is the most
prudent approach from a risk management perspective. Installing patches on the
y in production may be necessary to respond to a critical operations need. If this is
180 ◾  Official (ISC)
2
® Guide to the ISSMP® CBK®
© 2011 by Taylor & Francis Group, LLC
the case, the best risk management method is to be prepared to back out the patch
as quickly as possible if something goes wrong.
A change to the security posture is the addition or detraction of a safeguard
or safeguard feature, e.g., adding an intrusion detection system (IDS) increases
the security posture by adding an additional defense-in-depth security mechanism.
How ever, presenting the security posture to executives has no meaning to them.
Honestly, a CEO could not care less about a security posture in terms of rewalls,
IDS, anti-malware, and security awareness training. What a CEO does care about
is risk posture that includes how you as a security professional are handling poten-
tial liability issues via legislative compliance. Your understanding of the nuances
around security posture and risk posture will help you articulate the security story
in words desirable and understandable by the audience across operations, manage-
ment, and governance.
Change Control
A change is an event that results in a new status of one or more aspects of the enter-
prise. Enterprise aspects include people, process, technology, environment, policy,
standards, procedures, and guidelines. Controlling change within the enterprise
results in the predictable impact of modications on operations and productivity
with minimal disruption and ecient use of resources involved in the change. e
overall process of change control is dierent from the information technology use of
revision control, version control, and source control (collectively referred to herein
as version control for simplicity). Change control is for quality management and
ensures forethought; version control traditionally applies to software development
environments, but is nding new uses in knowledge management applications. We
will rst look at change control as an enterprise process for managing the impact of
modications on policy, standards, procedures, practices, people, process, technol-
ogy, and environment; change control is for technology, but not only technology.
Change control roles include the following:
Change initiator (CI)
Change sponsor (CS)
Change owner (CO)
Change administrator (CA)
Impact assessor (ImA)
Change manager (CMgr)
Task owner (TO)
Change control board (CCB)
e CI initially requests a modication and is the same person who will ulti-
mately conrm the completion of the modication. e CS provides business
approval for the change. e CO monitors and manages the change through
Overseeing Compliance of Security Operations ◾  181
© 2011 by Taylor & Francis Group, LLC
acceptance of the CI and closure. e CA assesses the change request, monitors
progress through the CO, and ensures acceptance by the CI. e ImA analyzes the
enterprise impact of the change. e CM guides the overall change process, acts as
a point of escalation for the CO, and interacts with the CCB to review and process
change requests, especially in the event of emergency changes. e TO receives
direction from the CM and performs activities that implement the change. e
CCB is a management group that reviews the change process and specic changes
that may aect enterprise operations.
e CCB is a committee of stakeholders aected by the proposed change. e
CCB makes the nal decision on whether or not to implement the change. e author-
ity of the CCB should be such that its decision regarding the change is nal and
binding. Members of the CCB should include a representative from security. Any
change to the organization requires a review of the risk to the enterprise environ-
ment (e.g., physical), processes (e.g., operations), people (e.g., safety), and technol-
ogy (e.g., ability to produce desired results). e security representative can assist
with risk identication, risk implications, and risk mitigation.
e change control process consists of the following steps:
Initiate
Analyze
Plan
Build/implement/test
Deploy
Outreach
Close
e CI initiates a change request via formal submission. e CI and CS work
together to provide as much detail as possible in the formal submission, including clas-
sication of the change (e.g., people, process, technology, environment, policy, etc.),
scope of impact on enterprise operations, impact on enterprise bottom line (e.g., cost
and revenue impacts), cost of change, and benet of change; the formal submission
also identies a CO as the primary contact for the CI and CS. Note: Distinguishing
these roles helps identify necessary change control steps and accountability. e roles
may be virtual, meaning any particular individual may be assigned multiple roles.
e CA and ImA analyze the change request with respect to enterprise impact,
including risk, risk mitigation, operational impact, cost, and benet. e CA iden-
ties all stakeholders in the claim request, including those impacted by the change
(e.g., the operations manager). e stakeholders all provide input to the change
plan, which provides details on budget, schedule, milestones, areas aected, work
breakdown structure (WBS), resource list, resource assignments, etc. e plan also
provides for the ability to back out changes in the event of unforeseen diculties.
e change request delivery team then follows the plan and proceeds to
build, implement, and test the changes. ese are accomplished in a controlled
182 ◾  Official (ISC)
2
® Guide to the ISSMP® CBK®
© 2011 by Taylor & Francis Group, LLC
environment or a small production environment to discern the nuances of intro-
ducing the change with high eciency and low impact to operations. e lessons
learned from this step will make deployment throughout the enterprise much more
cost eective. e CM oversees those performing tasks (the TO) that implement
the change; additionally, the CM oversees the entire change process, including
outreach to stakeholders.
Outreach to those parts of the organization aected by the change should begin
in the building phase and proceed throughout implementation, testing, and deploy-
ment. Engaging people early on will make them feel like part of the process and
increase the likelihood of their adopting the changes. At the very least, outreach
should include awareness and training post-deployment to ensure that operations
personnel know about the change, what it means to them, how it aects their jobs,
and how to use the change eectively.
Closure of the change request is the result of successful implementation. Also,
a decision to back out the change and regress to the initial prechange state may or
may not result in closure. Backing out a change may be an interim step to imple-
menting the change dierently and accommodating an unforeseen impact. A nal
decision to back out the change because it is the wrong business decision may also
result in closure of the change request.
e following are examples of modications requiring change control:
Operating system upgrades
Policy modications
Network infrastructure renewal
Operating system upgrades have the potential to aect all the underlying soft-
ware applications that run the organization. A formal change process is necessary
to manage the introduction of the new operating system in a controlled manner to
ensure full knowledge of the organizational impact.
Policy modications come from executives and upper management. Many
times, policy changes rarely nd their way into operations because it is assumed
that the decree of upper echelons is known and acted upon simultaneously with the
policy change. Any change in policy must nd its way to operations in order to have
any real impact on the organization. In an analogy, consider the dierence between
a law and the ability to enforce that law. e citizenry needs to be aware that there
is a new law; the police and judicial system needs to be aware that there is a new law
and what that means insofar as monitoring for violations and adjudicating violators.
e same applies to changes in enterprise policy. e change control process will
help facilitate the application of new policy throughout the enterprise, especially in
operations to implement and enforce the new policy.
Network infrastructure renewal includes a refresh of all routers and switches.
e enterprise impact is huge and IT operations need to analyze the implications
of introducing new versions from the same vendor or swapping out for new vendor
Overseeing Compliance of Security Operations ◾  183
© 2011 by Taylor & Francis Group, LLC
equipment all together. e formal change process will help identify technical and
business implications of either decision.
Version Control
Version control is the management of multiple revisions of a le, where the le
may be source code, a written document, an engineering diagram, an architectural
blueprint, etc. e purpose of version control is to track changes and to provide the
ability to restore or reference previous versions. For example, from personal experi-
ence as a software developer, three days into implementing user change request
specications, the specications changed. ese new changes were to such a degree
that it made more sense to roll back to the source code of three days ago rather than
try to modify the current version of the source code. Using a version control system
(VCS) made the restoration of the previous version very simple and resulted in high
condence that it was indeed the starting point desired.
is same concept of version control or revision control applies to knowledge
management systems (KMS). A KMS supports the creation, capture, storage, dis-
semination, comments, and modications to knowledge within the enterprise. A
KMS facilitates the learning organization where information belongs to the enter-
prise and is made available to the enterprise via information technology. is is
contrary to information belonging to an individual, residing on an individual hard
drive, and lost when the individual leaves the organization.
Records Management
e ISO 15489: 2001 Information and DocumentationRecords Management stan-
dard denes records management as “the eld of management responsible for the
ecient and systematic control of the creation, receipt, maintenance, use and dispo-
sition of records, including the processes for capturing and maintaining evidence of
and information about business activities and transactions in the form of records.
Records
e word record as a noun means a document or other entity that preserves infor-
mation. e 44 U.S.C. Chapter 33 Section 3301 denes records as “all books,
papers, maps, photographs, machine readable materials, or other documentary
materials, regardless of physical form or characteristics, made or received by an
agency of the United States Government under Federal law or in connection with
the transaction of public business and preserved or appropriate for preservation by
that agency or its legitimate successor as evidence of the organization, functions,
policies, decisions, procedures, operations, or other activities of the Government
or because of the informational value of data in them.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.220.9.237