Principles of Information Security 7E - Module 11

MODULE 11
Implementing Information
Security
Upon completion of this material, you should be able to:
1 Explain how an organization’s information security blueprint becomes a project
plan
Change is good. You
2 Explain the significance of the project manager’s role in the success of an infor- go first!
mation security project
—Dilbert (by Scott Adams)
3 Discuss the many organizational considerations that a project plan must address
4 Describe the need for professional project management for complex projects
5 Discuss technical strategies and models for implementing a project plan
6 List and discuss the nontechnical problems that organizations face in times of
rapid change
Opening Scenario
Kelvin Urich was preparing for the change control meeting that was about to start. His screen showed the slides he planned to
use with his detailed notes. He scanned through the slides one final time. During the meeting last week, the technical review
committee had approved his ideas, and now he was confident that the project plan he’d developed was complete, tight, and
well-ordered.
The series of change requests resulting from this project would keep the company’s technical analysts busy for months
to come, but he hoped that the scope and scale of the project, and the vast improvements it was sure to bring to the SLS
information security program, would inspire his colleagues. To help the project proceed smoothly, he had loaded his slides
and supporting documents with columns of tasks, subtasks, and action items, and he had assigned dates to every action step
and personnel to each required task. Everything was under control.
Kelvin started the online meeting software, activated his microphone and camera, and braced himself to start the virtual
meeting.
Naomi Jackson, the change control supervisor, connected a few minutes early. She greeted Kelvin with a wave. Everyone
attending had received the detailed report of planned changes the previous day; Naomi opened the list of planned change
items and shared them with the meeting. Charlie Moody connected next, also nodding to Kelvin on the screen.
Once the virtual room filled, Naomi said, “Time to get started.” The slide showing the planned changes highlighted the
first change control item for discussion. She said, “Item 742.”
418 Principles of Information Security
One of the members of the UNIX support team responded, “As planned,” meaning that the item, a routine maintenance
procedure for the corporate servers, would occur as scheduled.
Naomi continued down the list in numeric order. Most items received the response “As planned” from the sponsoring
team member. Occasionally, someone answered “Cancelled” or “Will be rescheduled,” but for the most part, the review of the
change items proceeded as usual until it came to the section with Kelvin’s information security change requests.
Naomi said, “Items 761 through 767. Kelvin Urich from the security team is present to discuss these items with the change
control group.” Naomi passed control of the shared screen to Kelvin.
Kelvin shared his opening slide with the meeting. He waited, a little nervously, until he felt everyone had registered the
material on the screen, and then began speaking: “I’m sure most of you are already aware of the information security upgrades
we’ve been working on for the past few months. We’ve created an overall strategy based on the revised policies that were
published last month and a detailed analysis of the threats to our systems. As the project manager, I’ve created what I think
is a very workable plan. The seven change requests on the list today are all network changes, and each is a top priority. In the
coming weeks, I’ll be sending each department head a complete list of all planned changes and the expected dates. Of course,
detailed change requests will be filed in advance for change control meetings, but each department can find out when any
item is planned by checking the master list. As I said, there are more changes coming, and I hope we can all work together to
make this a success.”
“Comments or questions?” asked Naomi. “Please use our standard virtual meeting protocols.”
Instantly, six virtual hands shot up on the participant list. All of them belonged to senior technical analysts. Kelvin realized
belatedly that none of these analysts were on the technical review committee that had approved his plan.
As he was running the session now, Kelvin said, “OK, Davey Martinez, I think you were first. Go ahead.”
Davey replied, “We should have been warned if we are going to have all this work dumped on us all at once.”
Kelvin replied, “Well, Davey, I guess this is the first chance we have had to tell you about it.” He continued, “Amy, you’re
next.” She replied, “We can’t make this happen on this schedule.”
Meanwhile, the chat window had erupted with several threads of comments. It seemed like everyone in the meeting
had started typing messages and replies at once. Amid the sudden chaos that had broken out during an otherwise orderly
meeting, it occurred to Kelvin that his plan might not be as simple as he’d thought. He braced himself—it was going to be a
very long afternoon.
Introduction To Information Security Implementation

Information security should be implemented into every major system in an organization. It should also be designed
into every system from inception and through all phases of development and deployment. As organizations continue to
make the transition to cloud-based services and application delivery, the need for information security that is designed
into systems from inception becomes even more important. One approach for implementing information security into
an organization’s information systems is to ensure that security is a fundamental part of the organization’s systems
development life cycle (SDLC). To understand how security is integrated into the systems development life cycle, you
must first understand the foundations of systems development.
Each organization has a unique set of needs when it comes to developing information (and security) systems.
The organization’s culture will dictate the nature and types of systems development activities that will be used. Many
organizations do not develop a significant proprietary system, choosing instead to
systems development use off-the-shelf applications or work with other approaches that specialize in the
life cycle (SDLC) development and deployment of information systems. When organizations need to
A methodology for the design and develop systems in-house, they can choose from a variety of approaches that have
implementation of an information
emerged over time. The traditional approach to software development (discussed in
system, which may contain dif-
ferent phases depending on the the next section) has given rise to several variations, including RAD, JAD, Agile, and
methodology deployed, but gen- one of the newest approaches, DevOps.
erally addresses the investigation,
An early innovation in systems development was the inclusion of a broader cross
analysis, design, implementation,
and maintenance of an informa- section of the organization in the development process. Whereas in early develop-
tion system. ment projects, systems owners and software developers would collaborate to define
Module 11 Implementing Information Security 419
specifications and create systems, an approach known as joint application development (JAD) added members of the
management team from the supported business unit. In some cases, future users of the systems were also added.
Another innovation that often occurred with the JAD approach was to increase the speed at which requirements were
collected and software was prototyped, thus allowing more iterations in the design process—an approach called rapid
application development (RAD). This type of development later evolved into a combined approach known as the spiral
method, in which each stage of development was completed in smaller increments, with delivery of working software
components occurring more frequently and the software under development coming closer to its intended finished
state with each pass through the development process.
Taking the objectives of JAD and RAD even further is the collective approach to systems development known as
agile programming (AP) or extreme programming (XP), including aspects of systems development known as Kanban
and Scrum. As the need to reduce the time taken in the systems development cycle from gathering requirements to
testing software continued to evolve, even faster feedback cycles were required to reduce time to market and shorten
feature rollout times. When coupled with a need to better integrate the effort of the development team and the opera-
tions team to improve the functionality and security of applications, another model known as Development Operations
(DevOps) has begun to emerge.
DevOps focuses on integrating the need for the development team to provide iterative and rapid improvements
to system functionality and the need for the operations team to improve security and minimize the disruption from
software release cycles. By collaborating across the entire software/service life cycle, DevOps uses a continuous devel-
opment model that relies on systems thinking, short feedback loops, and continuous experimentation and learning.
Each of these approaches has its advantages and disadvantages, and each can be effective under the right circum-
stances. People who work in software development and some specialty areas of information security that support the
software assurance process must be conversant with each of these methodologies.
An emerging development has been called SecDevOps, which is short for security development operations and is
also known as DevSecOps. This is a process of using the DevOps methodologies noted earlier to bring an integrated
development and operations approach that is applied to the specification, creation, and implementation of security
control systems. SecDevOps is a set of best practices designed to allow organizations to build a culture of secure cod-
ing within their development approach that will bring the impact of DevOps development and deployment processes
to enable the secure deployment of application functionality. The planned outcome is to embed security inside the
development process as deeply as DevOps has enabled an operations mindset into program development.
You can learn more about DevSecOps in general and Microsoft’s support for that approach in the Azure develop-
i ment environment at https://azure.microsoft.com/en-us/solutions/devsecops/.
The Systems Development Life Cycle

An SDLC is a methodology for the design and implementation of an information system. Using a methodology ensures
a rigorous process with a clearly defined goal and increases the probability of success. Once a methodology has been
adopted, the key milestones are established, and a team is selected and made accountable for accomplishing the
project goals.
methodology
Traditional Development Methods A formal approach to solving a
problem based on a structured
The traditional SDLC approach consists of six general phases. If you have taken a sequence of procedures.
system analysis and design course, you may have been exposed to a model consist-
ing of a different number of phases. SDLC models range from three to 12 phases, all of waterfall model
which have been mapped into the six presented here. The waterfall model pictured A type of SDLC in which each phase
in Figure 11-1 illustrates that each phase begins with the results and information of the process “flows from” the
information gained in the previous
gained from the previous phase.
phase, with multiple opportunities
At the end of each phase of the traditional SDLC comes a structured review or to return to previous phases and
reality check, during which the team determines if the project should be continued, make adjustments.
Deliverables:
Investigation Process, outcomes, goals, scope, costs & benefits,

