26 ◾ Official (ISC)
2
® Guide to the ISSMP® CBK®
© 2011 by Taylor & Francis Group, LLC
inuences and on the right are the operational inuences. All of these must be thor-
oughly understood by an ISSMP prior to developing an information system secu-
rity program, because with these the ISSMP will understand the “True Problem”
that needs to be solved.
Using this knowledge of the organization’s systems, the ISSMP can take the next
step of developing the Enterprise System Security Framework for the systems.
System Development Life Cycle (SDLC)
An enterprise system security program must support the systems continuously from
“cradle to grave,” because systems’ environments, missions, threats, and vulnerabili-
ties are constantly changing throughout the life of the systems. Security reviews and
actions must be taken to ensure that each system remains secure, so before moving
on to the next topic, the concept of system development life cycle (SDLC) must be
understood to provide the ISSMP with a point of reference for future topics.
e SDLC title can sometimes be misleading because of the word “develop-
ment.” In reading the title the initial perception is that it only supports development
of the system and stops at the acceptance of the system. Actually, SDLC covers the
system from conception to disposition.
ere are many SDLC models used for information systems, but most of the
models consist of ve basic phases:
1. Initiation Phase: is phase identies what the real and perceived needs are
for the system and a determination of how they link to the business mission
Total Influences
Laws and
Regulations
Senior Management
Group Culture
& Expectations
Mission, Goals
& Objectives
reats
Security
Categorization
Security
Boundaries
Vulnerabilities
Risks
Competition
Client Capabilities
& Expectations
Information System
Security Program
Information
Classification
Information
Figure 1.4 Total information system security program influences.
Enterprise Security Management Practices ◾ 27
© 2011 by Taylor & Francis Group, LLC
being supported by the system. Security actions during this phase include
conducting a security categorization and preliminary risk assessment.
2. Development/Acquisition Phase: Here the statement of functional require-
ments is drafted, various analysis activities are conducted (i.e., requirements,
alternatives, cost-benet, etc.), and a risk management plan is drafted. Security
activities include conducting a risk assessment, a security functional and assur-
ance requirements analysis, security planning, and security test and evalua-
tion activities.
3. Implementation Phase: During this phase, system(s) are installed and
inspected, nal acceptance testing is completed as well as documentation, and
users are trained. For security, nal security testing and evaluation (ST&E)
eorts are completed and documented, and the system is authorized to go
operational.
4. Operations/Maintenance Phase: e systems in full operation mode will
require continued maintenance support, monitoring of performance, and
modications as required to meet mission requirements. Conguration man-
agement and monitoring of security eectiveness and the security environ-
ment will be conducted on a continuous basis to maintain an acceptable
security posture.
5. Disposition/Disposal Phase: When it is determined that the system is no
longer useful, decisions are made regarding how the system will be transi-
tioned or disposed of (i.e., exchange, sale, transfer, donation, etc.), supporting
and supported elements will be notied and services nalized, and so forth.
Security actions will support information preservation, sanitization of the
media, and disposal of the hardware and software.
Notice that much of what has been discussed thus far includes actions that were
identied in the Initiation Phase.
As mentioned, many versions of the SDLC are being used by organizations.
e versions can range from ve to many phases. It is imperative that the ISSMP
understand the SDLC model used within the organization to ensure that appropri-
ate security support is provided to the process in a timely manner and security is
implemented from the beginning of the cycle to the end. So, one of the rst actions
an ISSMP should take is to verify what the specic SDLC model for the organiza-
tion is. Typically, it can be found in the corporate or CIO policies and procedures;
if not, ask the system program manager.
Enterprise System Security Framework
An Enterprise System Security Framework is created to ensure that IT security is
designed, implemented, authorized, and maintained to provide an acceptable level
of risk and is cost-eective. An Enterprise System Security Framework is a structure
28 ◾ Official (ISC)
2
® Guide to the ISSMP® CBK®
© 2011 by Taylor & Francis Group, LLC
developed by the organization and must have the following components identi-
ed, developed, and documented:
◾ Policies
◾ Standards
◾ Guidelines–Best Practices
◾ Roles and Responsibilities
◾ Procedures and Processes
◾ Baselines
◾ Enterprise-Wide Security Consistency
Twenty-rst century ISSMPs are fortunate because there are many tools and
materials available to them for helping them build this framework in the form of
standards, guidelines, control baselines, examples, and so forth. Because these were
created by the IT security experts who preceded them in various types of organi-
zations (governmental and commercial), they are like the materials (wood, brick,
glass, nails, etc.) available to make a house, i.e., they all need to be modied and
reshaped to build the specic framework for the individual organization’s enter-
prise system security architecture.
Enterprise Security Policy
An enterprise security policy establishes the framework for how security will be
implemented, maintained, and modied as the security and business environment
changes. A successful enterprise security policy provides answers to the following:
◾ What are the controls, processes, and procedures related to maintaining
an adequate security posture as the environment changes, new systems are
deployed, and existing systems are modied or decommissioned?
◾ How are these reviewed for compliance and enforced?
◾ Who is responsible for all the above and the associated resources?
◾ How are these responsibilities communicated and monitored?
◾ To whom does one report issues, and from whom does one gain further
clarication?
Overall, it is critical that the enterprise security policy be accurate, robust, and
complete. It must accurately reect the needs of all of the information systems in the
organization. Robustness is necessary to ensure the security policy is exible enough
to support the dierences in the systems and changes in the organization’s mission,
operation, and environment. Finally, the enterprise security policy must cover all
the security requirements necessary to provide the best security for the systems.
To ensure that the enterprise security policy meets all of these requirements,
ISSMPs must have a thorough understanding of the organization’s systems. is
Enterprise Security Management Practices ◾ 29
© 2011 by Taylor & Francis Group, LLC
is why this chapter began with a focus on identifying the organization’s missions/
business goals and objectives, functional groups, and individual systems boundaries,
cultures, and security functions. Without these, the ISSMP will be ineective in
building the enterprise security policy or any other component within the enterprise
security framework. Many have tried using “standard” or “generic” security policies
and failed because they lacked an understanding of the problem.
To achieve the above objectives and create their organization’s enterprise secu-
rity policy in an ecient and eective manner, ISSMPs must incorporate the most
basic of all management principles and methodologies. e following are consid-
ered absolute “musts”:
Understand the Current Environment: Ensure that the policies are robust
enough to support the current operating environment and the true reality
of the organization, including the business, culture, expectations, local laws,
regulations, and operational needs.
Use Standard Project Management Practices: Organizations must build their
programs using proven management concepts and processes. Developing
unique, creative management processes frequently results in a costly and
unsuccessful experience. It is highly recommended to leverage the informa-
tion provided by the Project Management Institute (PMI) to reduce risks
related to managing projects and programs.
Be Based on Risk and Cost: Policies must be based on the results of risk assess-
ments and cost-benet analyses to ensure that they are in the best interests of
the organization.
Are Enforceable: Polices must be enforceable to be eective and should address
what the consequences will be for those who violate the policies. Not enforc-
ing one policy can degrade all of the organization’s policies.
Be Supported by Executives: Polices that do not have the support of senior
management, HR, and the legal department will not be eective. erefore,
all concerns from these groups must be addressed and resolved prior to the
release of any policies.
Include Representatives: To increase the eectiveness of the policy in any orga-
nization, the development of the policy must have the participation of those
who will be using the policy. User representatives from all elements (func-
tional, business, and support units) will ensure that the policies are practi-
cal and applicable to all of the elements. Additionally, these representatives
can become great promoters to other users during the implementation of the
policies. is will also prevent the perception of senior management creating
policies “in a vacuum” without an understanding of reality.
Communicate Policy: Organizations must ensure that all of their employees,
clients, and partners are fully aware of their policies to ensure eective and
ecient operations and compliance with regulations. It is recommended that
30 ◾ Official (ISC)
2
® Guide to the ISSMP® CBK®
© 2011 by Taylor & Francis Group, LLC
there be a proactive and consistent awareness program that extends beyond
the initial employee indoctrination eorts. Promotion of policies via memos,
e-mails, newsletters, banners, senior management presentations, town hall
meetings, and so forth, can be used.
Be Reviewed Regularly: As the organization changes, the policy will need to
change and grow to support those changes. All policy changes must be docu-
mented to include who approved the change, when, and what caused the
change. Reasons for changing policies include changes in threats and vul-
nerabilities, mergers, acquisitions, testing and exercise results, and so forth.
Routine reviews should be scheduled at least annually.
Track Exceptions: Although the entire organization is supposed to comply
with the organization’s policies, there are situations where exceptions must be
made. Whenever exceptions are made, the following must be documented:
the exemption, justication and time period for the exemption, who autho-
rized the exemption, and when. is documentation needs to be centrally
located with the enterprise’s policy documents.
Create One Central Location: e organization should have one central location
where all polices are maintained so everyone can access them. is supports the
requirement that all employees should be aware of an organization’s policies.
Leverage Technology and Expertise: Enterprise security policies should always
leverage two things: technology and the experience of other experts, e.g., the
previously mentioned use of PMI for project management.
Leveraging technology to automate manual processes and procedures can
be either very cost-eective or not. Having technology that replaces the manual
updating of each computer by pushing down patches and antivirus updates for a
very large, dispersed system should be considered when building a security policy.
But not all technology can be leveraged without the additional implementation of
more controls, like using an automated tool for system personnel to document and
report their security control status, when the system personnel do not understand
security. Another example is stating a policy that everyone will use smartcards for
system access, and when smartcards are deployed the systems are not congured
with smartcard readers. Do leverage technology, but ensure that it is practical and
not vulnerable. Also be aware of what will have to be done when established enter-
prise security policies are confronted with technology inherited from acquisitions
and mergers. Integration of old and new technologies can be very expensive, and
planning the transition of the two security policies can be very complicated.
Leveraging the expertise of others does not specically mean hiring an expert.
Remember the policy for a specic enterprise system must be tailored to each orga-
nization, but the ISSMP should take advantage of the examples that have already
been proven successful by others. As previously mentioned, other security experts
have contributed their experiences, so ISSMPs do not have to make the same costly
mistakes made previously. ey have provided their knowledge, recommendations,
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.