U86PStVS

1Key Term
2McCumber Cube A graphical representation of the architectural approach widely used in
3computer and information security; commonly shown as a cube composed of 3×3×3 cells, similar
4to a Rubik’s Cube.
518 Chapter 1
6Policy Education Technology
7Confidentiality
8Integrity
9Availability
10Policy Education Technology
11Storage Processing Transmission
12Confidentiality
13Integrity
14Availability
15Storage Processing Transmission
16Figure 1-9 The McCumber Cube 13
17© Cengage Learning 2015
18Copyright 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).
19Editorial 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.
201
21Components of an Information System
22Key Term
23information system (IS) The entire set of software, hardware, data, people, procedures, and
24networks that enable the use of information resources in the organization.
25As shown in Figure 1-10, an information system (IS) is much more than computer hardware;
26it is the entire set of people, procedures, and technology that enable business to use informa-
27tion. The six critical components of hardware, software, networks, people, procedures, and
28data enable information to be input, processed, output, and stored. Each of these IS compo-
29nents has its own strengths and weaknesses, as well as its own characteristics and uses. Each
30component of the information system also has its own security requirements.
31‡ Software
32The software component of an IS includes applications, operating systems, and assorted com-
33mand utilities. Software is perhaps the most difficult IS component to secure. The exploita-
34tion of errors in software programming accounts for a substantial portion of the attacks on
35information. The information technology industry is rife with reports warning of holes,
36bugs, weaknesses, or other fundamental problems in software. In fact, many facets of daily
37life are affected by buggy software, from smartphones that crash to flawed automotive con-
38trol computers that lead to recalls.
39Software carries the lifeblood of information through an organization. Unfortunately, soft-
40ware programs are often created under the constraints of project management, which limit
41time, costs, and manpower. Information security is all too often implemented as an
42Components of an Information System 19
43People
44Procedures
45Hardware
46Data
47Networks
48Software
49Figure 1-10 Components of an information system
50© Cengage Learning 2015
51Copyright 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).
52Editorial 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.
53afterthought rather than developed as an integral component from the beginning. In this way,
54software programs become an easy target of accidental or intentional attacks.
55‡ Hardware
56Hardware is the physical technology that houses and executes the software, stores and trans-
57ports the data, and provides interfaces for the entry and removal of information from the sys-
58tem. Physical security policies deal with hardware as a physical asset and with the protection
59of physical assets from harm or theft. Applying the traditional tools of physical security, such
60as locks and keys, restricts access to and interaction with the hardware components of an
61information system. Securing the physical location of computers and the computers them-
62selves is important because a breach of physical security can result in a loss of information.
63Unfortunately, most information systems are built on hardware platforms that cannot guar-
64antee any level of information security if unrestricted hardware access is possible.
65Before September 11, 2001, laptop thefts in airports were common. A two-person team
66worked to steal a computer as its owner passed it through the conveyor scanning devices.
67The first perpetrator entered the security area ahead of an unsuspecting target and quickly
68went through. Then, the second perpetrator waited behind until the target placed the com-
69puter on the baggage scanner. As the computer was whisked through, the second perpetrator
70slipped ahead of the victim and entered the metal detector with a substantial collection of
71keys, coins, and the like, slowing the detection process and allowing the first perpetrator to
72grab the computer and disappear in a crowded walkway.
73While the security response to September 11 did tighten the security process at airports, hard-
74ware can still be stolen in airports and other public places. Although laptops and notebook
75computers might be worth a few thousand dollars, the information stored on them can be
76worth a great deal more to organizations and individuals.
77‡ Data
78Data stored, processed, and transmitted by a computer system must be protected. Data is
79often the most valuable asset of an organization and therefore is the main target of inten-
80tional attacks. Systems developed in recent years are likely to make use of database manage-
81ment systems. When used properly, they should improve the security of the data and the
82applications that rely on the data. Unfortunately, many system development projects do not
83make full use of the database management system’s security capabilities, and in some cases
84the database is implemented in ways that make them less secure than traditional file systems.
85Because data and information exist in physical form in many organizations as paper reports,
86handwritten notes, and computer printouts, the protection of physical information is as
87important as the protection of electronic, computer-based information.
88‡ People
89Though often overlooked in computer security considerations, people have always been a threat
90to information security. Legend has it that around 200 B.C., a great army threatened the secu-
91rity and stability of the Chinese empire. So ferocious were the Hun invaders that the Chinese
92emperor commanded the construction of a great wall that would defend against them. Around
931275 A.D., Kublai Khan finally achieved what the Huns had been trying for more than a thou-
94sand years. Initially, the Khan’s army tried to climb over, dig under, and break through the wall.
9520 Chapter 1
96Copyright 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).
97Editorial 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.
981
99In the end, the Khan simply bribed the gatekeeper—and the rest is history. Whether this event
100actually occurred or not, the moral of the story is that people can be the weakest link in an orga-
101nization’s information security program. Unless policy, education and training, awareness, and
102technology are properly employed to prevent people from accidentally or intentionally damag-
103ing or losing information, they will remain the weakest link. Social engineering can prey on the
104tendency to cut corners and the commonplace nature of human error. It can be used to manipu-
105late people to obtain access information about a system. This topic is discussed in more detail in
106Chapter 2, “The Need for Security.”
107‡ Procedures
108Procedures are another frequently overlooked component of an IS. Procedures are written
109instructions for accomplishing a specific task. When an unauthorized user obtains an organi-
110zation’s procedures, it poses a threat to the integrity of the information. For example, a con-
111sultant to a bank learned how to wire funds by using the computer center’s procedures,
112which were readily available. By taking advantage of a security weakness (lack of authentica-
113tion), the bank consultant ordered millions of dollars to be transferred by wire to his own
114account. Lax security procedures caused the loss of more than $10 million before the situa-
115tion was corrected. Most organizations distribute procedures to employees so they can access
116the information system, but many of these companies often fail to provide proper education
117for using the procedures safely. Educating employees about safeguarding procedures is as
118important as physically securing the information system. After all, procedures are informa-
119tion in their own right. Therefore, knowledge of procedures, as with all critical information,
120should be disseminated among members of an organization on a need-to-know basis.
121‡ Networks
122Networking is the IS component that created much of the need for increased computer and
123information security. When information systems are connected to each other to form local area
124networks (LANs), and these LANs are connected to other networks such as the Internet, new
125security challenges rapidly emerge. The physical technology that enables network functions is
126becoming more accessible to organizations of every size. Applying the traditional tools of physi-
127cal security, such as locks and keys, to restrict access to the system’s hardware components is
128still important. However, when computer systems are networked, this approach is no longer
129enough. Steps to provide network security are essential, as is implementing alarm and intrusion
130systems to make system owners aware of ongoing compromises.
131Balancing Information Security and Access
132Even with the best planning and implementation, it is impossible to obtain perfect information
133security. Recall James Anderson’s statement from the beginning of this chapter, which empha-
134sizes the need to balance security and access. Information security cannot be absolute: it is a
135process, not a goal. You can make a system available to anyone, anywhere, anytime, through
136any means. However, such unrestricted access poses a danger to the security of the informa-
137tion. On the other hand, a completely secure information system would not allow anyone
138access. For instance, when challenged to achieve a TCSEC C-2 level security certification for
139Balancing Information Security and Access 21
140Copyright 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).
141Editorial 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.
142its Windows operating system, Microsoft had to remove all networking components and oper-
143ate the computer only from the console in a secured room. 15
144To achieve balance—that is, to operate an information system that satisfies the user and the
145security professional—the security level must allow reasonable access, yet protect against
146threats. Figure 1-11 shows some of the competing voices that must be considered when bal-
147ancing information security and access.
148Because of today’s security concerns and issues, an information system or data processing
149department can get too entrenched in the management and protection of systems. An imbal-
150ance can occur when the needs of the end user are undermined by obsessive focus on protect-
151ing and administering the information systems. Information security technologists and end
152users must recognize that both groups share the same overall goals of the organization—to
153ensure that data is available when, where, and how it is needed, with minimal delays or obsta-
154cles. In an ideal world, this level of availability can be met even after addressing concerns
155about loss, damage, interception, or destruction.
156Approaches to Information Security Implementation
157Key Terms
158bottom-up approach A method of establishing security policies that begins as a grassroots
159effort in which systems administrators attempt to improve the security of their systems.
160top-down approach A methodology of establishing security policies that is initiated by upper
161management.
16222 Chapter 1
163Security
164Access
165User 1: Encrypting
166e-mail is a hassle.
167User 2: Encrypting
168e-mail slows me down.
169CISO: Encryption is
170needed to protect secrets
171of the organization.
172Figure 1-11 Balancing information security and access
173© Cengage Learning 2015
174Copyright 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).
175Editorial 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.
1761
177The implementation of information security in an organization must begin somewhere, and
178cannot happen overnight. Securing information assets is an incremental process that requires
179coordination, time, and patience. Information security can begin as a grassroots effort in
180which systems administrators attempt to improve the security of their systems. This is often
181referred to as a bottom-up approach. The key advantage of the bottom-up approach is the
182technical expertise of individual administrators. By working with information systems on a
183day-to-day basis, these administrators possess in-depth knowledge that can greatly enhance
184the development of an information security system. They know and understand the threats to
185their systems and the mechanisms needed to protect them successfully. Unfortunately, the
186bottom-up approach seldom works because it lacks critical features such as participant sup-
187port and organizational staying power.
188The top-down approach has a higher probability of success. With this approach, the project is
189initiated by upper-level managers who issue policies, procedures, and processes; dictate the
190goals and expected outcomes; and determine accountability for each required action. This
191approach has strong upper-management support, a dedicated champion, usually dedicated
192funding, a clear planning and implementation process, and the means of influencing organiza-
193tional culture. The most successful kind of top-down approach also involves a formal develop-
194ment strategy known as a systems development life cycle.
195For any organization-wide effort to succeed, management must buy into and fully support it.
196The champion’s role in this effort cannot be overstated. Typically, the champion is an execu-
197tive, such as a chief information officer (CIO) or the vice president of information technology
198(VP-IT), who moves the project forward, ensures that it is properly managed, and pushes for
199acceptance throughout the organization. Without this high-level support, many mid-level
200administrators fail to make time for the project or dismiss it as a low priority. The involve-
201ment and support of end users is also critical to the success of this type of project. Users are
202most directly affected by the process and outcome of the project and must be included in the
203information security process. Key end users should be assigned to a developmental team
204known as the joint application development (or design) team (JAD). To succeed, the JAD
205must have staying power. It must be able to survive employee turnover and should not be vul-
206nerable to changes in the personnel team that is developing the information security system.
207This means the processes and procedures must be documented and integrated into the organi-
208zational culture. They must be adopted and promoted by the organization’s management.
209The organizational hierarchy and its relationship to the bottom-up and top-down approaches
210are illustrated in Figure 1-12.
211Security in the Systems Life Cycle
212Key Terms
213security systems development life cycle (SecSDLC) A methodology for the design and
214implementation of security systems based on the systems development life cycle. The two life
215cycles contain the same general phases.
216systems development life cycle (SDLC) A methodology for the design and implementation of
217an information system. The SDLC contains different phases depending on the methodology
218deployed, but generally the phases address the investigation, analysis, design, implementation,
219and maintenance of an information system.
220Security in the Systems Life Cycle 23
221Copyright 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).
222Editorial 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.
223Information security must be managed like any other major system in an organization. One
224approach for implementing an information security system in an organization with little or no
225formal security in place is to use a variation of a systems development life cycle (SDLC): the
226security systems development life cycle (SecSDLC). To understand a security systems develop-
227ment life cycle, you must first understand the principles of the method on which it is based.
228‡ The Systems Development Life Cycle
229Key Terms
230methodology A formal approach to solving a problem based on a structured sequence of
231procedures.
232waterfall model A type of SDLC in which each phase of the process “flows from” the
233information gained in the previous phase, with multiple opportunities to return to previous
234phases and make adjustments.
235An SDLC is a methodology for the design and implementation of an information system.
236Using a methodology ensures a rigorous process with a clearly defined goal and increases
237the probability of success. Once a methodology has been adopted, the key milestones are
238established and a team is selected and made accountable for accomplishing the project goals.
239The traditional SDLC consists of six general phases. If you have taken a system analysis and
240design course, you may have been exposed to a model consisting of a different number of
241phases. SDLC models range from three to twelve phases, all of which have been mapped
24224 Chapter 1
243CEO
244CFO CIO COO
245CISO VP-Systems VP-Networks
246security
247mgr
248systems
249mgr
250network
251mgr
252security
253admin
254systems
255admin
256network
257admin
258security
259tech
260systems
261tech
262network
263tech
264Top-down approach Bottom-up approach
265Figure 1-12 Approaches to information security implementation
266© Cengage Learning 2015
267Copyright 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).
268Editorial 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.
2691
270into the six presented here. The waterfall model pictured in Figure 1-13 illustrates that each
271phase begins with the results and information gained from the previous phase.
272A traditional form of the SDLC is not the only approach in widespread use. Other
273approaches to the development process include iterative and incremental, the spiral method,
274rapid application development (RAD), JAD, agile (extreme programming), V-shaped, and
275many other practices. Each of these approaches has its advantages and disadvantages, and
276each can be effective under the right circumstances. People who work in specialty areas of
277information security that support the software assurance process (described later in this chap-
278ter) must be conversant in each of these methodologies. However, we will use the more
279widely accepted traditional approach for this discussion.
280At the end of each phase of the traditional SDLC comes a structured review or reality check,
281during which the team determines if the project should be continued, discontinued, out-
282sourced, postponed, or returned to an earlier phase. This determination depends on whether
283the project is proceeding as expected and whether it needs additional expertise, organiza-
284tional knowledge, or other resources.
285Once the system is implemented, it is maintained and modified over the remainder of its working
286life. Any information systems implementation may have multiple iterations as the cycle is repeated
287over time. Only by constant examination and renewal can any system, especially an information
288security program, perform up to expectations in a constantly changing environment.
289The following sections describe each phase of a traditional SDLC. 16
290Investigation The first phase, investigation, is the most important. What problem is the
291system being developed to solve? The investigation phase begins by examining the event or
292plan that initiates the process. During this phase, the objectives, constraints, and scope of
293the project are specified. A preliminary cost-benefit analysis evaluates the perceived benefits
294and their appropriate levels of cost. At the conclusion of this phase and at every phase after-
295ward, a process will be undertaken to assess economic, technical, and behavioral feasibilities
296and ensure that implementation is worth the organization’s time and effort.
297Security in the Systems Life Cycle 25
298Maintenance
299and Change
300Repeat when system no longer viable
301Investigation
302Analysis
303Logical Design
304Physical Design
305Implementation
306Figure 1-13 SDLC waterfall methodology
307© Cengage Learning 2015
308Copyright 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).
309Editorial 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.
310Analysis The analysis phase begins with the information gained during the investigation
311phase. This phase consists primarily of assessments of the organization, its current systems,
312and its capability to support the proposed systems. Analysts begin by determining what the
313new system is expected to do and how it will interact with existing systems. This phase ends
314with documentation of the findings and an update of the feasibility analysis.
315Logical Design In the logical design phase, the information gained from the analysis
316phase is used to begin creating a systems solution for a business problem. In any systems
317solution, the first and driving factor must be the business need. Based on the business need,
318applications are selected to provide needed services, and then the team chooses data support
319and structures capable of providing the needed inputs. Finally, based on all of this, specific
320technologies are delineated to implement the physical solution. The logical design, therefore,
321is the blueprint for the desired solution. The logical design is implementation independent,
322meaning that it contains no reference to specific technologies, vendors, or products. Instead,
323it addresses how the proposed system will solve the problem at hand. In this stage, analysts
324generate estimates of costs and benefits to allow for a general comparison of available
325options. At the end of this phase, another feasibility analysis is performed.
326Physical Design During the physical design phase, specific technologies are selected to
327support the alternatives identified and evaluated in the logical design. The selected compo-
328nents are evaluated based on a make-or-buy decision—the option to develop components
329in-house or purchase them from a vendor. Final designs integrate various components and
330technologies. After yet another feasibility analysis, the entire solution is presented to the
331organization’s management for approval.
332Implementation In the implementation phase, any needed software is created. Compo-
333nents are ordered, received, and tested. Afterward, users are trained and supporting docu-
334mentation created. Once all components are tested individually, they are installed and tested
335as a system. A feasibility analysis is again prepared, and the sponsors are then presented
336with the system for a performance review and acceptance test.
337Maintenance and Change The maintenance and change phase is the longest and most
338expensive of the process. This phase consists of the tasks necessary to support and modify the
339system for the remainder of its useful life cycle. Even though formal development may conclude
340during this phase, the life cycle of the project continues until the team determines that the pro-
341cess should begin again from the investigation phase. At periodic points, the system is tested for
342compliance, and the feasibility of continuance versus discontinuance is evaluated. Upgrades,
343updates, and patches are managed. As the needs of the organization change, the systems that
344support the organization must also change. The people who manage and support the systems
345must continually monitor their effectiveness in relation to the organization’s environment.
346When a current system can no longer support the evolving mission of the organization, the
347project is terminated and a new project is implemented.
348For more information on SDLCs, see the Department of Justice’s Information Resource
349Management Department document on SDLC Guidance at www.justice.gov/jmd/irm/lifecycle
350/table.htm.
35126 Chapter 1
352Copyright 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).
353Editorial 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.
3541
355‡ The Security Systems Development Life Cycle
356The same phases used in the traditional SDLC can be adapted to support the implementation
357of an information security project. While the two processes may differ in intent and specific
358activities, the overall methodology is the same. At its heart, implementing information secu-
359rity involves identifying specific threats and creating specific controls to counter them. The
360SecSDLC unifies this process and makes it a coherent program rather than a series of ran-
361dom, seemingly unconnected actions. (Other organizations use a risk management approach
362to implement information security systems, as you will learn in subsequent chapters.)
363Investigation The investigation phase of the SecSDLC begins with a directive from upper
364management that dictates the process, outcomes, and goals of the project, as well as its budget
365and other constraints. Frequently, this phase begins with an enterprise information security
366policy (EISP), discussed in detail in Chapter 5, which outlines the implementation of a security
367program within the organization. Teams of responsible managers, employees, and contractors
368are organized; problems are analyzed; and the scope of the project is defined along with specific
369goals and objectives and any additional constraints not covered in the program policy. Finally,
370an organizational feasibility analysis is performed to determine whether the organization has
371the resources and commitment necessary to conduct a successful security analysis and design.
372Analysis In the analysis phase, the documents from the investigation phase are studied.
373The development team conducts a preliminary analysis of existing security policies or pro-
374grams, documented current threats, and associated controls. This phase also includes an
375analysis of relevant legal issues that could affect the design of the security solution. Increas-
376ingly, privacy laws have become a major consideration when making decisions about infor-
377mation systems that manage personal information. Recently, many states have implemented
378legislation that make certain computer-related activities illegal. A detailed understanding of
379these issues is vital. Risk management, which is described in detail in Chapter 4, also begins
380in this stage. Risk management focuses on identifying, assessing, and evaluating the levels of
381risk in an organization, specifically the threats to its security and to the information it stores
382and processes.
383Logical Design The logical design phase creates and develops the blueprints for infor-
384mation security, and examines and implements key policies that influence later decisions. At
385this stage, the team also plans incident response actions to be taken in the event of partial or
386catastrophic loss. The planning answers the following questions:
387●
388Continuity planning: How will business continue in the event of a loss?
389●
390Incident response: What steps are taken when an attack occurs?
391●
392Disaster recovery: What must be done to recover information and vital systems imme-
393diately after a disastrous event?
394Next, a feasibility analysis determines whether the project should be continued or
395outsourced.
396Physical Design The physical design phase evaluates the information security technol-
397ogy needed to support the blueprint as it has been outlined in the logical design. The final phys-
398ical design is usually chosen from several competing alternatives, each of which could meet the
399Security in the Systems Life Cycle 27
400Copyright 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).
401Editorial 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.
402logical design requirements. The information security blueprint may be revisited from time to
403time to keep it in line with changes needed when the physical design is completed. Criteria for
404determining the definition of successful solutions are also prepared during this phase. This
405phase includes designs for physical security measures to support the proposed technological
406solutions. At the end of this phase, a feasibility study determines the organization’s readiness
407for the proposed project, and then the champion and sponsors are presented with the design.
408All parties involved have a chance to approve the project before implementation begins.
409Implementation The implementation phase of the SecSDLC is similar to that of the tra-
410ditional SDLC. The security solutions are acquired (made or bought), tested, implemented,
411and tested again. Personnel issues are evaluated, and specific training and education pro-
412grams are conducted. Finally, the entire tested package is presented to upper management
413for final approval.
414Maintenance and Change Maintenance and change is the last phase, and perhaps the
415most important one, given the ever-changing threat environment. Today’s information security
416systems need constant monitoring, testing, modification, updating, and repairing. Applications
417systems developed within the framework of the traditional SDLC are not designed to anticipate
418a software attack that requires some degree of application reconstruction. In information secu-
419rity, the battle for stable, reliable systems is a defensive one. Often, repairing damage and
420restoring information is a constant effort against an unseen adversary. As new threats emerge
421and old threats evolve, an organization’s information security profile must constantly adapt to
422prevent threats from successfully penetrating sensitive data. This constant vigilance and secu-
423rity can be compared to that of a fortress, where threats both from outside and within must be
424constantly monitored and checked with continuously new and more innovative technologies.
425Table 1-2 summarizes the steps performed both in the systems development life cycle and
426the security systems development life cycle. Because the security systems development life
427cycle is based on the systems development life cycle, the steps in the cycles are similar. The
428steps common to both cycles are outlined in column 2. Column 3 shows the steps unique
429to the security systems development life cycle that are performed in each phase.
430‡ Software Assurance—Security in the SDLC
431Key Term
432software assurance (SA) A methodological approach to the development of software that
433seeks to build security into the development life cycle rather than address it at later stages. SA
434attempts to intentionally create software free of vulnerabilities and provide effective, efficient
435software that users can deploy with confidence.
436Many of the information security issues facing modern information systems have their root
437cause in the software elements of the system. Secure systems require secure or at least securable
438software. The development of systems and the software they use is often accomplished using a
439methodology, such as the SDLC described earlier. Many organizations recognize the need to
440include planning for security objectives in the SDLC they use to create systems, and have estab-
441lished procedures to create software that is more capable of being deployed in a secure fashion.
442This approach to software development is known as software assurance, or SA.
44328 Chapter 1
444Copyright 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).
445Editorial 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.
4461
447Security in the Systems Life Cycle 29
448Phases
449Steps common to both the systems
450development life cycle and the
451security systems development life
452cycle
453Steps unique to the security
454systems development life cycle
455Phase 1: Investigation
456●
457Outline project scope and goals
458●
459Estimate costs
460●
461Evaluate existing resources
462●
463Analyze feasibility
464●
465Management defines project
466processes and goals and documents
467these in the program security
468policy
469Phase 2: Analysis
470●
471Assess current system against plan
472developed in Phase 1
473●
474Develop preliminary system
475requirements
476●
477Study integration of new system
478with existing system
479●
480Document findings and update
481feasibility analysis
482●
483Analyze existing security policies
484and programs
485●
486Analyze current threats and
487controls
488●
489Examine legal issues
490●
491Perform risk analysis
492Phase 3: Logical Design
493●
494Assess current business needs
495against plan developed in Phase 2
496●
497Select applications, data support,
498and structures
499●
500Generate multiple solutions for
501consideration
502●
503Document findings and update
504feasibility analysis
505●
506Develop security blueprint
507●
508Plan incident response actions
509●
510Plan business response to disaster
511●
512Determine feasibility of continuing
513and/or outsourcing the project
514Phase 4: Physical Design
515●
516Select technologies to support
517solutions developed in
518Phase 3
519●
520Select the best solution
521●
522Decide to make or buy components
523●
524Document findings and update
525feasibility analysis
526●
527Select technologies needed to
528support security blueprint
529●
530Develop definition of successful
531solution
532●
533Design physical security measures
534to support technological
535solutions
536●
537Review and approve project
538Phase 5: Implementation
539●
540Develop or buy software
541●
542Order components
543●
544Document the system
545●
546Train users
547●
548Update feasibility analysis
549●
550Present system to users
551●
552Test system and review
553performance
554●
555Buy or develop security solutions
556●
557At end of phase, present tested
558package to management for
559approval
560Phase 6: Maintenance and
561Change
562●
563Support and modify system during
564its useful life
565●
566Test periodically for compliance
567with business needs
568●
569Upgrade and patch as necessary
570●
571Constantly monitor, test, modify,
572update, and repair to meet
573changing threats
574Table 1-2 SDLC and SecSDLC Phases Summary
575© Cengage Learning 2015
576Copyright 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).
577Editorial 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.
578Organizations are increasingly working to build security into the SDLC to prevent security
579problems before they begin. A national effort is underway to create a common body of
580knowledge focused on secure software development. The U.S. Department of Defense
581launched a Software Assurance Initiative in 2003. This initial process was led by Joe
582Jarzombek and was endorsed and supported by the Department of Homeland Security (DHS),
583which joined the program in 2004. This program initiative resulted in the publication of the
584Secure Software Assurance (SwA) Common Body of Knowledge (CBK). 17 A working group
585drawn from industry, government, and academia was formed to examine two key questions:
5861. What are the engineering activities or aspects of activities that are relevant to achieving
587secure software?
5882. What knowledge is needed to perform these activities or aspects?
589Based on the findings of this working group and a host of existing external documents and
590standards, the SwA CBK was developed and published to serve as a guideline. While this
591work has not yet been adopted as a standard or even a policy requirement of government
592agencies, it serves as a strongly recommended guide to developing more secure applications.
593The SwA CBK, which is a work in progress, contains the following sections:
594●
595Nature of Dangers
596●
597Fundamental Concepts and Principles
598●
599Ethics, Law, and Governance
600●
601Secure Software Requirements
602●
603Secure Software Design
604●
605Secure Software Construction
606●
607Secure Software Verification, Validation, and Evaluation
608●
609Secure Software Tools and Methods
610●
611Secure Software Processes
612●
613Secure Software Project Management
614●
615Acquisition of Secure Software
616●
617Secure Software Sustainment 18
618The following sections provide insight into the stages that should be incorporated into the
619software SDLC.
620‡ Software Design Principles
621Good software development should result in a finished product that meets all of its design
622specifications. Information security considerations are a critical component of those specifica-
623tions, though that has not always been true. Leaders in software development J. H. Saltzer
624and M. D. Schroeder note that:
625The protection of information in computer systems [… and] the usefulness of a set of
626protection mechanismsdependsuponthe ability ofa system toprevent securityviola-
627tions. In practice, producing a system at any level of functionality that actually does
628prevent all such unauthorized acts has proved to be extremely difficult. Sophisticated
62930 Chapter 1
630Copyright 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).
631Editorial 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.
6321
633usersofmostsystems areawareofat least oneway tocrash thesystem, denyingother
634users authorized access to stored information. Penetration exercises involving a large
635number of different general-purpose systems all have shown that users can construct
636programs that can obtain unauthorized access to information stored within. Even in
637systems designed and implemented with security as an important objective, design
638and implementation flaws provide paths that circumvent the intended access con-
639straints. Design and construction techniques that systematically exclude flaws are
640the topic of much research activity, but no complete method applicable to the con-
641struction of large general-purpose systems exists yet… 19
642This statement could be about software development in the early part of the 21st century, but
643it actually dates back to 1975, before information security and software assurance became
644critical factors for many organizations. In the same article, the authors provide insight into
645what are now commonplace security principles:
646●
647Economy of mechanism: Keep the design as simple and small as possible.
648●
649Fail-safe defaults: Base access decisions on permission rather than exclusion.
650●
651Complete mediation: Every access to every object must be checked for authority.
652●
653Open design: The design should not be secret, but rather depend on the possession of
654keys or passwords.
655●
656Separation of privilege: Where feasible, a protection mechanism should require two
657keys to unlock, rather than one.
658●
659Least privilege: Every program and every user of the system should operate using the
660least set of privileges necessary to complete the job.
661●
662Least common mechanism: Minimize mechanisms (or shared variables) common to
663more than one user and depended on by all users.
664●
665Psychological acceptability: It is essential that the human interface be designed for ease of
666use, so that users routinely and automatically apply the protection mechanisms correctly. 20
667Many of the common problems associated with programming approaches that don’t follow
668the software assurance methodology are discussed in Chapter 2, “The Need for Security.”
669For more information on software assurance and the national effort to develop an SA common
670body of knowledge and supporting curriculum, visit https://buildsecurityin.us-cert.gov/dhs/dhs-
671software-assurance-resources.
672‡ The NIST Approach to Securing the SDLC
673Each phase of the SDLC should include consideration for the security of the system being
674assembled as well as the information it uses. Whether the system is custom-made and built
675from scratch, purchased and then customized, or commercial off-the-shelf software (COTS),
676the implementing organization is responsible for ensuring its secure use. This means that
677each implementation of a system is secure and does not risk compromising the confidential-
678ity, integrity, and availability of the organization’s information assets. The following section,
679adapted from NIST Special Publication 800-64, rev. 2, provides an overview of the security
680considerations for each phase of the SDLC.
681Security in the Systems Life Cycle 31
682Copyright 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).
683Editorial 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.
684To be most effective, information security must be integrated into the SDLC
685from system inception. Early integration of security in the SDLC enables agen-
686cies to maximize return on investment in their security programs, through:
687●
688Early identification and mitigation of security vulnerabilities and misconfi-
689gurations, resulting in lower cost of security control implementation and
690vulnerability mitigation;
691●
692Awareness of potential engineering challenges caused by mandatory secu-
693rity controls;
694●
695Identification of shared security services and reuse of security strategies and
696tools to reduce development cost and schedule while improving security
697posture through proven methods and techniques; and
698●
699Facilitation of informed executive decision making through comprehensive
700risk management in a timely manner. […]
701Initiation
702During this first phase of the development life cycle, security considerations are
703key to diligent and early integration, thereby ensuring that threats, requirements,
704and potential constraints in functionality and integration are considered. At this
705point, security is looked at more in terms of business risks with input from the
706information security office. For example, an agency may identify a political risk
707resulting from a prominent Web site being modified or made unavailable during
708a critical business period, resulting in decreased trust by citizens.
709Key security activities for this phase include:
710●
711Initial delineation of business requirements in terms of confidentiality,
712integrity, and availability;
713●
714Determination of information categorization and identification of known
715special handling requirements to transmit, store, or create information such
716as personally identifiable information; and
717●
718Determination of any privacy requirements.
719Early planning and awareness will result in cost and time saving through proper
720risk management planning. Security discussions should be performed as part of
721(not separately from) the development project to ensure solid understandings
722among project personnel of business decisions and their risk implications to the
723overall development project. […]
724Development/Acquisition
725This section addresses security considerations unique to the second SDLC phase.
726Key security activities for this phase include:
727●
728Conduct the risk assessment and use the results to supplement the baseline
729security controls;
730●
731Analyze security requirements;
73232 Chapter 1
733Copyright 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).
734Editorial 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.
7351
736●