budget & constraints, development team specifications
Analysis Issues with the current program/system, its
environment, requirements of the new system
Logical Design
Rev General program/system specifications (blueprint)
is
aris it pre
e o viou
r pr s Physical Design Detailed program/system specifications
ogr phas
ess e
is u s whe
(solutions) including resources and personnel
nsa n is
tisf s
act ues Implementation Feedback, testing, program/
ory
system acceptance
When the existing program/system is deemed
ineffective or inefficient, a new program/system is initiated Maintenance Performance measures,
& Change operational reporting
Figure 11-1 SDLC waterfall methodology
discontinued, outsourced, postponed, or returned to an earlier phase. This determination depends on whether the proj-
ect is proceeding as expected and whether it needs additional expertise, organizational knowledge, or other resources.
Once the system is implemented, it is maintained and modified over the remainder of its working life. Any infor-
mation systems implementation may have multiple iterations as the cycle is repeated over time. Only by constant
examination and renewal can any system, especially an information security program, perform up to expectations in
a constantly changing environment.
The following sections describe each phase of a traditional SDLC.1
Investigation
The first phase, investigation, is the most important. What problem is the system being developed to solve? The
investigation phase begins by examining the event or plan that initiates the process. During this phase, the objectives,
constraints, and scope of the project are specified. A preliminary cost-benefit analysis evaluates the perceived benefits
and their appropriate levels of cost. At the conclusion of this phase and at every phase afterward, a process will be
undertaken to assess economic, technical, and behavioral feasibilities and ensure that implementation is worth the
organization’s time and effort.
Analysis
The analysis phase begins with the information gained during the investigation phase. This phase consists primarily
of assessments of the organization, its current systems, and its capability to support the proposed systems. Analysts
begin by determining what the new system is expected to do and how it will interact with existing systems. This phase
ends with documentation of the findings and an update of the feasibility analysis.
Logical Design
In the logical design phase, the information gained from the analysis phase is used to begin creating a systems solu-
tion for a business problem. In any systems solution, the first and driving factor must be the business need. Based on
the business need, applications are selected to provide needed services, and then the team chooses data support and
structures capable of providing the needed inputs. Finally, based on all of this, specific technologies are delineated
to implement the physical solution. The logical design, therefore, is the blueprint for the desired solution. The logical
design is implementation-independent, meaning that it contains no reference to specific technologies, vendors, or
products. Instead, it addresses how the proposed system will solve the problem at hand. In this stage, analysts gener-
ate estimates of costs and benefits to allow for a general comparison of available options. At the end of this phase,
another feasibility analysis is performed.
Physical Design
During the physical design phase, specific technologies are selected to support the alternatives identified and evalu-
ated in the logical design. The selected components are evaluated based on a make-or-buy decision—the option
to develop components in-house or purchase them from a vendor. Final designs integrate various components and
technologies. After yet another feasibility analysis, the entire solution is presented to the organization’s manage-
ment for approval.
Implementation
In the implementation phase, any needed software is created. Components are ordered, received, and tested. After-
ward, users are trained and supporting documentation created. Once all components are tested individually, they are
installed and tested as a system. A feasibility analysis is again prepared, and the sponsors are then presented with the
system for a performance review and acceptance test.
Maintenance and Change

The maintenance and change phase is the longest and most expensive of the process. This phase consists of the tasks
necessary to support and modify the system for the remainder of its useful life cycle. Even though formal development
may conclude during this phase, the life cycle of the project continues until the team determines that the process
should begin again from the investigation phase. At periodic points, the system is tested for compliance, and the fea-
sibility of continuance versus discontinuance is evaluated. Upgrades, updates, and patches are managed. As the needs
of the organization change, the systems that support the organization must also change. The people who manage and
support the systems must continually monitor their effectiveness in relation to the organization’s environment. When
a current system can no longer support the evolving mission of the organization, the system is retired from use and
ongoing maintenance stops. If the services provided by the retired system are still needed, a new project is planned
and implemented.
For more information on SDLCs, see Appendix E of Special Publication 800-64, Rev. 2, from the National Institute
i of Standards and Technology (NIST). The Web address is http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpub-
lication800-64r2.pdf. Although this is a “withdrawn” document that has been superseded, it is still useful to your
understanding of the methodologies used in the security of software development.
Software Assurance
Many of the information security issues facing modern information systems have their root cause in the software ele-
ments of the system. Secure systems require secure or at least securable software. The development of systems and
the software they use is often accomplished using a methodology, such as the SDLC described earlier. Many organiza-
tions recognize the need to include planning for security objectives in the SDLC they use to create systems, and have
established procedures to create software that is more capable of being deployed in a secure fashion. This approach
to software development is known as software assurance, or SA. SA attempts to intentionally create software free of
vulnerabilities and provide effective, efficient software that users can deploy with confidence.
Organizations are increasingly working to build security into the SDLC to prevent security problems before they
begin. A national effort is under way to create a common body of knowledge focused on secure software develop-
ment. The U.S. Department of Defense launched a Software Assurance Initiative in 2003. This initial process was led
by Joe Jarzombek and was endorsed and supported by the Department of Homeland Security (DHS), which joined
the program in 2004. This program initiative resulted in the publication of the Software Assurance (SwA) Common
Body of Knowledge (CBK).2 A working group drawn from industry, government, and academia was formed to examine
two key questions:
1. What are the engineering activities or aspects of activities that are relevant to achieving secure software?
2. What knowledge is needed to perform these activities or aspects?
Based on the findings of this working group and a host of existing external doc- software assurance
uments and standards, the SwA CBK was developed and published to serve as a A methodological approach to the
development of software that seeks
guideline. While this work has not yet been adopted as a standard or even a policy
to build security into the develop-
requirement of government agencies, it serves as a strongly recommended guide to ment life cycle rather than address
developing more secure applications. it at later stages.
The SwA CBK, which is a work in progress, contains the following sections:
• Nature of Dangers
• Fundamental Concepts and Principles
• Ethics, Law, and Governance
• Secure Software Requirements
• Secure Software Design
• Secure Software Construction
• Secure Software Verification, Validation, and Evaluation
• Secure Software Tools and Methods
• Secure Software Processes
• Secure Software Project Management
• Acquisition of Secure Software
• Secure Software Sustainment3
The following sections provide insight into the stages that should be incorporated into the software SDLC.
Software Design Principles

Good software development should result in a finished product that meets all of its design specifications. Information
security considerations are a critical component of those specifications, though that has not always been true. Leaders
in software development J. H. Saltzer and M. D. Schroeder note that:
The protection of information in computer systems [. . . and] the usefulness of a set of protection
mechanisms depends upon the ability of a system to prevent security violations. In practice,
producing a system at any level of functionality that actually does prevent all such unauthorized
acts has proved to be extremely difficult. Sophisticated users of most systems are aware of at
least one way to crash the system, denying other users authorized access to stored information.
Penetration exercises involving a large number of different general-purpose systems all have shown
that users can construct programs that can obtain unauthorized access to information stored
within. Even in systems designed and implemented with security as an important objective, design
and implementation flaws provide paths that circumvent the intended access constraints. Design
and construction techniques that systematically exclude flaws are the topic of much research
activity, but no complete method applicable to the construction of large general-purpose systems
exists yet.4
This statement could be about software development in the early part of the 21st century, but it actually dates
back to 1975, before information security and software assurance became critical factors for many organizations. In
the same article, the authors provide insight into what are now commonplace security principles:
• Economy of mechanism: Keep the design as simple and small as possible.

• Fail-safe defaults: Base access decisions on permission rather than exclusion.
• Complete mediation: Every access to every object must be checked for authority.
• Open design: The design should not be secret, but rather depend on the possession of keys or passwords.
• Separation of privilege: Where feasible, a protection mechanism should require two keys to unlock, rather
than one.
• Least privilege: Every program and every user of the system should operate using the least set of privileges
necessary to complete the job.
• Least common mechanism: Minimize mechanisms (or shared variables) common to more than one user
and depended on by all users.
• Psychological acceptability: It is essential that the human interface be designed for ease of use, so that
users routinely and automatically apply the protection mechanisms correctly.5
Many of the common problems associated with programming approaches that don’t follow the software assurance
methodology are discussed in Module 2.
For more information on software assurance and the national effort to develop an SA common body of knowl-
i edge and supporting curriculum, visit https://buildsecurityin.us-cert.gov/dhs/dhs-software-assurance-resources.
The NIST Approach to Securing the SDLC

NIST has adopted a simplified SDLC for its approach, based on five phases: initiation, development/acquisition, imple-
mentation/assessment, operation/maintenance, and disposal. These loosely map to the SDLC approach described
earlier, as shown in Table 11-1.
Each phase of the SDLC should include consideration for the security of the system being assembled as well as the
information it uses. Whether the system is custom-made and built from scratch, purchased and then customized, or
commercial off-the-shelf software (COTS), the implementing organization is responsible for ensuring its secure use. This
means that each implementation of a system is secure and does not risk compromising the confidentiality, integrity,
and availability of the organization’s information assets. The following section, adapted from NIST Special Publication
800-64, Rev. 2, provides an overview of the security considerations for each phase of the SDLC.
While the following section offers advice from NIST expressed in the context of traditional methods (the water-
fall methodology), note that these principles are equally valid when the effort uses RAD, JAD, Agile, XP, and other
approaches to systems development. Development projects that make use of nontraditional development methodolo-
gies must still build in the requirements dictated by sound security practices. Software development should always
include meeting security requirements.
To be most effective, information security must be integrated into the SDLC from system inception. Early
integration of security in the SDLC enables agencies to maximize return on investment in their security
programs, through:
• Early identification and mitigation of security vulnerabilities and misconfigurations, resulting in lower cost
of security control implementation and vulnerability mitigation;
• Awareness of potential engineering challenges caused by mandatory security controls;
• Identification of shared security services and reuse of security strategies and tools to reduce development
cost and schedule while improving security posture through proven methods and techniques; and
• Facilitation of informed executive decision making through comprehensive risk management in a timely
manner. [. . .]
Initiation
During this first phase of the development life cycle, security considerations are key to diligent and early
integration, thereby ensuring that threats, requirements, and potential constraints in functionality and
integration are considered. At this point, security is looked at more in terms of business risks with input
from the information security office. For example, an agency may identify a political risk resulting from
Table 11-1 Comparison of Waterfall and NIST SDLC Phases
Waterfall SDLC Phase Equivalent NIST SDLC Phase

