Key Term
McCumber Cube A graphical representation of the architectural approach widely used in
computer and information security; commonly shown as a cube composed of 3×3×3 cells, similar
to a Rubik’s Cube.
18 Chapter 1
Policy Education Technology
Confidentiality
Integrity
Availability
Policy Education Technology
Storage Processing Transmission
Confidentiality
Integrity
Availability
Storage Processing Transmission
Figure 1-9 The McCumber Cube 13
© Cengage Learning 2015
Copyright 2016 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s).
Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it.
1
Components of an Information System
Key Term
information system (IS) The entire set of software, hardware, data, people, procedures, and
networks that enable the use of information resources in the organization.
As shown in Figure 1-10, an information system (IS) is much more than computer hardware;
it is the entire set of people, procedures, and technology that enable business to use informa-
tion. The six critical components of hardware, software, networks, people, procedures, and
data enable information to be input, processed, output, and stored. Each of these IS compo-
nents has its own strengths and weaknesses, as well as its own characteristics and uses. Each
component of the information system also has its own security requirements.
‡ Software
The software component of an IS includes applications, operating systems, and assorted com-
mand utilities. Software is perhaps the most difficult IS component to secure. The exploita-
tion of errors in software programming accounts for a substantial portion of the attacks on
information. The information technology industry is rife with reports warning of holes,
bugs, weaknesses, or other fundamental problems in software. In fact, many facets of daily
life are affected by buggy software, from smartphones that crash to flawed automotive con-
trol computers that lead to recalls.
Software carries the lifeblood of information through an organization. Unfortunately, soft-
ware programs are often created under the constraints of project management, which limit
time, costs, and manpower. Information security is all too often implemented as an
Components of an Information System 19
People
Procedures
Hardware
Data
Networks
Software
Figure 1-10 Components of an information system
© Cengage Learning 2015
Copyright 2016 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s).
Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it.
afterthought rather than developed as an integral component from the beginning. In this way,
software programs become an easy target of accidental or intentional attacks.
‡ Hardware
Hardware is the physical technology that houses and executes the software, stores and trans-
ports the data, and provides interfaces for the entry and removal of information from the sys-
tem. Physical security policies deal with hardware as a physical asset and with the protection
of physical assets from harm or theft. Applying the traditional tools of physical security, such
as locks and keys, restricts access to and interaction with the hardware components of an
information system. Securing the physical location of computers and the computers them-
selves is important because a breach of physical security can result in a loss of information.
Unfortunately, most information systems are built on hardware platforms that cannot guar-
antee any level of information security if unrestricted hardware access is possible.
Before September 11, 2001, laptop thefts in airports were common. A two-person team
worked to steal a computer as its owner passed it through the conveyor scanning devices.
The first perpetrator entered the security area ahead of an unsuspecting target and quickly
went through. Then, the second perpetrator waited behind until the target placed the com-
puter on the baggage scanner. As the computer was whisked through, the second perpetrator
slipped ahead of the victim and entered the metal detector with a substantial collection of
keys, coins, and the like, slowing the detection process and allowing the first perpetrator to
grab the computer and disappear in a crowded walkway.
While the security response to September 11 did tighten the security process at airports, hard-
ware can still be stolen in airports and other public places. Although laptops and notebook
computers might be worth a few thousand dollars, the information stored on them can be
worth a great deal more to organizations and individuals.
‡ Data
Data stored, processed, and transmitted by a computer system must be protected. Data is
often the most valuable asset of an organization and therefore is the main target of inten-
tional attacks. Systems developed in recent years are likely to make use of database manage-
ment systems. When used properly, they should improve the security of the data and the
applications that rely on the data. Unfortunately, many system development projects do not
make full use of the database management system’s security capabilities, and in some cases
the database is implemented in ways that make them less secure than traditional file systems.
Because data and information exist in physical form in many organizations as paper reports,
handwritten notes, and computer printouts, the protection of physical information is as
important as the protection of electronic, computer-based information.
‡ People
Though often overlooked in computer security considerations, people have always been a threat
to information security. Legend has it that around 200 B.C., a great army threatened the secu-
rity and stability of the Chinese empire. So ferocious were the Hun invaders that the Chinese
emperor commanded the construction of a great wall that would defend against them. Around
1275 A.D., Kublai Khan finally achieved what the Huns had been trying for more than a thou-
sand years. Initially, the Khan’s army tried to climb over, dig under, and break through the wall.
20 Chapter 1
Copyright 2016 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s).
Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it.
1
In the end, the Khan simply bribed the gatekeeper—and the rest is history. Whether this event
actually occurred or not, the moral of the story is that people can be the weakest link in an orga-
nization’s information security program. Unless policy, education and training, awareness, and
technology are properly employed to prevent people from accidentally or intentionally damag-
ing or losing information, they will remain the weakest link. Social engineering can prey on the
tendency to cut corners and the commonplace nature of human error. It can be used to manipu-
late people to obtain access information about a system. This topic is discussed in more detail in
Chapter 2, “The Need for Security.”
‡ Procedures
Procedures are another frequently overlooked component of an IS. Procedures are written
instructions for accomplishing a specific task. When an unauthorized user obtains an organi-
zation’s procedures, it poses a threat to the integrity of the information. For example, a con-
sultant to a bank learned how to wire funds by using the computer center’s procedures,
which were readily available. By taking advantage of a security weakness (lack of authentica-
tion), the bank consultant ordered millions of dollars to be transferred by wire to his own
account. Lax security procedures caused the loss of more than $10 million before the situa-
tion was corrected. Most organizations distribute procedures to employees so they can access
the information system, but many of these companies often fail to provide proper education
for using the procedures safely. Educating employees about safeguarding procedures is as
important as physically securing the information system. After all, procedures are informa-
tion in their own right. Therefore, knowledge of procedures, as with all critical information,
should be disseminated among members of an organization on a need-to-know basis.
‡ Networks
Networking is the IS component that created much of the need for increased computer and
information security. When information systems are connected to each other to form local area
networks (LANs), and these LANs are connected to other networks such as the Internet, new
security challenges rapidly emerge. The physical technology that enables network functions is
becoming more accessible to organizations of every size. Applying the traditional tools of physi-
cal security, such as locks and keys, to restrict access to the system’s hardware components is
still important. However, when computer systems are networked, this approach is no longer
enough. Steps to provide network security are essential, as is implementing alarm and intrusion
systems to make system owners aware of ongoing compromises.
Balancing Information Security and Access
Even with the best planning and implementation, it is impossible to obtain perfect information
security. Recall James Anderson’s statement from the beginning of this chapter, which empha-
sizes the need to balance security and access. Information security cannot be absolute: it is a
process, not a goal. You can make a system available to anyone, anywhere, anytime, through
any means. However, such unrestricted access poses a danger to the security of the informa-
tion. On the other hand, a completely secure information system would not allow anyone
access. For instance, when challenged to achieve a TCSEC C-2 level security certification for
Balancing Information Security and Access 21
Copyright 2016 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s).
Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it.
its Windows operating system, Microsoft had to remove all networking components and oper-
ate the computer only from the console in a secured room. 15
To achieve balance—that is, to operate an information system that satisfies the user and the
security professional—the security level must allow reasonable access, yet protect against
threats. Figure 1-11 shows some of the competing voices that must be considered when bal-
ancing information security and access.
Because of today’s security concerns and issues, an information system or data processing
department can get too entrenched in the management and protection of systems. An imbal-
ance can occur when the needs of the end user are undermined by obsessive focus on protect-
ing and administering the information systems. Information security technologists and end
users must recognize that both groups share the same overall goals of the organization—to
ensure that data is available when, where, and how it is needed, with minimal delays or obsta-
cles. In an ideal world, this level of availability can be met even after addressing concerns
about loss, damage, interception, or destruction.
Approaches to Information Security Implementation
Key Terms
bottom-up approach A method of establishing security policies that begins as a grassroots
effort in which systems administrators attempt to improve the security of their systems.
top-down approach A methodology of establishing security policies that is initiated by upper
management.
22 Chapter 1
Security
Access
User 1: Encrypting
e-mail is a hassle.
User 2: Encrypting
e-mail slows me down.
CISO: Encryption is
needed to protect secrets
of the organization.
Figure 1-11 Balancing information security and access
© Cengage Learning 2015
Copyright 2016 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s).
Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it.
1
The implementation of information security in an organization must begin somewhere, and
cannot happen overnight. Securing information assets is an incremental process that requires
coordination, time, and patience. Information security can begin as a grassroots effort in
which systems administrators attempt to improve the security of their systems. This is often
referred to as a bottom-up approach. The key advantage of the bottom-up approach is the
technical expertise of individual administrators. By working with information systems on a
day-to-day basis, these administrators possess in-depth knowledge that can greatly enhance
the development of an information security system. They know and understand the threats to
their systems and the mechanisms needed to protect them successfully. Unfortunately, the
bottom-up approach seldom works because it lacks critical features such as participant sup-
port and organizational staying power.
The top-down approach has a higher probability of success. With this approach, the project is
initiated by upper-level managers who issue policies, procedures, and processes; dictate the
goals and expected outcomes; and determine accountability for each required action. This
approach has strong upper-management support, a dedicated champion, usually dedicated
funding, a clear planning and implementation process, and the means of influencing organiza-
tional culture. The most successful kind of top-down approach also involves a formal develop-
ment strategy known as a systems development life cycle.
For any organization-wide effort to succeed, management must buy into and fully support it.
The champion’s role in this effort cannot be overstated. Typically, the champion is an execu-
tive, such as a chief information officer (CIO) or the vice president of information technology
(VP-IT), who moves the project forward, ensures that it is properly managed, and pushes for
acceptance throughout the organization. Without this high-level support, many mid-level
administrators fail to make time for the project or dismiss it as a low priority. The involve-
ment and support of end users is also critical to the success of this type of project. Users are
most directly affected by the process and outcome of the project and must be included in the
information security process. Key end users should be assigned to a developmental team
known as the joint application development (or design) team (JAD). To succeed, the JAD
must have staying power. It must be able to survive employee turnover and should not be vul-
nerable to changes in the personnel team that is developing the information security system.
This means the processes and procedures must be documented and integrated into the organi-
zational culture. They must be adopted and promoted by the organization’s management.
The organizational hierarchy and its relationship to the bottom-up and top-down approaches
are illustrated in Figure 1-12.
Security in the Systems Life Cycle
Key Terms
security systems development life cycle (SecSDLC) A methodology for the design and
implementation of security systems based on the systems development life cycle. The two life
cycles contain the same general phases.
systems development life cycle (SDLC) A methodology for the design and implementation of
an information system. The SDLC contains different phases depending on the methodology
deployed, but generally the phases address the investigation, analysis, design, implementation,
and maintenance of an information system.
Security in the Systems Life Cycle 23
Copyright 2016 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s).
Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it.
Information security must be managed like any other major system in an organization. One
approach for implementing an information security system in an organization with little or no
formal security in place is to use a variation of a systems development life cycle (SDLC): the
security systems development life cycle (SecSDLC). To understand a security systems develop-
ment life cycle, you must first understand the principles of the method on which it is based.
‡ The Systems Development Life Cycle
Key Terms
methodology A formal approach to solving a problem based on a structured sequence of
procedures.
waterfall model A type of SDLC in which each phase of the process “flows from” the
information gained in the previous phase, with multiple opportunities to return to previous
phases and make adjustments.
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.
The traditional SDLC consists of six general phases. If you have taken a system analysis and
design course, you may have been exposed to a model consisting of a different number of
phases. SDLC models range from three to twelve phases, all of which have been mapped
24 Chapter 1
CEO
CFO CIO COO
CISO VP-Systems VP-Networks
security
mgr
systems
mgr
network
mgr
security
admin
systems
admin
network
admin
security
tech
systems
tech
network
tech
Top-down approach Bottom-up approach
Figure 1-12 Approaches to information security implementation
© Cengage Learning 2015
Copyright 2016 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s).
Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it.
1
into the six presented here. The waterfall model pictured in Figure 1-13 illustrates that each
phase begins with the results and information gained from the previous phase.
A traditional form of the SDLC is not the only approach in widespread use. Other
approaches to the development process include iterative and incremental, the spiral method,
rapid application development (RAD), JAD, agile (extreme programming), V-shaped, and
many other practices. Each of these approaches has its advantages and disadvantages, and
each can be effective under the right circumstances. People who work in specialty areas of
information security that support the software assurance process (described later in this chap-
ter) must be conversant in each of these methodologies. However, we will use the more
widely accepted traditional approach for this discussion.
At the end of each phase of the traditional SDLC comes a structured review or reality check,
during which the team determines if the project should be continued, discontinued, out-
sourced, postponed, or returned to an earlier phase. This determination depends on whether
the project is proceeding as expected and whether it needs additional expertise, organiza-
tional knowledge, or other resources.
Once the system is implemented, it is maintained and modified over the remainder of its working
life. Any information 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. 16
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 after-
ward, a process will be undertaken to assess economic, technical, and behavioral feasibilities
and ensure that implementation is worth the organization’s time and effort.
Security in the Systems Life Cycle 25
Maintenance
and Change
Repeat when system no longer viable
Investigation
Analysis
Logical Design
Physical Design
Implementation
Figure 1-13 SDLC waterfall methodology
© Cengage Learning 2015
Copyright 2016 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s).
Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it.
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 solution 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
generate 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 evaluated in the logical design. The selected compo-
nents 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 management for approval.
Implementation In the implementation phase, any needed software is created. Compo-
nents are ordered, received, and tested. Afterward, users are trained and supporting docu-
mentation 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 pro-
cess should begin again from the investigation phase. At periodic points, the system is tested for
compliance, and the feasibility 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
project is terminated and a new project is implemented.
For more information on SDLCs, see the Department of Justice’s Information Resource
Management Department document on SDLC Guidance at www.justice.gov/jmd/irm/lifecycle
/table.htm.
26 Chapter 1
Copyright 2016 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s).
Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it.
1
‡ The Security Systems Development Life Cycle
The same phases used in the traditional SDLC can be adapted to support the implementation
of an information security project. While the two processes may differ in intent and specific
activities, the overall methodology is the same. At its heart, implementing information secu-
rity involves identifying specific threats and creating specific controls to counter them. The
SecSDLC unifies this process and makes it a coherent program rather than a series of ran-
dom, seemingly unconnected actions. (Other organizations use a risk management approach
to implement information security systems, as you will learn in subsequent chapters.)
Investigation The investigation phase of the SecSDLC begins with a directive from upper
management that dictates the process, outcomes, and goals of the project, as well as its budget
and other constraints. Frequently, this phase begins with an enterprise information security
policy (EISP), discussed in detail in Chapter 5, which outlines the implementation of a security
program within the organization. Teams of responsible managers, employees, and contractors
are organized; problems are analyzed; and the scope of the project is defined along with specific
goals and objectives and any additional constraints not covered in the program policy. Finally,
an organizational feasibility analysis is performed to determine whether the organization has
the resources and commitment necessary to conduct a successful security analysis and design.
Analysis In the analysis phase, the documents from the investigation phase are studied.
The development team conducts a preliminary analysis of existing security policies or pro-
grams, documented current threats, and associated controls. This phase also includes an
analysis of relevant legal issues that could affect the design of the security solution. Increas-
ingly, privacy laws have become a major consideration when making decisions about infor-
mation systems that manage personal information. Recently, many states have implemented
legislation that make certain computer-related activities illegal. A detailed understanding of
these issues is vital. Risk management, which is described in detail in Chapter 4, also begins
in this stage. Risk management focuses on identifying, assessing, and evaluating the levels of
risk in an organization, specifically the threats to its security and to the information it stores
and processes.
Logical Design The logical design phase creates and develops the blueprints for infor-
mation security, and examines and implements key policies that influence later decisions. At
this stage, the team also plans incident response actions to be taken in the event of partial or
catastrophic loss. The planning answers the following questions:
●
Continuity planning: How will business continue in the event of a loss?
●
Incident response: What steps are taken when an attack occurs?
●
Disaster recovery: What must be done to recover information and vital systems imme-
diately after a disastrous event?
Next, a feasibility analysis determines whether the project should be continued or
outsourced.
Physical Design The physical design phase evaluates the information security technol-
ogy needed to support the blueprint as it has been outlined in the logical design. The final phys-
ical design is usually chosen from several competing alternatives, each of which could meet the
Security in the Systems Life Cycle 27
Copyright 2016 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s).
Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it.
logical design requirements. The information security blueprint may be revisited from time to
time to keep it in line with changes needed when the physical design is completed. Criteria for
determining the definition of successful solutions are also prepared during this phase. This
phase includes designs for physical security measures to support the proposed technological
solutions. At the end of this phase, a feasibility study determines the organization’s readiness
for the proposed project, and then the champion and sponsors are presented with the design.
All parties involved have a chance to approve the project before implementation begins.
Implementation The implementation phase of the SecSDLC is similar to that of the tra-
ditional SDLC. The security solutions are acquired (made or bought), tested, implemented,
and tested again. Personnel issues are evaluated, and specific training and education pro-
grams are conducted. Finally, the entire tested package is presented to upper management
for final approval.
Maintenance and Change Maintenance and change is the last phase, and perhaps the
most important one, given the ever-changing threat environment. Today’s information security
systems need constant monitoring, testing, modification, updating, and repairing. Applications
systems developed within the framework of the traditional SDLC are not designed to anticipate
a software attack that requires some degree of application reconstruction. In information secu-
rity, the battle for stable, reliable systems is a defensive one. Often, repairing damage and
restoring information is a constant effort against an unseen adversary. As new threats emerge
and old threats evolve, an organization’s information security profile must constantly adapt to
prevent threats from successfully penetrating sensitive data. This constant vigilance and secu-
rity can be compared to that of a fortress, where threats both from outside and within must be
constantly monitored and checked with continuously new and more innovative technologies.
Table 1-2 summarizes the steps performed both in the systems development life cycle and
the security systems development life cycle. Because the security systems development life
cycle is based on the systems development life cycle, the steps in the cycles are similar. The
steps common to both cycles are outlined in column 2. Column 3 shows the steps unique
to the security systems development life cycle that are performed in each phase.
‡ Software Assurance—Security in the SDLC
Key Term
software assurance (SA) 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. SA
attempts to intentionally create software free of vulnerabilities and provide effective, efficient
software that users can deploy with confidence.
Many of the information security issues facing modern information systems have their root
cause in the software elements 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 organizations recognize the need to
include planning for security objectives in the SDLC they use to create systems, and have estab-
lished 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.
28 Chapter 1
Copyright 2016 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s).
Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it.
1
Security in the Systems Life Cycle 29
Phases
Steps common to both the systems
development life cycle and the
security systems development life
cycle
Steps unique to the security
systems development life cycle
Phase 1: Investigation
●
Outline project scope and goals
●
Estimate costs
●
Evaluate existing resources
●
Analyze feasibility
●
Management defines project
processes and goals and documents
these in the program security
policy
Phase 2: Analysis
●
Assess current system against plan
developed in Phase 1
●
Develop preliminary system
requirements
●
Study integration of new system
with existing system
●
Document findings and update
feasibility analysis
●
Analyze existing security policies
and programs
●
Analyze current threats and
controls
●
Examine legal issues
●
Perform risk analysis
Phase 3: Logical Design
●
Assess current business needs
against plan developed in Phase 2
●
Select applications, data support,
and structures
●
Generate multiple solutions for
consideration
●
Document findings and update
feasibility analysis
●
Develop security blueprint
●
Plan incident response actions
●
Plan business response to disaster
●
Determine feasibility of continuing
and/or outsourcing the project
Phase 4: Physical Design
●
Select technologies to support
solutions developed in
Phase 3
●
Select the best solution
●
Decide to make or buy components
●
Document findings and update
feasibility analysis
●
Select technologies needed to
support security blueprint
●
Develop definition of successful
solution
●
Design physical security measures
to support technological
solutions
●
Review and approve project
Phase 5: Implementation
●
Develop or buy software
●
Order components
●
Document the system
●
Train users
●
Update feasibility analysis
●
Present system to users
●
Test system and review
performance
●
Buy or develop security solutions
●
At end of phase, present tested
package to management for
approval
Phase 6: Maintenance and
Change
●
Support and modify system during
its useful life
●
Test periodically for compliance
with business needs
●
Upgrade and patch as necessary
●
Constantly monitor, test, modify,
update, and repair to meet
changing threats
Table 1-2 SDLC and SecSDLC Phases Summary
© Cengage Learning 2015
Copyright 2016 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s).
Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it.
Organizations are increasingly working to build security into the SDLC to prevent security
problems before they begin. A national effort is underway to create a common body of
knowledge focused on secure software development. 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
Secure Software Assurance (SwA) Common Body of Knowledge (CBK). 17 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 documents and
standards, the SwA CBK was developed and published to serve as a guideline. While this
work has not yet been adopted as a standard or even a policy requirement of government
agencies, it serves as a strongly recommended guide to developing more secure applications.
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 Sustainment 18
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 specifica-
tions, 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 mechanismsdependsuponthe ability ofa system toprevent securityviola-
tions. 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
30 Chapter 1
Copyright 2016 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s).
Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it.
1
usersofmostsystems areawareofat least oneway tocrash thesystem, denyingother
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 con-
straints. Design and construction techniques that systematically exclude flaws are
the topic of much research activity, but no complete method applicable to the con-
struction of large general-purpose systems exists yet… 19
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. 20
Many of the common problems associated with programming approaches that don’t follow
the software assurance methodology are discussed in Chapter 2, “The Need for Security.”
For more information on software assurance and the national effort to develop an SA common
body of knowledge and supporting curriculum, visit https://buildsecurityin.us-cert.gov/dhs/dhs-
software-assurance-resources.
‡ The NIST Approach to Securing the SDLC
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 confidential-
ity, 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.
Security in the Systems Life Cycle 31
Copyright 2016 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s).
Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it.
To be most effective, information security must be integrated into the SDLC
from system inception. Early integration of security in the SDLC enables agen-
cies to maximize return on investment in their security programs, through:
●
Early identification and mitigation of security vulnerabilities and misconfi-
gurations, resulting in lower cost of security control implementation and
vulnerability mitigation;
●
Awareness of potential engineering challenges caused by mandatory secu-
rity 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 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. […]
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;
32 Chapter 1
Copyright 2016 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s).
Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it.
1
●