73
© 2011 by Taylor & Francis Group, LLC
Chapter 2
Enterprise-Wide Systems
Development Security
Maura Van Der Linden
Contents
Managing Security in Dierent Methods of Systems Development .....................75
Systems Development Life Cycle ....................................................................75
Proposal: Plan the Project ...........................................................................76
Gather Requirements ................................................................................ 77
Design the Project ..................................................................................... 77
Implementation: Build the Project .............................................................78
Verication: Test the Project .......................................................................78
Deployment ...............................................................................................79
Maintenance ..............................................................................................79
Rapid Application Development .....................................................................80
Pre-Project .................................................................................................81
Requirements .............................................................................................81
User Design ...............................................................................................82
Construction ..............................................................................................82
Implementation/Transition ........................................................................83
End Project ................................................................................................83
Security and Risk Analysis .................................................................................. 84
Security Elements in Systems Projects .............................................................85
Project Risk ................................................................................................85
Mandated Security .....................................................................................86
Security Cost ..............................................................................................88
74 ◾ Official (ISC)
2
® Guide to the ISSMP® CBK®
© 2011 by Taylor & Francis Group, LLC
Systems developed for use across an enterprise can fall victim to the myth that,
because they are not for sale or public consumption, they don’t need as much atten-
tion to security. In fact, this can be the complete opposite of reality. ere is often
more data to protect, internal company and employee information as well as cus-
tomer information. ese enterprise-wide systems also have more threats to protect
against that already have some sort of access—like internal attackers. Both of these
factors mean that enterprise-wide systems need a focus on security and secure prac-
tices as much as any system developed for external release.
e Enterprise-Wide Systems Development Security domain describes the role
of security management in dening, designing, developing, testing, implement-
ing, and maintaining the critical software infrastructure that supports today’s and
tomorrow’s business environment. e security manager has a crucial role to play
in protecting business operations through providing input to the development pro-
cess. is requires knowledge of various types of applications, software languages,
databases, and operating platforms. e security manager must understand the risk
and threats that are applicable to this environment and the countermeasures that
can be employed to minimize damage, loss, compromise, or manipulation of data,
systems, processes, and personnel. Key areas of knowledge include the following:
◾ Building security into the systems development life cycle
◾ Integrating application and network security controls
◾ Integrating security with the conguration management program
◾ Developing and integrating processes to identify system vulnerabilities
and threats
Security of Project Elements ...........................................................................89
Hardware .................................................................................................. 90
Operating System .......................................................................................93
Networks ...................................................................................................96
Web Servers .............................................................................................106
Other Applications ...................................................................................110
Project under Development ......................................................................112
Service-Oriented Architecture Security .....................................................121
System Testing ...................................................................................................123
Testing and Documentation of Security Elements .........................................123
Component Testing ..................................................................................124
Integrated System Testing .........................................................................124
Penetration Testing ...................................................................................124
Condential Test Data ..................................................................................124
Insider Attacks ..............................................................................................125
Certication and Accreditation .........................................................................125
Review Questions ..............................................................................................125
Enterprise-Wide Systems Development Security ◾ 75
© 2011 by Taylor & Francis Group, LLC
is chapter focuses on the management of security eorts in the development
of systems designed for enterprise-wide use rather than the implementation details
of various security measures.
Managing Security in Different Methods
of Systems Development
ere are two main types of system development methods: waterfall and itera-
tive. It’s important to understand these two methodologies and where security falls
within them in order to best manage security eorts to achieve the greatest success.
Typically, a development team is accustomed to using one type of method or the
other; the team is not very likely to ip between the two main types as they really
require dierent approaches.
ere are many examples of each of these, but the two listed here are the most
common. Keep in mind that every company and group puts its own spin on them
and modies them to meet its unique challenges or situations. None of them is
cast in stone, so you should always get a run-down from the project manager or a
knowledgeable person on the team you will be working with as to just what process
is in use and what stage the system being developed is currently in.
e closer to the start of a development project that functionality or features
are added, the less expensive they are. is is especially true for security measures.
But in the case of security, the measures are not only less expensive but also more
eective when planned into a system from the start of the design process.
Building security into a system as it is created has benets not only in terms of
how secure the completed system is, but also in the reduction of any pain or retrain-
ing for the users and administrators of the system. is can be an important aspect
of the overall eectiveness of security measures.
Attempting to graft security solutions or mitigations onto existing systems can
be expensive, incomplete, or inadequate and is often painful to the system’s users
and administrators. In fact, the older the existing system is, the more extreme these
issues can be—so the rule for any security is always “the sooner, the better.”
It bears mentioning that user convenience and education are important consid-
erations when implementing a security eort. Users are very prone to nding ways
not to use security that is too inconvenient or confusing if they can possibly nd a
way around it, and they are quite clever at nding workarounds that can jeopardize
security, even without malicious intent.
Systems Development Life Cycle
e Systems Development Life Cycle (SDLC) is probably familiar as it is the most
common waterfall systems development method, but the following is an overview
more specically targeted to security’s place in that process.
76 ◾ Official (ISC)
2
® Guide to the ISSMP® CBK®
© 2011 by Taylor & Francis Group, LLC
Despite the fact the traditional SDLC is typically shown as a purely waterfall
method in which one stage is begun only as the prior stage is completed, in practice
this is becoming less and less the case. Certainly when you are managing a security
eort, you cannot wait for a stage to nish before you think about and begin plan-
ning for the next stage. Keeping in touch with all the details and deliverables of the
project as it progresses through the SDLC is an ongoing and very necessary part of
eectively managing the entire system’s security needs (Figure2.1).
If you overlay security concerns and t them into the SDLC methodology, the
process now looks as shown in Figure2.2.
An overview of the SDLC stages and where security management ts into each
stage is as follows.
Proposal: Plan the Project
e rst stage of the SDLC is where the basic, high-level planning takes place.
Some systems start with a feasibility study and presentations or proposals to upper
management to sell them on the system and obtain necessary funding and buyo.
Some systems are already funded and approved or sponsored ahead of time.
Because this is the stage at which systems are assessed for their feasibility, it is
also the time at which a broad set of security aspects is considered. e ability to
appropriately secure the system and keep it secure over time is one part of the feasi-
bility equation. Another part is the ability to secure the source code and conden-
tiality of mission-critical or sensitive systems, both as they are under development
and after they are released or put into place.
Security needs are an integral component of any funding request. Nothing is
free, but having security needs not included in the initial estimates should never be
the reason why adequate security is not implemented.
Maintain access control and permissions.
Carry out log and access monitoring.
Periodically review Risk Analysis and Security
Plan in light of new threats.
Security review all system changes or upgrades.
Figure 2.2 Security integrated SDLC.
Require-
ments
Proposal Design
Implemen-
tation
Verification
Deployment
Maintenance
Figure 2.1 The software development life cycle.
Enterprise-Wide Systems Development Security ◾ 77
© 2011 by Taylor & Francis Group, LLC
is is the time a skeleton risk analysis study is conducted, and the security issues
already apparent in the plans being made are cataloged so they can be addressed in
greater detail in later stages of the SDLC.
Gather Requirements
e system proposal is usually approved and funded by the time the second stage of
gathering requirements is in full swing, although some requirement gathering may
have taken place before the system was formally proposed.
In this stage of the SDLC, the initial proposal is expanded and revised by
including requirements gathered from the parties that will be users, maintainers, or
regulators of the system under design. is includes testing/quality assurance (QA),
IT, legal, and the security manager, as just a few examples.
In this stage of the project, the skeleton Risk Analysis study is reviewed and
security-specic requirements are added to the system’s requirement list based on
the Risk Analysis’ planned or proposed mitigations to the assessed risks. e rela-
tive priority of each security requirement is noted to allow for educated triage deci-
sions at a later stage when cuts or compromises will need to be made.
e other big security-focused task during this stage is to actively participate
in determining and documenting a set of standards for secure coding, source code
control, documentation control, code reviews, and defect tracking of security issues.
e overall project manager of the system under development usually drives this,
but the security manager has a vested interest in this and must be willing to drive
it if necessary.
is is also the stage in which the exit criteria are set for when the system is con-
sidered completed and ready to deploy. Accurate, realistic, and reasonable security
criteria are an important part of these criteria.
Design the Project
is third stage of the SDLC is where requirements are translated into actual
designs and where requirements tend to be cut, if necessary, to meet the time or
budget constraints of the project.
Depending on the way the development and design team works, these system
designs may be done with a top-down approach—in which major components
are designed independently and then linked together. Other times the work may be
done bottom up—in which links and interfaces between components are designed
rst and then the component functionality is added. Neither approach is neces-
sarily better or worse than the other, but security issues and mitigations need to
remain a key focus. Security must remain a part of the design of all parts of the
system rather than allowing the common “add security at the end” mindset to jeop-
ardize the system’s overall success.
A particular risk to security during this stage occurs if part of the design is
being done by prototyping. If prototype code is rolled into the nished system,
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.