Investigation Initiation
Analysis
Logical Design Development/Acquisition
Physical Design
Implementation Implementation/Assessment
Maintenance and Change Operation/Maintenance
Disposal
a prominent Web site being modified or made unavailable during a critical business period, resulting in
decreased trust by citizens.
Key security activities for this phase include:
• Initial delineation of business requirements in terms of confidentiality, integrity, and availability;

• Determination of information categorization and identification of known special handling requirements
to transmit, store, or create information such as personally identifiable information; and
• Determination of any privacy requirements.
Early planning and awareness will result in cost and time saving through proper risk management
planning. Security discussions should be performed as part of (not separately from) the development
project to ensure solid understandings among project personnel of business decisions and their risk
implications to the overall development project. [. . .]
These activities and their related outputs are illustrated in Figure 11-2. The key aspect of this illustration is the align-
ment of the system design to enterprise architecture (EA) and information assurance (IA) design goals.
Figure 11-2 Relating security considerations in the Initiation phase

Source: NIST SP 800-64 Rev. 2: “Security Considerations in the System Development Life Cycle.”
Development/Acquisition
This section addresses security considerations unique to the second SDLC phase. Key security activities
for this phase include:
• Conduct the risk assessment and use the results to supplement the baseline security controls;
• Analyze security requirements;
• Perform functional and security testing;
• Prepare initial documents for system certification and accreditation; and
• Design security architecture.
Although this section presents the information security components in a sequential top-down manner,
the order of completion is not necessarily fixed. Security analysis of complex systems will need to be
iterated until consistency and completeness is achieved. [. . .]
Figure 11-3 Relating security considerations in the Development/Acquisition

phase
These activities and their related outputs are illustrated in Figure 11-3.
Implementation/Assessment
Implementation/Assessment is the third phase of the SDLC. During this phase, the system will be
installed and evaluated in the organization’s operational environment.

• Integrate the information system into its environment;
• Plan and conduct system certification activities in synchronization with testing of security controls; and
• Complete system accreditation activities. [. . .]
Note that the Certification and Authorization (C&A) approach to systems formerly used by the federal government
has evolved into a comprehensive Risk Management Framework (RMF). As such, the performance of a risk assessment
on the system under development would replace the C&A process. These activities and their related outputs are illus-
trated in Figure 11-4. The POA&M in the figure refers to a plan of action and milestones (POA&M), which is a document
that identifies tasks to be accomplished.
Operations and Maintenance

Operations and Maintenance is the fourth phase of the SDLC. In this phase, systems are in place
and operating, enhancements and/or modifications to the system are developed and tested, and
hardware and/or software is added or replaced. The system is monitored for continued performance
in accordance with security requirements and needed system modifications are incorporated. The
operational system is periodically assessed to determine how the system can be made more effective,
secure, and efficient. Operations continue as long as the system can be effectively adapted to respond
to an organization’s needs while maintaining an agreed-upon risk level. When necessary modifications
or changes are identified, the system may reenter a previous phase of the SDLC.
Figure 11-4 Relating security considerations in the Implementation/

Assessment phase

• Conduct an operational readiness review;
• Manage the configuration of the system;
• Institute processes and procedures for assured operations and continuous monitoring of the information
system’s security controls; and
• Perform reauthorization as required. [. . .]
These activities and their related outputs are illustrated in Figure 11-5. Note that the CCB indicated in this figure
is the change control board, the organizational unit that coordinates changes to systems across the organization.
Figure 11-5 Relating security considerations in the Operations/Maintenance phase

Disposal
Disposal, the final phase in the SDLC, provides for disposal of a system and closeout of any contracts
in place. Information security issues associated with information and system disposal should be
addressed explicitly. When information systems are transferred, become obsolete, or are no longer
usable, it is important to ensure that government resources and assets are protected.
Usually, there is no definitive end to a system. Systems normally evolve or transition to the next
generation because of changing requirements or improvements in technology. System security plans
should continually evolve with the system. Much of the environmental, management, and operational
information should still be relevant and useful in developing the security plan for the follow-on
system.
The disposal activities ensure the orderly termination of the system and preserve the vital information
about the system so that some or all of the information may be reactivated in the future, if necessary.
Particular emphasis is given to proper preservation of the data processed by the system so that the
data is effectively migrated to another system or archived in accordance with applicable records
management regulations and policies for potential future access.

• Building and executing a disposal/transition plan;
• Archival of critical information;
• Sanitization of media; and
• Disposal of hardware and software.6
These activities and their related outputs are illustrated in Figure 11-6.
Figure 11-6 Relating security considerations in the Disposal phase

It is imperative that information security be designed into a system from its inception, rather than being added
during or after the implementation phase. Information systems that were designed with no security functionality, or
with security functions added as an afterthought, often require constant patching, updating, and maintenance to pre-
vent risk to the systems and information. A well-known adage holds that “an ounce of prevention is worth a pound of
cure.” With this in mind, organizations are moving toward more security-focused development approaches, seeking
to improve not only the functionality of existing systems but consumer confidence in their products. In early 2002,
Microsoft effectively suspended development work on many of its products to put its OS developers, testers, and pro-
gram managers through an intensive program that focused on secure software development. It also delayed release of
its flagship server operating system to address critical security issues. Many other organizations followed Microsoft’s
lead in putting security into the development process. Since that time, Microsoft has developed its own Security Devel-
opment Lifecycle, which uses a seven-phase, 17-step methodology that culminates in an executed incident response
plan, as shown in Figure 11-7.7
Training Requirements Design Implementation Verification Release Response
Establish security Establish design Use approved Dynamic Incident

requirements requirements tools analysis response plan
Core security Create quality Analyze attack Deprecate unsafe Fuzz Final security
Execute incident
training gates/bug bars surface functions testing review
response plan
Security and privacy Threat Static Attack Release

risk assessment modeling analysis surface review archive
Figure 11-7 Microsoft’s SDL8

Source: Microsoft. Used with permission.
For more information on the Microsoft SDL, visit the Web site at www.microsoft.com/
i en-us/securityengineering/sdl/.
Information Security Project Management

First and foremost, an information security project manager must realize that implementing an information security
project takes time, effort, and a great deal of communication and coordination. This module continues the discussion
from Module 3 and explains how to successfully execute the information security blueprint. In general, the implemen-
tation phase is accomplished by changing the configuration and operation of the organization’s information systems
to make them more secure. It includes changes to the following:
• Procedures (for example, through policy)
• People (for example, through training)
• Hardware (for example, through technology like firewalls)
• Software (for example, through encryption)
• Data (for example, through classification)
As you may recall from earlier modules, effective planning for information security involves collecting informa-
tion about an organization’s objectives, its technical architecture, and its information security environment. These
elements are used to form the information security blueprint, which is the founda-
project management tion for protecting the confidentiality, integrity, and availability of the organization’s
The process of identifying and con-
information. The realization of these objectives will require an organization to define
trolling the goals, objectives, tasks,
scheduling, and resources of a and execute a project. Successful projects require the application of a management
project. specialty known as project management.
During the implementation phase, the organization translates its blueprint for project plan
information security into a project plan. The project plan instructs the people who The documented instructions for
are executing the implementation phase. These instructions focus on the security participants and stakeholders in a
project that provide details on its
control changes needed to improve the security of the hardware, software, proce-
goals, objectives, tasks, scheduling,
dures, data, and people that make up the organization’s information systems. The and resource management.
information security project plan as a whole must describe how to acquire and
implement the needed security controls and create a setting in which those controls
achieve the desired outcomes.
As the opening scenario of this module illustrates, organizational change is not easily accomplished. The follow-
ing sections discuss the issues a project plan must address, including project leadership; managerial, technical, and
budgetary considerations; and organizational resistance to the change.
The major steps in executing the project plan are as follows:
• Planning the project
• Supervising tasks and action steps
• Wrapping up
The project plan can be developed in any number of ways. Each organization has to determine its own project
management methodology for IT and information security projects. Whenever possible, information security proj-
ects should follow the organization’s project management practices. Many organizations now make use of a project
office—a centralized resource to maximize the benefits of a standardized approach to project management. One such
benefit is the leveraging of common project management practices across the organization to enable reallocation of
resources without confusion or delays.
Developing the Project Plan

Planning for the implementation phase requires the creation of a detailed project plan, which is often assigned either
to a project manager or the project champion. This person manages the project and delegates parts of it to other
decision makers. Often, the project manager is from the IT community of interest because most other employees lack
the requisite information security background, management authority, and technical
knowledge.
The project plan can be created using a simple planning tool such as the work work breakdown
breakdown structure (WBS). An example is shown in Table 11-2. To use the WBS structure (WBS)
approach, you first break down the project plan into its major tasks. The major A list of the tasks to be accom-
plished in a project, the skill sets
project tasks are placed into the WBS, along with the following attributes for each:
or individual employees needed
• Work to be accomplished (activities and deliverables) to perform the tasks, the start and
end dates for tasks, the estimated
• The people or skill sets assigned to perform the task resources required, and the depen-
• Start and end dates for the task, when known dencies among tasks.
• Amount of effort required for completion, in hours or work days
• Estimated capital expenses for the task
• Estimated noncapital expenses for the task
• Identification of dependencies between and among tasks
Each major task in the WBS is then further divided into either smaller tasks (subtasks) or specific action steps.
For the sake of simplicity, the sample project plan outlined in the table and described in the following sections divides
each major task into action steps. In an actual project plan, major tasks are often much more complex and must be
divided into subtasks before action steps can be identified and assigned to a specific person or skill set. Given the
variety of possible projects, there are few formal guidelines for determining the appropriate level of detail—that is, the
level at which a task or subtask should become an action step. However, one hard-and-fast rule can help you make this
determination: A task or subtask becomes an action step when it can be completed by one person or skill set and has
a single deliverable. (A deliverable is a completed document or program module that can serve either as the beginning
point for a later task or become an element in the finished project.)
Table 11-2 Example Work Breakdown Structure for a Project Plan
Estimated Estimated Estimated

