78 ◾ Official (ISC)
2
® Guide to the ISSMP® CBK®
© 2011 by Taylor & Francis Group, LLC
additional risks may be incurred. Prototyping with automated tools or wizards is
especially prone to having little or no security when code is generated, so constant
vigilance must be practiced to ensure that security is added before the prototype
code is included in the system.
In order to achieve the best results, security must be a carefully documented
part of the design generated in this stage of the SDLC.
is is also the stage where QA begins to develop a test plan, and security tests
must be an integral part of those plans as well. Successful completion of both pen-
etration and overall security testing is a necessary requirement in order to deploy
the system.
During this stage of the SDLC, the risk analysis is updated and a security
design document may be begun to demonstrate how and where security require-
ments t within the system as a whole. User stories and use cases, especially hacker
or attacker scenarios, are helpful ways to illustrate the security requirements and
better enable QA to test the system later. e security design document lives side by
side with and may be referenced by the system’s other design documents.
Implementation: Build the Project
is is the fourth SDLC stage and where the majority of development work is done,
and where the design created in the prior stage is turned into a working system.
During this stage, part of the security focus is to enforce adherence to the stan-
dards agreed on during the Requirements stage. Standards are only good if they are
actually used, and the impact of failing to adhere to these security standards is that
the associated security risks are not eectively mitigated.
Unit testing occurs as code is written, and some QA testing often starts on fea-
tures as soon as they are completed in this stage. While this stage continues, a watch
is kept on the defects being reported, especially any defects marked as being secu-
rity related. Finding these early and focusing on them allows both an opportunity
to catch security issues whose mitigations or xes are not correctly implemented as
well as a chance to nd and x previously unaddressed security concerns.
It’s also imperative that the risk analysis and security plan are kept up to date
as changes are made during the system’s actual development process. ese docu-
ments provide both the correct current information as well as serve as a historical
reference of the security-specic risks and mitigations for this system. is means
document change histories also need to be closely tracked and retained.
Verification: Test the Project
Stage ve of the SDLC is the Verication or test phase. In a strict waterfall method,
this would occur only after the prior stage is fully code complete, but this rarely
happens in practice anymore. Instead, testing and QA work typically begin back
Enterprise-Wide Systems Development Security ◾ 79
© 2011 by Taylor & Francis Group, LLC
in the Build stage and continue through this stage and often into the next stage as
well, to help verify deployment of the nal system.
Security must be tested as early as possible in order to minimize the impact and
cost of any xes required. Security defects found late can put even the product’s
schedule at risk. All too often security and penetration testing is done at a late point
in this stage, and that makes any issues found more expensive to x than if they
were discovered earlier. e closer to the end of the Test stage issues are found, the
more likely they are to be postponed or not xed at all.
Each bug led for the product must be examined and assessed for security rel-
evance to make sure no bugs led have unrecognized security implications to either
the defect or the defect’s x. Staying on top of this means there is a reduced risk
of having a security bug that is discovered or introduced during this phase make it
through to be discovered by a customer or attacker.
Deployment instructions and any documentation related to the system’s instal-
lation are reviewed at this stage for any security-related concerns integral to the
system’s deployment. ese concerns may include things like server permissions,
user settings, server settings, database setup and permissions, etc.
Before this stage is exited, the Security Plan and the Risk Analysis are reviewed
and each threat’s mitigation veried. is will help ensure that things have not
somehow slipped through the cracks. At the end of this stage, these two documents
are completely up to date and annotated with any changes or updates.
Deployment
is sixth stage of the SDLC is the stage that occurs after the system has been tested
and signed o on as meeting the criteria set in the Requirements stage. During this
stage, the security focus is to verify that the actual deployment being implemented
matches the tested and approved deployment plan and no new security issues are
created during the process of deployment. Each stage of the deployment is veried
as correctly carried out and functioning correctly. All aspects of deployment are
important to the system security.
It is highly desirable to rerun all security-related tests against the nal deploy-
ment before it is announced or released to the enterprise at large. is allows a further
chance to catch any errors in deployment or situations where the test environment
did not accurately reect the live or production environment. If all security-related
tests cannot be run, even a subset of the security-related tests can help.
At this time the security design document and risk analysis are updated with
details of deployment and archived.
Maintenance
Unlike most of the systems development team, the role of security is still very active
in this seventh stage of the SDLC. Security is an ongoing process, and the focus is
80 ◾ Official (ISC)
2
® Guide to the ISSMP® CBK®
© 2011 by Taylor & Francis Group, LLC
to maintain access control and permissions as well as to audit both user logs and
server logs and any access records for any evidence of attempted attacks or suspi-
cious activity.
Because security is an ever-changing landscape, periodic reviews of the risk
analysis and security design documents in light of any new situations, exploits,
threats, or requirements are needed in order to ensure the system, as deployed, is
still within the realm of acceptable risk or, if it is not, to drive changes or revisions
to bring it back within acceptable risk levels.
Rapid Application Development
Rapid Application Development (RAD) is the most common iterative systems
development method. It has some advantages over the more traditional waterfall or
modied waterfall of SDLC, but also some disadvantages.
RAD, by its nature, has considerably less time between releases available for
planning, fact-nding, and research. Issues and changes that are introduced late
in a cycle often run into this method’s signature hard-line message of never tak-
ing design changes after the initial Pre-Project or Requirements stage. is means
security issues and requirements must be brought up early and stressed frequently
to prevent them from falling o the radar and being deferred to a later cycle or
determined as an issue that will not be xed.
RAD also places a strong emphasis on reusability. is can be of particular con-
cern if the code or functionality being reused is not secure, because this can cause
security vulnerabilities to permeate the end system.
e premise of iterative development methods is to build increasingly more
functional systems using short, fast construction cycles with each one building on
the working system presented at the end of the prior construction cycle. RAD also
makes considerable use of prototyping and prototyping tools, and thus has a ten-
dency to fall victim to the issues of prototype code written via tools or wizards nd-
ing its way into the nished product without adequate security review or mitigation
of security risks. All reused and prototype code must be reviewed for security before
being included in the nal system.
Figure2.3 shows a basic illustration of the RAD process. Figure2.4 shows an
overlay of security concerns and tasks for each step.
RequirementsPre-Project User Design Construction
Implementation/
Transition
End Project
Figure 2.3 The basic Rapid Application Development (RAD) process.
Enterprise-Wide Systems Development Security ◾ 81
© 2011 by Taylor & Francis Group, LLC
Pre-Project
is is the rst stage in the RAD process and is usually completed before the start
of each systems development project, though its documents and information may
be further updated and modied as the project is under way.
During this stage, all of the details that aect the project as a whole are
determined. is includes what the project schedule will be, what the approach
to coding will be, the overall risks, etc. is is the stage in which security is
included as a project requirement and a careful examination of the tools, lan-
guages, prototyping, etc., that are decided upon must be made to identify risks
that must be mitigated and language or methodology concerns that require
special handling. ere are also security concerns around source control, defect
tracking, and other bookkeeping issues used during the actual systems develop-
ment eorts.
e overall project manager will develop a project plan during this stage, and a
skeleton risk analysis is begun to list the various security risks and mitigations that
aect the system. is will be built upon during each cycle of the RAD process
until the project is complete and will sit beside the project plan and other project
documentation or be referenced by them.
Requirements
In this second stage of the RAD process, initial customer requirements are gath-
ered, usually by a group of designers who conduct multiple meetings with key
customers and compile a draft list of requirements. ese meetings are brain-
storming sessions in which both the designers and the customers must partici-
pate fully to obtain the best results. If at all possible, the security manager for
RequirementsPre-Project User Design Construction
Implementation/
Transition
End Project
Include security
as a project
requirement.
Indentify risks
inherent in tools,
languages,
prototyping, and
methodology that
need mitigation.
Add skeleton
Risk Analysis to
the Project Plan.
Security Manager
participation at
requirements
gathering
meetings.
Build security into
project diagrams.
Document
security concerns
not typically
raised by users.
Update Risk
Analysis.
Review all new
diagrams and
design
documents for
security concerns
and risks.
Update Risk
Analysis.
Monitor and
enforce security.
Ensure continual
security testing.
Review all
documentation
for security
concerns.
Update Risk
Analysis.
Ensure
deployment plans
are followed and
security
mitigations
implemented.
Update Risk
Analysis.
Maintain access
control and
permissions.
Review and
monitor logs.
Periodically
review the Risk
Analysis and
security
documents in
light of new
threats.
Figure 2.4 The basic Rapid Application Development (RAD) process with an
overlay of the security concerns and tasks for each step.
82 ◾ Official (ISC)
2
® Guide to the ISSMP® CBK®
© 2011 by Taylor & Francis Group, LLC
the project needs to be a part of these brainstorming sessions in order to bring
security issues to light by asking relevant questions and raising potential con-
cerns early.
A typical deliverable from this stage is a set of project diagrams that show the
interaction between parts of the system along with the business entities that will
use the system and how. Security must be built into these diagrams and plans as
they are produced. is allows the RAD construction cycles to build these in as the
system is developed rather than having to add it later.
Another security focus during this stage is to understand and document the
requirements not usually considered by the business users. is includes things like
access restrictions, server and database security, etc. Because these things are not
typically considered by users, the security manager has to be sure to cover as many
of them as possible as early as possible to avoid negative impacts on the project
or late-requested security xes being postponed to a later release. Optimally, this
would take place in the brainstorming session but can be done later, if necessary.
e risk analysis is expanded to include any new security risks, mitigations, and
their priorities.
User Design
is third stage of the RAD process is focused on taking the rough requirements,
diagrams, and documents for the project and rening them into more detailed
design documents that are regularly reviewed with the key end users for accuracy
and any additional required information.
is is the stage that is most focused on setting a concrete schedule and development
of system dialogues and the look and feel of the user interface, among other things.
e focus of security at this point is to review the new diagrams and design
documents as well as the construction methodology for risks or security concerns
that are not yet documented. An example of this is secure coding processes and
known vulnerabilities that center around a particular language or software whose
use is listed as a system requirement. When security concerns are found, they are
added to the ongoing risk analysis document as well as documented in the ongoing
RAD documents for the system.
Construction
is fourth stage of the RAD process is the part that truly makes the process itera-
tive. In this stage, the software is actually coded and built with multiple cycles of
coding, testing, and revising. Depending on the size of the system, this may be
done by several small teams that are each assigned a portion of the system to work
on. Typically this is done under the constraints of a strict set of mini-schedules,
often referred to as time-boxing, and under the close supervision of the main proj-
ect manager.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.