Start (S) & Effort in Capital Noncapital
Task or Subtask Resources End (E) Dates Hours Expense Expense Dependencies
1. Contact field office Network S: 9/22 2 $0 $200
and confirm network architect
E: 9/22
assumptions
2. Purchase standard
firewall hardware
2.1 Order firewall through Network S: 9/23 1 $0 $100 1
purchasing group architect
E: 9/23
2.2 Order firewall from Purchasing S: 9/24 2 $4,500 $100 2.1
manufacturer group
E: 9/24
2.3 Firewall delivered Purchasing E: 10/3 1 $0 $50 2.2
group
3. Configure firewall Network S: 10/3 8 $0 $800 2.3
architect
E: 10/5
4. Package and ship Student S: 10/6 2 $0 $85 3
firewall to field office intern
E: 10/15
5. Work with local technical Network S: 10/22 6 $0 $600 4
resource to install and architect
E: 10/31
test firewall
6. Penetration test
6.1 Request penetration Network S: 11/1 1 $0 $100 5
test architect
E: 11/1
6.2 Perform penetration Penetration S: 11/2 9 $0 $900 6.1
test test team
E: 11/12
6.3 Verify that results of Network S: 11/13 2 $0 $200 6.2
penetration test were architect
E: 11/15
passing
7. Get remote office Network S: 11/16 8 $0 $800 6.2
sign-off and update all architect
E: 11/30
network drawings and
documentation
The WBS can be prepared with a simple spreadsheet program. The use of more
projectitis complex project management software often leads to projectitis, in which the proj-
A situation in project planning in ect manager spends more time working with the project management software than
which a project manager spends accomplishing meaningful project work. Recall Kelvin’s slides from the opening sce-
more time manipulating and adjust-
ing aspects of the project manage-
nario, which were loaded with dates and details. His case of projectitis led him to
ment software than accomplishing develop an elegant, detailed plan before gaining consensus for the required changes.
meaningful project work. Because he was new to project management, he did not realize that simpler software
tools could help him focus on organizing and coordinating with the project team.
Work to Be Accomplished
The work to be accomplished encompasses both activities and deliverables. Ideally, the project planner provides a
label to identify the task and provides a thorough description for the task. The description should be complete enough
to avoid ambiguity during the tracking process later, yet should not be so detailed as to make the WBS unwieldy. For
instance, if the task is to write firewall specifications for the preparation of a request for proposal (RFP), the planner
should note that the deliverable is a specification document suitable for distribution to vendors.
Assignments
The project planner should describe the skills or personnel, often referred to as resources, needed to accomplish the
task. The naming of individual employees should be avoided in early planning efforts, a rule Kelvin ignored when
he named employees for every task in the first draft of his project plan. Instead of making individual assignments,
the project plan should focus on organizational roles or known skill sets. For example, if any of the engineers in
the networks group can write the specifications for a router, the assigned resource would be noted as “network
engineer” in the WBS. As planning progresses, however, specific tasks and action steps should be assigned to
individual employees. For example, when only the manager of the networks group can evaluate responses to the
RFP and make an award for a contract, the project planner should assign the network manager as the resource for
this task.
Start and End Dates

In the early stages of planning, the project planner should attempt to specify completion dates only for major project
milestones. For example, the date for sending the final RFP to vendors is a milestone because it signals that all RFP
preparation work is complete. Assigning too many dates to too many tasks early in the planning process exacerbates
projectitis. This is another mistake Kelvin made, and was a significant cause of the resistance he faced from his cowork-
ers. Planners can avoid this pitfall by assigning only key or milestone start and end dates early in the process. Later,
planners may add start and end dates as needed.
Amount of Effort
Planners need to estimate the effort required to complete each task, subtask, or action step. Estimating effort hours for
technical work is a complex process. Even when an organization has formal governance, technical review processes,
and change control procedures, it is always good practice to ask the people who are most familiar with the tasks to
make these estimates. After these estimates are made, the people assigned to action steps should review the estimated
effort hours, understand the tasks, and agree with the estimates. Had Kelvin collaborated with his peers more effec-
tively and adopted a more flexible planning approach, much of the resistance he encountered in the meeting would
not have emerged.
Estimated Capital Expenses

Planners need to estimate the capital expenses required for the completion of each task, subtask, or action item.
While each organization budgets and expends capital according to its own established procedures, most differentiate
between capital outlays for durable assets and expenses for other purposes. For example, a firewall device that costs
$5,000 may be a capital outlay for an organization, but it might not consider a $5,000 software package to be a capital
outlay because its accounting rules classify all software as expense items, regardless of cost.
Estimated Noncapital Expenses

Planners need to estimate the noncapital expenses for the completion of each task, subtask, or action item. In busi-
ness, capital expenses are those for revenue-producing projects that are expected to yield a return on investment,
usually more than a year in the future. Noncapital expenses do not meet the criteria for capital expenditures. Some
organizations require that current expenses for a project include a recovery charge for staff time, while others
exclude employee time and consider only contract or consulting time used by the project as a noncapital expense.
As mentioned earlier, it is important to determine the cost accounting practices for which the plan is to be used. For
example, at some companies, a project to implement a firewall may charge only the costs of the firewall hardware
as capital and consider all costs for labor and software as expense; the hardware element is regarded as a durable
good that has a lifespan of many years. Another organization might use the aggregate of all cash outflows associated
with the implementation as the capital charge and make no charges to the expense category for everything needed
to complete the project. The justification behind using this aggregate of all costs—which might include charges
for items like hardware, labor, and freight—is that the newly implemented capability is expected to last for many
years and is an improvement to the organization’s infrastructure. A third company may charge the whole project
as expense if the aggregate amount falls below a certain threshold, under the theory that small projects are a cost
of ongoing operations.
Task Dependencies
Whenever possible, planners should note the dependencies of other tasks or action steps on the one at hand, including
task predecessors and successors. Predecessors are tasks that precede the current task, and successors are tasks that
come after the current task and are dependent upon it. Multiple types of dependencies can exist, but such details are
typically covered in courses on project management and are beyond the scope of this text.
A process for developing a simple WBS-style project plan is provided in the following steps. In this example, a small
information security project has been assigned to Jane Smith for planning. The project is to design and implement a
firewall for a small office. The hardware is a standard organizational product and will be installed at a location that
already has a network connection.
Jane’s first step is to list the major tasks:
1. Contact field office and confirm network assumptions.
2. Purchase standard firewall hardware.
3. Configure firewall.
4. Package and ship firewall to field office.
5. Work with local technical resource to install and test firewall.
6. Coordinate vulnerability assessment by penetration test team.
7. Get remote office sign-off and update all network drawings and documentation.
After all the people involved review and refine Jane’s plan, she revises it to add more dates to the tasks listed, as
shown in Table 11-2.
For more information on project management certifications in the federal sector, visit www.fai.gov/certification/
i program-and-project-managers-fac-ppm.
Project Planning Considerations

As the project plan is developed, adding detail is not always straightforward. The following sections discuss factors
that project planners must consider as they decide what to include in the work plan, how to break tasks into subtasks
and action steps, and how to accomplish the objectives of the project.
Financial Considerations
Regardless of an organization’s information security needs, the amount of effort that can be expended depends on the
available funds. A cost-benefit analysis (CBA), as described in Module 4, is typically prepared and must be reviewed
and verified prior to the development of the project plan. The CBA determines the impact that a specific technology
or approach can have on the organization’s information assets and what it may cost.
Each organization has its own approach to the creation and management of budgets and expenses. In many organiza-
tions, the information security budget is a subsection of the overall IT budget. In others, information security is a separate
budget category that may have the same degree of visibility and priority as the IT budget. Regardless of where informa-
tion security items are located in the budget, monetary constraints determine what can and cannot be accomplished.
Public organizations tend to be more predictable in their budget processes than private organizations because
the budgets of public organizations are usually the product of legislation or public meetings. This makes it difficult to
obtain additional funds once the budget is determined. Also, some public organizations rely on temporary or renew-
able grants for their budgets and must stipulate their planned expenditures when the grant applications are written. If
new expenses arise, funds must be requested via new grant applications. Also, grant expenditures are usually audited
and cannot be misspent. In addition, many public organizations must spend all budgeted funds within the fiscal
year—otherwise, the subsequent year’s budget is reduced by the unspent amount. As a result, these organizations
often conduct “spend-a-thons” at the end of the fiscal year. This is often the best time to acquire a remaining piece of
technology needed to complete the information security architecture.
Private (for-profit) organizations have budgetary constraints that are determined by the marketplace. When a for-
profit organization initiates a project to improve security, the funding comes from the company’s capital and expense
budgets. Each for-profit organization has different methods for determining its capital budget and its rules for manag-
ing capital spending and expenses. In almost all cases, however, budgetary constraints affect the planning and actual
expenditures for information security. For example, a preferred technology or solution may be sacrificed for a less
desirable but more affordable solution. The budget ultimately guides the information security implementation.
To justify the amount budgeted for a security project at either a public or for-profit organization, it may be use-
ful to benchmark expenses of similar organizations. Most for-profit organizations publish the components of their
expense reports. Similarly, public organizations must document how funds are spent. A savvy information security
project manager might find a number of similarly sized organizations with larger expenditures for security to justify
planned spending. While such tactics may not improve this year’s budget, they could improve future budgets. Ironi-
cally, attackers can also help information security project planners justify the information security budget. If attacks
successfully compromise secured information systems, management may be more willing to support the information
security budget.
Priority Considerations
In general, the most important information security controls in the project plan should be scheduled first. Budgetary
constraints may have an effect on the assignment of a project’s priorities. As you learned in Module 5, the implemen-
tation of controls is guided by the prioritization of threats and the value of the threatened information assets. A less
important control may be prioritized if it addresses a group of specific vulnerabilities and improves the organization’s
security posture to a greater degree than other high-priority controls.
Time and Scheduling Considerations

Time and scheduling can affect a project plan at dozens of points, including the time between ordering and receiving
a security control, which may not be immediately available; the time it takes to install and configure the control; the
time it takes to train the users; and the time it takes to realize the control’s return on investment. For example, if a
control must be in place before an organization can implement its electronic commerce product, the selection process
is likely to be influenced by the speed of acquisition and implementation of the various alternatives.
Staffing Considerations
The need for qualified, trained, and available personnel also constrains the project plan. An experienced staff is often
needed to implement technologies and to develop and implement policies and training programs. If no staff members
are trained to configure a new firewall, for example, the appropriate personnel must be trained or hired.
Procurement Considerations
There are often constraints on the selection of equipment and services—for example, some organizations require the
use of particular service vendors or manufacturers and suppliers. These constraints may limit which technologies can
be acquired. For example, in a recent budget cycle, the author’s lab administrator was considering selecting an auto-
mated risk analysis software package. The leading candidate promised to integrate everything, including vulnerability
scanning, risk weighting, and control selection. Upon receipt of the RFP, the vendor issued a bid to meet the desired
requirements for a staggering $75,000, plus a 10 percent annual maintenance fee. If an organization has an annual
information security budget of $30,000, it must eliminate a package like this from consideration. Also, consider the
chilling effect on innovation when an organization requires elaborate supporting documentation and complex bidding
for even small-scale purchases. Such procurement constraints, which are designed to control losses from occasional
abuses, may actually increase costs when the lack of operating agility is taken into consideration.
Organizational Feasibility Considerations

Whenever possible, security-related technological changes should be transparent to system users, but sometimes such
changes require new procedures—for example, additional authentication or validation. A successful project requires
that an organization be able to assimilate the proposed changes. New technologies sometimes require new policies,
employee training, and education. Scheduling training after the new processes are in place—and after the users have
had to deal with the changes without preparation—can create tension and resistance, and might undermine security
operations. Users who are untrained in a new technology may develop ways to work around unfamiliar security proce-
dures, and their bypassing of controls may create additional vulnerabilities. Conversely, users should not be prepared
so far in advance that they forget the new training techniques and requirements. The optimal time frame for training
is usually one to three weeks before the new policies and technologies come online.
Training and Indoctrination Considerations

The size of the organization and the normal conduct of business may preclude a large training program for new secu-
rity procedures or technologies. If so, the organization should conduct a phased-in or pilot implementation, such as
roll-out training for one department at a time. See the “Conversion Strategies” section later in the module for details
about various implementation approaches. When a project involves a change in policies, it may be sufficient to brief
supervisors on the new policy and assign them the task of updating end users in regularly scheduled meetings. Project
planners must ensure that compliance documents are also distributed and that all employees are required to read,
understand, and agree to the new policies.
Scope Considerations
The scope of any given project plan should be carefully reviewed and kept as small as possible, given the project’s
objectives. To control project scope, organizations should implement large information security projects in stages, as
in the bull’s-eye approach discussed later in this module.
For several reasons, the scope of information security projects must be evaluated and adjusted with care. First, in
addition to the challenge of handling many complex tasks at one time, the installation of information security controls
can disrupt the ongoing operations of an organization and may also conflict with existing controls in unpredictable
ways. For example, if you install a new packet-filtering router and a new application proxy firewall at the same time
and users are blocked from accessing the Web as a result, which technology caused the conflict? Was it the router, the
firewall, or an interaction between the two? Limiting the project scope to a set of manageable tasks does not mean that
the project should only allow change to one component at a time, but a good plan carefully considers the number of
tasks that are planned for the same time in a single department.
Recall from the opening scenario that all of Kelvin’s change requests are in the area of networking, where the
dependencies are particularly complex. If the changes in Kelvin’s project plan are not deployed exactly as planned, or
if unanticipated complexities arise, there could be extensive disruption to Sequential Label and Supply’s daily opera-
tions. For instance, an error in the deployment of the primary firewall rules could interrupt all Internet connectivity,
which might make detection and recovery from the error more difficult.
The Need for Project Management

Project management requires a unique set of skills and a thorough understanding of a broad body of specialized
knowledge. In the opening scenario, Kelvin’s inexperience as a project manager makes this all too clear. Realistically,
most information security projects require a trained project manager—a CISO or a skilled IT manager who is trained
in project management techniques. Even experienced project managers are advised to seek expert assistance when
needed—for example, when engaging in a formal bidding process to select advanced or integrated technologies or
outsourced services.
When projects are being implemented to support information security objectives, the project manager and others
associated with the project should have an appropriate skill set in security or prior experience with the topic. The need
for information security to be built into development efforts means that project leaders and other key participants
should understand the security environment.
Supervised Implementation
Although it is not an optimal solution, some organizations designate a champion from the general management com-
munity of interest to supervise the implementation of an information security project plan. In this case, groups of tasks
are delegated to individuals or teams from the IT and information security communities of interest. An alternative is
to designate a senior IT manager or the CIO of the organization to lead the implementation. In this case, the detailed
work is delegated to cross-functional teams.
The best solution is to designate a suitable person from the information security community of interest. In the final
analysis, each organization must find the project leadership that best suits its specific needs and the personalities and
politics of the organizational culture.
Executing the Plan gap analysis

Once a project is under way, it is managed using a process known as gap analysis The process of comparing mea-
sured results against expected
(also known as a negative feedback loop or cybernetic loop), which ensures that
results and then using the resulting
progress is measured periodically. When significant deviation occurs, corrective “gap” as a measure of project suc-
action is taken to bring the deviating task back into compliance with the project cess and as feedback for project
plan; otherwise, the project is revised in light of the new information. See Figure 11-8 management.
for an overview of this process.

Corrective action is taken in two basic situations: Either the estimate is flawed or
performance has lagged. When an estimate is flawed, as when the number of effort hours required is underestimated,
the plan should be corrected and downstream tasks updated to reflect the change. When performance has lagged—
for example, due to high turnover of skilled employees—corrective action may take the form of adding resources,
making longer schedules, or reducing the quality or quantity of the deliverable. Corrective action decisions are usually
expressed in terms of trade-offs. Often, a project manager can adjust one of the three following planning parameters
for the task being corrected:
• Effort and money allocated
• Elapsed time or scheduling impact
• Quality or quantity of the deliverable
When too much effort and money are being spent, you may decide to take more time to complete the project tasks
or to lower the deliverable’s quality or quantity. If the task is taking too long to complete, you should probably add
more resources in staff time or money or decrease the deliverable’s quality or quantity. If the quality of the deliverable
is inadequate, you must usually add more resources in staff time or money or take longer to complete the task. Of
course, there are complex dynamics among these variables, and these simplistic solutions do not serve in all cases,
but this simple trade-off model can help the project manager analyze available options.
Plan initiated
Current state assessed
Current state compared

to desired state as per
plan
Monitor and Yes Current =

periodically reassess Desired?
No
Develop gap analysis

remediation plan
Implement gap analysis

remediation plan and
reassess
Figure 11-8 Gap analysis

Project Wrap-Up
Project wrap-up is usually handled as a procedural task and assigned to a mid-level IT or information security man-
ager. These managers collect documentation, finalize status reports, and deliver a final report and a presentation at a
wrap-up meeting. The goal of the wrap-up is to resolve any pending issues, critique the overall project effort, and draw
conclusions about how to improve the process for the future.
i For more information on project management, visit the Project Management Institute’s Web site at www.pmi.org.
Security Project Management Certifications

For information security professionals who seek additional credentials and recognition for their project management
experience, some certifications are available.
GIAC Certified Project Manager

The SANS Institute offers a program that focuses on security professionals and managers who have project manage-
ment responsibilities and seek to demonstrate their mastery of project management methods and strategies.9 Can-
didates for the certification may either study on their own or enroll in the SANS IT Project Management course. The
program focuses on the following topic areas:
• Earned value technique (EVT)

• Leadership and management strategy
• Project communication management
• Project cost management
• Project human resource management
• Project integration management
• Project management framework and approach
• Project procurement management
• Project quality management
• Project risk management
• Project scope management
• Project stakeholder management
• Project time management10
EC-Council IT Security Project Management

The EC-Council offers the Certified Project Management program. This program focuses on the following topics:
• Introduction to project management
• Project scope and technology integration
• Project scheduling and time management
• Project cost and budget management
• Project sourcing and vendor management
• Project controls and quality assurance
• Project opportunity and risk management
• Project governance and team management
• Project visualization, analytics, and reporting
• Project stakeholder engagement and expectations management11
SIA Certified Security Project Manager

The Security Industry Association (SIA) is a consortium focused predominantly on physical security, but it also incor-
porates information security into its programs. It has a certification program called the Certified Security Project
Manager (CSPM), which signifies completion of its project manager course, a body of self-study, and the completion
of a final examination.
For more information on the SANS GIAC Certified Project Manager certification, visit www.giac.org/certification/
i certified-project-manager-gcpm. For more information on the EC-Council’s PM course, visit www.eccouncil.org. For
more information on the SIA certification, visit www.securityindustry.org.
PMI Project Management Professional

The Project Management Institute offers training and an examination for the very prestigious Project Management
Professional (PMP) certification. Many experts in project management believe the PMP is the premier certification in
the field and proves you have the specific skills and experience employers seek.
For more information on the Project Management Institute and the PMP certification, visit www.pmi.org/
i certifications/project-management-pmp.
Technical Aspects Of Implementation

Some aspects of the implementation process are technical and deal with the application of technology, while others
deal with the human interface to technical systems. The following sections discuss conversion strategies, prioritization
among multiple components, outsourcing, and technology governance.
Conversion Strategies
As the components of the new security system are planned, provisions must be made for the changeover from the
previous method of performing a task to the new method. Just like IT systems, information security projects require
careful conversion planning. This section discusses the four basic approaches for changing from an old system or
process to a new one. The approaches are illustrated in Figure 11-9.
Direct Changeover
Also known as going “cold turkey,” a direct changeover conversion strategy involves stopping the old method and
beginning the new one. This approach could be as simple as having employees follow the existing procedure one
week and then use a new procedure the next. Some cases of direct changeover are simple, such as requiring employ-
ees to begin using a new password with a stronger degree of authentication on an
announced date. Some may be more complex, such as requiring the entire company
to change procedures when the network team disables an old firewall and activates a
direct changeover
conversion strategy
new one. The primary drawback to the direct changeover approach is that if the new
The conversion strategy that
system fails or needs modification, users may be without services while the system’s involves stopping the old system
bugs are worked out. Complete testing of the new system in advance of the direct and starting the new one without
changeover reduces the probability of such problems. any overlap.
Direct Old system New system
Phased Old system New system
Pilot Old system New system
Old system
Parallel
New system
Figure 11-9 Conversion strategies

phased Phased Implementation

implementation A phased implementation conversion strategy is the most common and involves a
conversion strategy
measured rollout of the planned system, with only part of the system being brought
involves a measured rollout of the
out and disseminated across an organization before the next piece is implemented.
planned system; only part of the For example, this could mean that the security group implements only a small por-
system is brought out and dissemi- tion of the new security profile, giving users a chance to get used to it and resolving
nated across an organization before
issues as they arise. This is usually the best approach to security project imple-
the next piece is implemented.
mentation. As another example, if an organization seeks to update both its VPN and
IDPS systems, it may first introduce the new VPN solution that employees can use
pilot implementation to connect to the organization’s network while they’re traveling. Each week another
conversion strategy
department will be allowed to use the new VPN, with this process continuing until all
departments are using the new approach. Once the new VPN has been phased into
involves implementing the entire
system into a single office, depart- operation, revisions to the organization’s IDPS can begin.
ment, or division and dealing with
issues that arise before expanding Pilot Implementation
to the rest of the organization.
In a pilot implementation conversion strategy, the entire security system is put in
place in a single office, department, or division before expanding to the rest of the
parallel operations organization. The pilot implementation works well when an isolated group can serve
conversion strategy as the “guinea pig,” which prevents any problems with the new system from dramati-
The conversion strategy that cally interfering with the performance of the organization as a whole. The operation
involves running the new system
concurrently with the old system. of a research and development group, for example, may not affect the real-time oper-
ations of the organization and could assist security in resolving issues that emerge.
bull’s-eye model Parallel Operations

A method for prioritizing a program
The parallel operations conversion strategy involves running two systems con-
of complex change that requires
issues to be addressed from the currently; in terms of information systems, it might involve running two firewalls
general to the specific and focuses concurrently, for example. Although this approach is complex, it can reinforce an
on systematic solutions instead of
organization’s information security by allowing the old system(s) to serve as a
individual problems.
backup for the new systems if they fail or are compromised. Drawbacks usually
include the need to deal with both systems and maintain both sets of procedures.
The Bull’s-Eye Model

A proven method for prioritizing a program of complex change is the bull’s-eye model. This methodology, which
goes by many different names and has been used by many organizations, requires that issues be addressed from the
general to the specific and that the focus be on systematic solutions instead of individual problems. The increased
capabilities—that is, increased expenditures—are used to improve the information security program in a systematic
and measured way. As presented here and illustrated in Figure 11-10, the approach relies on a process of project plan
evaluation in four layers:
1. Policies—This is the outer, or first, ring in the bull’s-eye diagram. The critical importance of policies
has been emphasized throughout this textbook, particularly in Module 3. The foundation of all effective
information security programs is sound information security policy and information technology policy.
Because policy establishes the ground rules for the use of all systems and describes what is appropriate
and inappropriate, it enables all other information security components to function correctly. When
deciding how to implement complex changes and choose from conflicting options, you can use policy to
clarify what the organization is trying to accomplish with its efforts.
2. Networks—In the past, most information security efforts focused on this layer, so until recently,
information security was often considered synonymous with network security. In today’s computing
environment, implementing information security is more complex because networking infrastructure
often comes into contact with threats from the public network. If an organization is new to the Internet
and examines its policy environment to define how the new company networks should be defended, it will
soon find that designing and implementing an effective DMZ is the primary way to secure those networks.
Policies
Networks
Systems
Applications
Figure 11-10 The bull’s-eye model
Secondary efforts in this layer include providing the necessary authentication and authorization when
allowing users to connect over public networks to the organization’s systems.
3. Systems—Many organizations find that the problems of configuring and operating information systems in
a secure fashion become more difficult as the number and complexity of these systems grow. This layer
includes computers used as servers and desktop computers and systems used for process control and
manufacturing systems.
4. Applications—The layer that receives attention last deals with the application software systems used by
the organization to accomplish its work. This includes packaged applications, such as office automation
and e-mail programs, as well as high-end enterprise resource planning (ERP) packages that span the
organization. Custom application software developed by the organization for its own needs is also included.
By reviewing the information security blueprint and the current state of the organization’s information security
efforts in terms of these four layers, project planners can determine which areas require expanded capabilities. The
bull’s-eye model can also be used to evaluate the sequence of steps taken to integrate parts of the information security
blueprint into a project plan. As suggested by its bull’s-eye shape, this model dictates the following:
• Until sound and usable IT and information security policies are developed, communicated, and enforced, no
additional resources should be spent on other controls.
• Until effective network controls are designed and deployed, all resources should go toward achieving that
goal, unless resources are needed to revisit the policy needs of the organization.
• After policies and network controls are established, implementation should focus on the information, process,
and manufacturing systems of the organization. Until there is well-informed assurance that all critical systems
are being configured and operated in a secure fashion, all resources should be spent on reaching that goal.
• Once there is assurance that policies are in place, networks are secure, and systems are safe, attention should
move to assessing and remediating the security of the organization’s applications. This is a complicated and
vast area of concern for many organizations, and most neglect to analyze the impact of information security
on existing systems and their own proprietary systems. As in all planning efforts, attention should be paid to
the most critical applications first.
To Outsource or Not
Not every organization needs to develop an information security department or program of its own. Just as some
organizations outsource part or all of their IT operations, so too can organizations outsource their information security
programs. The expense and time required to develop an effective information security program may be beyond the
means of some organizations, so it may be in their best interest to hire professional services to help their IT depart-
ments implement such a program.
When an organization outsources most or all of its IT services, information security should be part of the contract
arrangement with the supplier. Organizations that handle most of their own IT operations may choose to outsource
the more specialized information security functions. Small and medium-sized organizations often hire outside consul-
tants for penetration testing and information security program audits. Organizations of all sizes frequently outsource
network monitoring functions to make certain that their systems are adequately secured and to gain assistance in
watching for attempted or successful attacks.
For an interesting article on outsourcing security, visit the Web page of renowned security consultant and author
i Bruce Schneier at https://www.schneier.com/essays/archives/2002/01/the_case_for_outsour.html.
Technology Governance and Change Control

Other factors that determine the success of an organization’s IT and information security programs are technology
governance and change control. Governance was covered in detail in Module 3.
Technology governance guides how frequently technical systems are updated
technology
and how technical updates are approved and funded. Technology governance
governance
also facilitates communication about technical advances and issues across the
A process that organizations use
to manage the effects and costs of organization.
technology implementation, inno- Medium-sized and large organizations deal with the impact of technical change
vation, and obsolescence. on their operations through a change control process. By managing the process of
change, the organization can do the following:
change control
• Improve communication about change across the organization.
A method of regulating the modifi-
cation of systems within the organ-
• Enhance coordination between groups within the organization as change is
ization by requiring formal review scheduled and completed.
and approval for each change. • Reduce unintended consequences by having a process to resolve conflict
and disruption that change can introduce.
• Improve quality of service as potential failures are eliminated and groups work together.
• Assure management that all groups are complying with the organization’s policies for technology governance,
procurement, accounting, and information security.
Effective change control is an essential part of the IT operation in all but the smallest organizations. The informa-
tion security group can also use the change control process to ensure that the organization follows essential process
steps that protect confidentiality, integrity, and availability when systems are upgraded across the organization.
The Center for Internet Security’s Critical Security Controls

To provide guidance for the implementation of security controls in the organization, the Center for Internet Security
(CIS) operates the Multi-State Information Sharing & Analysis Center (MS-ISAC), which serves as a sponsor and host of
a concise, prioritized list of the most critical and widespread cyberattacks and a library of methods that can be used to
control them. The MS-ISAC was created in response to industry practices that have seen security standards and require-
ment frameworks come and go; it makes an effort to address the risks that organizations face when using enterprise
systems. These efforts often seem to devolve into a set of rote compliance reports to address past threats, resulting in
a diversion of resources that may have been better spent making actual improvements in the security posture to meet
evolving threats. This state of affairs was noted in 2008 by the U.S. National Security Agency (NSA), which undertook
an “offense must inform defense” approach that sought to enable the selection and implementation of controls based
on a prioritization model with an intention to block actual threats instead of generating compliance documentation.
The result was the emergence of a global consortium drawn from industry and government that became known as the
Critical Security Controls (the Controls). MS-ISAC was charged with a coordinating role in this process.
The CIS Controls sought to deliver functionality that focused on emerging advanced targeted threats, placing an
emphasis on practical control approaches. The Controls were offered in a framework that emphasized standardization
of approach and the use of automated techniques where possible, seeking to deliver a high degree of effectiveness and
an essential efficiency to operations. The Controls are recognized as a subset of the controls enumerated in NIST SP 800-
53 (currently in Draft Rev. 5) and are not intended to supplant the NIST directives, including the Cybersecurity Frame-
work developed in response to Executive Order 13636. The order directed federal agencies to take steps to improve
the security infrastructure of critical federal systems. One of those steps was the development and implementation
of the Cybersecurity Framework. The Controls are a means of implementing a smaller number of actionable controls
that deliver maximum results from a modest set of resource inputs using a structured list of priorities.
The Controls are informed by actual attacks and effective defenses, reflecting the knowledge of a broad range of
experts in both the public and private sectors. These experts include threat responders, threat analysts, vulnerability
finders, solution providers, defenders, policy makers, and users who work within government and academia as well
as industries such as power, defense, finance, transportation, consulting, security, and IT.
The Controls are the most effective set of technical measures available to detect, prevent, respond to, and mitigate
damage from attacks. The Controls work to block the initial compromise of systems and to prevent or disrupt further
attacks on already compromised machines.12
The CIS Controls from Version 7.1, which was released in 2019, are as follows:
Basic Controls
1. Inventory and Control of Hardware Assets

2. Inventory and Control of Software Assets
3. Continuous Vulnerability Management
4. Controlled Use of Administrative Privileges
5. Secure Configuration for Hardware and Software on Mobile Devices, Laptops, Workstations, and Servers
6. Maintenance, Monitoring, and Analysis of Audit Logs
Foundational Controls
7. E-mail and Web Browser Protections

8. Malware Defenses
9. Limitations and Control of Network Ports, Protocols, and Services
10. Data Recovery Capabilities
11. Secure Configuration for Network Devices such as Firewalls, Routers, and Switches
12. Boundary Defense
13. Data Protection
14. Controlled Access Based on the Need to Know
15. Wireless Access Controls
16. Account Monitoring and Control
Organizational Controls
17. Security Awareness and Training Program

18. Application Software Security
19. Incident Response and Management
20. Penetration Tests and Red Team Exercises.13
Nontechnical Aspects Of Implementation

Some aspects of information security implementation are not technical in nature but deal instead with the human
interface to technical systems. The sections that follow discuss the topics of creating a culture of change management
and considerations for organizations facing change.
The Culture of Change Management

The prospect of change, the familiar shifting to the unfamiliar, can cause employees to resist the change, either uncon-
sciously or consciously. Regardless of whether the changes are perceived as good or bad, employees tend to prefer
the old way of doing things. Even when employees embrace changes, the stress of actually making the changes and
adjusting to new procedures can increase the probability of mistakes or create vulnerabilities in systems. By under-
standing and applying some basic tenets of change management, project managers can lower employee resistance to
change and can even build resilience for it, thereby making ongoing change more palatable to the entire organization.
The basic foundation of change management requires people who are making the changes to understand that
organizations typically have cultures that represent their mood and philosophy. Disruptions to this culture must be
properly addressed and their effects minimized. One of the oldest models of change is the Lewin change model, which
consists of three simplistic stages:14
• Unfreezing—Thawing hard-and-fast habits and established procedures. Preparing the organization for upcom-
ing changes facilitates the implementation of new processes, systems, and procedures. Training and awareness
programs assist in this preparation.
• Moving—Transitioning between the old way and the new. The physical implementation of new methods, using
the strategies outlined earlier in this module, requires the organization to recognize the cessation of old ways
of work and reinforces the need to use the new methods.
• Refreezing—The integration of the new methods into the organizational culture. This integration is accom-
plished by creating an atmosphere in which the changes are accepted as the preferred way of accomplishing
the necessary tasks.
Considerations for Organizational Change

An organization can take steps to make its employees more amenable to change. These steps reduce resistance to
change at the beginning of the planning process and encourage members of the organization to be more flexible as
changes occur.
Reducing Resistance to Change from the Start

The level of resistance to change affects the ease with which an organization can implement procedural and managerial
changes. The more ingrained the existing methods and behaviors are, the more difficult it will probably be to make
the change. It’s best, therefore, to improve interactions between the affected members of the organization and project
planners in the early phases of an information security improvement project. These interactions can be improved
through a three-step process in which project managers communicate, educate, and involve.
Communication is the first and most critical step. Project managers must communicate with employees so they
know a new security process is being considered and that their feedback is essential to making it work. Project manag-
ers must also constantly update employees on the progress of the project’s changes and provide information on the
expected completion dates. This ongoing series of updates keeps the process from being a last-minute surprise and
primes people to accept the change more readily when it finally arrives.
At the same time, project managers must update and educate employees about exactly how the proposed changes
will affect them individually and within the organization. While detailed information may not be available in earlier
stages of a project plan, details that can be shared with employees may emerge as the project progresses. Education
also involves teaching employees to use the new systems once they are in place. As discussed earlier, this means
delivering high-quality training programs at the appropriate times.
Finally, project managers can reduce resistance to change by involving employees in the project plan. This means
getting key representatives from user groups to serve as members of the project development process, as illustrated
in the JAD methodology described earlier. Identifying a liaison between the IT team, information security subject mat-
ter experts, and the organization’s general population can serve the project team well in early planning stages, when
unforeseen problems with acceptance of the project may need to be addressed.
Developing a Culture That Supports Change

An ideal organization fosters resilience to change. This means the organization understands that change is a necessary
part of the culture and that embracing change is more productive than fighting it. To develop such a culture, the organ-
ization must successfully accomplish many projects that require change. A resilient culture can be either cultivated or
undermined by management’s approach. Strong management support for change, with a clear executive-level cham-
pion, enables the organization to recognize the necessity for change and its strategic importance. Weak management
support, with overly delegated responsibility and no champion, sentences the project to almost certain failure. In such
a case, employees sense the low priority assigned to the project and do not communicate with the development team
because the effort seems useless.
For a sample change management and control policy template, visit the ISO 27001 security Web page at
i www.iso27001security.com/ISO27k_Model_policy_on_change_management_and_control.docx.
Closing Scenario
Charlie looked across his desk at Kelvin, who was absorbed in the sheaf of handwritten notes from the meeting. Charlie had
asked Kelvin to come to his office and discuss the change control meeting from earlier that day.
“So what do you think?” Charlie asked.
“I think I was blindsided by a bus!” Kelvin replied. “I thought I had considered all the possible effects of the change in my
project plan. I tried to explain this, but everyone acted as if I had threatened their lives.”
“In a way you did, or you threatened their jobs, at least,” Charlie stated. “Some people believe that change is the enemy.”
“But these changes are important.”
“I agree,” Charlie said. “But successful change usually occurs in small steps. What’s your top priority?”
“All the items on this list are top priorities,” Kelvin said. “I haven’t even gotten to the second tier.”
“So what should you do to accomplish these top priorities?” Charlie asked.
“I guess I should reprioritize within my top tier, but what then?”
“The next step is to build support before the meeting, not during it,” Charlie said, smiling. “Never go into a meeting where
you haven’t done your homework, especially when other people in the meeting can reduce your chance of success.”
Discussion Questions
1. What project management tasks should Kelvin perform before his next meeting?
2. What change management tasks should Kelvin perform before his next meeting, and how do these tasks fit
within the project management process?
3. Had you been in Kelvin’s place, what would you have done differently to prepare for this meeting?
Ethical Decision Making

Kelvin has seven controls listed as the top tier of project initiatives. Suppose that at his next meeting with Charlie, he provides
a rank-ordered list of these controls with projected losses over the next 10 years for each if the controls are not completed.
Also, he has estimated the 10-year cost for developing, implementing, and operating each control. Kelvin has identified three
controls as being the most advantageous for the organization in his opinion. As he prepared the slides for the meeting with
Charlie, he “adjusted” most of the projected losses upward to the top end of the range estimate given by the consultant who
prepared the data. For the projected costs of his preferred controls, he chose to use the lowest end of the range provided by
the consultant.
1. Do you think Kelvin has had an ethical lapse by cherry-picking the data for his presentation?
2. Suppose that instead of choosing data from the range provided by the consultant, Kelvin simply chose better
numbers, based on his experience, in support of his favorite initiatives. Is this an ethical lapse?
3. Suppose Kelvin has a close friend who works for a firm that makes and sells software for a specific control objec-
tive on the list. When Kelvin prioritized the list of his preferences, he made detailed adjustments to the data pre-
sented so the specific control was at the top of the list. Kelvin planned to provide his friend with internal design
specifications and the assessment criteria to be used for vendor selection for the initiative. Has Kelvin committed
an ethical lapse?
Selected Readings
• Information Technology Project Management, 5th Edition, by Kathy Schwalbe. Course Technology. 2007. Boston.
• The PMI Project Management Fact Book, 2nd Edition, by the Project Management Institute. 2001. Newtown Square, PA.
• NIST SP 800-37, Rev. 1, “Guide for Applying the Risk Management Framework to Federal Information Systems: A
Security Life Cycle Approach.”
• NIST DRAFT SP 800-39, “Managing Risk from Information Systems: An Organizational Perspective.”
Module Summary
• Information security should be implemented in every major system. One approach is to ensure that security is
a part of the organization’s system development methodology. DevOps and SecDevOps are emerging acceler-
ated development models that merge development and operational skills.
• Software assurance is a methodological approach to the development of software that seeks to build security
into the development life cycle rather than address it at later stages.
• The implementation phase of the security systems development life cycle involves modifying the configuration
and operation of the organization’s information systems to make them more secure. Such changes include
those to procedures, people, hardware, software, and data. During the implementation phase, the organization
translates its blueprint for information security into a concrete project plan.
• Before developing a project plan, management should articulate and coordinate the organization’s information
security vision and objectives with the involved communities of interest.
• The major steps in executing the project plan are planning the project, supervising tasks and action steps
within the plan, and wrapping up the plan.
• Each organization determines its own project management methodology for IT and information security proj-
ects. Whenever possible, an organization’s information security projects should be in line with its project
management practices.
• Planning for the implementation phase involves the creation of a detailed project plan. The project plan can
be created by using a simple planning tool such as the work breakdown structure (WBS). The plan can be
prepared with a simple desktop PC spreadsheet program or with more complex project management software.
The WBS involves addressing major project tasks and their related attributes, including the following:
❍ Work to be accomplished (activities and deliverables)
❍ Individual employees or skill sets assigned to perform the task
❍ Start and end dates for the task, when known
❍ Amount of effort required for completion, in hours or days
❍ Estimated capital expenses for the task
❍ Estimated noncapital expenses for the task
❍ Identification of task interdependencies
• Constraints and considerations should be addressed when developing the project plan. Considerations include
those for finances, procurement, priority, time and scheduling, staffing, scope, organizational feasibility, train-
ing and indoctrination, change control, and technology governance.
• Organizations usually designate a professional project manager to lead a security information project. Alter-
natively, some organizations designate a champion from a senior level of general management or a senior IT
manager, such as the CIO.
• Once a project is under way, it can be managed to completion using a process known as a negative feedback
loop or cybernetic loop. This process involves measuring variances from the project plan and then taking
corrective action when needed.
• As the components of the new security system are planned, provisions must be made for the changeover from
the previous method of performing a task to the new method(s). The four common conversion strategies for
performing this changeover are as follows:
❍ Direct changeover
❍ Phased implementation
❍ Pilot implementation
❍ Parallel operations
• The bull’s-eye model is a proven method for prioritizing a program of complex change. Using this method,
the project manager can address issues from the general to the specific and focus on systematic solutions
instead of individual problems.
• When the expense and time required to develop an effective information security program is beyond the reach
of an organization, it should outsource the program to competent professional services.
• Technology governance is a complex process that an organization uses to manage the impacts and costs of
technology implementation, innovation, and obsolescence.
• The change control process is a method that medium-sized and large organizations use to deal with the impact
of technical change on their operations.
• As with any project, certain aspects of change must be addressed. In any major project, the prospect of moving
from the familiar to the unfamiliar can cause employees to resist change, consciously or unconsciously.
Review Questions
1. What is a methodology in the context of implement- 12. Why is it a good practice to delay naming
ing secure systems? specific people as resources early in the
2. What is a systems development life cycle (or planning process?
SDLC)? 13. What is a milestone, and why is it significant to
3. What is a project plan? List what a project plan can project planning?
accomplish. 14. Why is it good practice to assign start and end
4. What categories of constraints to project plan dates sparingly in the early stages of project
implementation are noted in the module? Explain planning?
each of them. 15. Who is the best judge of effort estimates for project
5. List and describe the three major steps in execut- tasks and action steps? Why?
ing the project plan. 16. Within project management, what is a dependency?
6. What is a work breakdown structure (WBS)? Is it What is a predecessor? What is a successor?
the only way to organize a project plan? 17. What is a negative feedback loop? How is it used to
7. What is projectitis? How is it cured or its impact keep a project in control?
minimized? 18. When a task is not being completed according to
8. List and define the common attributes of tasks the plan, what two circumstances are likely to be
within a WBS. involved?
9. How does a planner know when a task has been 19. List and describe the four basic conversion strate-
subdivided to an adequate degree and can be clas- gies that are used when converting to a new sys-
sified as an action step? tem. Under which circumstances is each strategy
10. What is a deliverable? Name two uses for the best approach?
deliverables. 20. What is technology governance? What is change
11. What is a resource? What are the two types? control? How are they related?
Exercises
1. Using the Web, explore the emerging approach of 4. Write a job description for Kelvin Urich, the project
SecDevOps (Security/Development/Operations). manager described in the opening scenario of this
An earlier and alternative approach is DevSecOps. module. Be sure to identify key characteristics of
What is the difference implied in the two names? the ideal candidate, as well as work experience and
2. Create a first draft of a WBS from the following sce- educational background. Also, justify why your job
nario. Make assumptions as needed based on the description is suitable for potential candidates for
section about project planning considerations and this position.
constraints in this module. In your WBS, describe the 5. Search the Web for job descriptions of project man-
skill sets required for the tasks you have planned. agers. You can use any number of Web sites, includ-
3. If you have access to commercial project manage- ing www.monster.com or www.dice.com, to find at
ment software, such as Microsoft Project, use it to least 10 IT-related job descriptions. What common
complete a project plan based on the data shown elements do you find among the job descriptions?
in Table 11-2. Prepare a simple WBS report or Gantt What is the most unusual characteristic among
chart that shows your work. them?
References
1. Adapted from Dewitz, Sandra D. Systems Analysis and Design and the Transition to Objects. 1996. New York:
McGraw Hill Publishers, 94.
2. Redwine, Samuel T., Jr. (Editor). “Software Assurance: A Guide to the Common Body of Knowledge to
Produce, Acquire, and Sustain Secure Software,” Version 1.1. U.S. Department of Homeland Security.
September 2006.
3. Ibid.
4. Saltzer, J. H., and Schroeder, M. D. “The Protection of Information in Computer Systems.” Proceedings
of the IEEE, vol. 63, no. 9 (1975), pp. 1278–1308. Accessed November 1, 2020, from http://cap-lore.com/
CapTheory/ProtInf/.
5. Ibid.
6. Kissel, R., Stine, K., Scholl, M., Rossman, H., Fahlsing, J., and Gulick, J. Special Publication 800-64, Rev.
2, “Security Considerations in the System Development Life Cycle.” National Institute of Standards and
Technology. Accessed November 1, 2020, from https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpub-
lication800-64r2.pdf.
7. Microsoft. “Microsoft Security Development Lifecycle (SDL) Process Guidance – Version 5.2.” Accessed
November 1, 2020, from www.microsoft.com/en-us/download/confirmation.aspx?id=29884.
8. Ibid.
9. The SANS Institute. “GIAC Certified Project Manager (GCPM).” Accessed October 24, 2020, from www.giac
.org/certification/certified-project-manager-gcpm.
10. Ibid.
11. EC-Council. “Certified Project Management (CPM).” Accessed October 24, 2020, from https://iclass.eccoun-
cil.org/our-courses/certified-project-management/.
12. “CIS Controls® Download.” Version 7.1. Accessed November 1, 2020, from www.cisecurity.org/controls/.
13. Ibid.
14. Schein, E.H. “Kurt Lewin’s Change Theory in the Field and in the Classroom: Notes Toward a Model of
Managed Learning.” Systems Practice 9, 27–47 (1996). https://doi.org/10.1007/BF02173417.

Principles of Information Security 7E - Module 11

Uploaded by

Copyright:

Available Formats

Principles of Information Security 7E - Module 11

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Principles of Information Security 7E - Module 11

Uploaded by

Copyright:

Available Formats

MODULE 11

Introduction To Information Security Implementation

The Systems Development Life Cycle

Investigation Process, outcomes, goals, scope, costs & beneﬁts,

Figure 11-1 SDLC waterfall methodology

Maintenance and Change

Software Design Principles

• Economy of mechanism: Keep the design as simple and small as possible.

The NIST Approach to Securing the SDLC

Table 11-1 Comparison of Waterfall and NIST SDLC Phases

Waterfall SDLC Phase Equivalent NIST SDLC Phase

Key security activities for this phase include:

• Initial delineation of business requirements in terms of confidentiality, integrity, and availability;

Figure 11-2 Relating security considerations in the Initiation phase

Figure 11-3 Relating security considerations in the Development/Acquisition

Key security activities for this phase include:

Operations and Maintenance

Figure 11-4 Relating security considerations in the Implementation/

Key security activities for this phase include:

Figure 11-5 Relating security considerations in the Operations/Maintenance phase

Key security activities for this phase include:

Figure 11-6 Relating security considerations in the Disposal phase

Training Requirements Design Implementation Veriﬁcation Release Response

Establish security Establish design Use approved Dynamic Incident

Security and privacy Threat Static Attack Release

Figure 11-7 Microsoft’s SDL8

Information Security Project Management

Developing the Project Plan

Table 11-2 Example Work Breakdown Structure for a Project Plan

Estimated Estimated Estimated

Start and End Dates

Estimated Capital Expenses

Estimated Noncapital Expenses

Project Planning Considerations

Time and Scheduling Considerations

Organizational Feasibility Considerations

Training and Indoctrination Considerations

The Need for Project Management

Executing the Plan gap analysis

for an overview of this process.

Current state assessed

Current state compared

Monitor and Yes Current =

Develop gap analysis

Implement gap analysis

Figure 11-8 Gap analysis

Security Project Management Certifications

GIAC Certified Project Manager

• Earned value technique (EVT)

EC-Council IT Security Project Management

SIA Certified Security Project Manager

PMI Project Management Professional

Technical Aspects Of Implementation

Direct Old system New system

Phased Old system New system

Pilot Old system New system

Figure 11-9 Conversion strategies

phased Phased Implementation

bull’s-eye model Parallel Operations