computer security#1556#13
MasterTec2
14.pdf
Chapter 14. Microsoft Windows and the Security Life Cycle CHAPTERS 11 AND 12 COVERED securing the Microsoft Windows operating system and securing Microsoft
Windows application software. In both cases the software was completed and in a production environment. All
efforts to secure the software depended on changing the application's environment, configuration settings, or
external controls. All of the changes you made to secure applications were postimplementation changes.
In this chapter, you'll learn about securing applications by creating or changing the application code. You'll also
study the software development process. You'll learn as well to develop secure applications. And you'll examine the
importance of formal testing, validation, and the configuration management process. Finally, you'll be able to
apply what you've learned to your own development environments and start making the application software you
write more secure from the very start.
Chapter 14 Topics
This chapter covers the following topics and concepts:
What system life cycle phases are
How to manage Microsoft Windows Operating System (OS) and application software security
How to develop secure Microsoft Windows OS and application software
How to implement, evaluate, and test Microsoft Windows OS and application software security
How to maintain the security of Microsoft Windows OS and application software
What Microsoft Windows OS and application software revision, change management, and endoflife
phaseout are
What the best practices for Microsoft Windows and application software development security
investigations are
Chapter 14 Goals
When you complete this chapter, you will be able to:
Describe system life cycle phases
Manage the existing Microsoft Operating System and application software security
Implement, evaluate, and test Microsoft Operating System and application software
Describe how to manage the process of secure software development
Understanding System Life Cycle Phases
Understanding System Life Cycle Phases In the early 1960s, application software developers realized the software development process needed some
structure. Computers were becoming more numerous and the need for programmers was growing. The capabilities
of hardware and software expanded. In turn, software development projects began to grow in scope. Organizations
that owned computers demanded more functionality from their large investments. That increased demand for
functionality required more sophisticated applications. Software developers began to collaborate to create systems
of software that were made up of numerous programs that worked together.
Software development began to look like an engineering process. It needed a model to help coordinate all of the
individual pieces and people involved. One emerged that is still in use in various forms today. That model is
the System Development Life Cycle (SDLC). It is also known as the Software Development Life Cycle. The
SDLC is a formal model for creating and modifying software. It breaks down the software development process
into between six and 10 phases, depending on whose version of the model you adopt. Figure 141 shows a 10phase
SDLC model.
Figure 141. An SDLC with 10 phases.
The SDLC uses industry best practices to guide software system development activities. Software development
activities have the characteristics of projects. Software projects have specific start and end dates. They also have
specificdeliverables. A deliverable is an object created as a result of project activities. Using the wealth of best
practices from project management for software development projects is a good fit. Project management
techniques help standardize the software development process. These techniques make it easier to identify
problems and fix them.
The SDLC provides both control and visibility of the tasks throughout the development project. It can also increase
the probability of success. The SDLC encourages the development processes to be repeated in a predictable
fashion. The SDLC has been around for quite a while in different forms. It has matured and changed with system
architectures, but the overriding themes have remained the same. Throughout the years, the SDLC has also been
called:
Classic Life Cycle Model
Linear Sequential Model
Waterfall Method
The most important concept in SDLC is decomposition, or breaking down a software development project into
distinct phases. From a security perspective, this practice provides specific points in time. These points in time
allow you to validate or test the product to ensure it meets requirements. You can never start testing too early. The
earlier you validate that your deliverables satisfy the requirements for the phase you are in, the more secure the
final product will be. The SDLC phases mark different activities along the development process. The 10phase
SDLC defines the following phases:
1. Initiation—This phase is where you scope and submit the initial project to management for approval and
funding. If management agrees, the process is formally authorized and the process moves to the next phase.
2. System/Information Engineering and Modeling—Here you collect information about your environment
and the environment's requirements. The idea is that you document everything your computing environment
has and any specific requirements or restrictions. For example, if your proposed software system requires
Microsoft IIS Web server and none of your servers has IIS installed, document this information. You'll need to
either change the Web server requirement or install IIS. You don't have to make decisions yet, but you'll need
these facts for later phases when making decisions. This information will provide a baseline of what your
environment currently does and what must be changed to support the new or modified application.
3. Planning—You develop your project management plan in this phase. The processes include resource
requirements and scheduling. The deliverables of the planning phase direct the remainder of the software
project.
4. Software Requirement Analysis—You'll document what the software must do in this phase. This includes
both functionality and security requirements. Study the business needs that the software will meet. List them
in terms of business functions.
5. System Analysis & Design—Once you know details about your environment and what the software must do,
begin the process of designing software that will fulfill business requirements. The deliverable of this phase is a
complete design document that describes the software. You haven't written any software yet—you have just
described it. Your descriptions can be formal, such as using unified modeling language (UML), or informal
using your own standards. The important point is that the development team clearly understands what it needs
to write. This is also the last chance to ensure your project is still on track before coding begins. If there are any
design documents that do not satisfy the requirements from the previous phase or do not fit with your
environmental requirements, address those before continuing.
6. Code Generation—This phase is not the starting point. By this stage of the SDLC, most big decisions have
already been made. Ensure that all code generated during this phase meets the design criteria from the
previous phase. The code you generate in this phase should operate correctly.
7. Formal Testing—This phase is the first formal mention of testing. However, you should have been validating
that each phase's deliverables meet the requirements of the previous phase's deliverables. Thorough validation
can save a lot of wasted programming effort.
8. Implementation—The implementation phase represents the point in the project where the customer accepts
the software product and the software moves into a production environment.
9. Maintenance—This is typically the last phase. It is the step after implementation. Once in the maintenance
phase there are really only two main reasons to modify the application. One reason to modify the application is
enhancement request. The only other reason to modify the application is to fix a bug. In either of these
situations, the correct approach is to return to Step 1 and go through the whole process again. However, you
don't start from scratch. This time you have all of the deliverables from the previous phases. You simply start
with a description of what you want to change, and then go through each phase until you end up with modified
code. By ensuring that even code fixes meet the application's design goals, you avoid many of the situations
where a fix breaks something else. It takes a little longer, but you save time and money by not chasing as many
bugs later.
10. Disposition—This phase represents the activities related to retiring a software product and cleansing any
hardware of sensitive data. In nearly all cases, plan to either archive application data or transfer it to another
system. The disposition phase addresses all of the activities that reverse the actions in the implementation
phase. By the end of this phase, you have completely removed all of your sensitive data from any hardware or
devices that may be sold or recycled.
The SDLC formalizes the development process. This process also keeps you from jumping ahead and writing code
that doesn't satisfy requirements. Don't make the mistake of allowing your team to start the project by writing
code. You will almost always end up either ditching or rewriting at least parts of software you develop without
planning. Some development approaches rely on prototyping at the beginning of projects. Even in these cases,
though, you should have already put plans in place for ensuring any code is secure. Any time your software has to
interact with other system components, carefully decide how it should operate. That requires time to make
decisions before writing code.
Keep two important points in mind when following the SDLC. One, precede the code generation phase with several
iterations of modeling and design. Two, validate each phase's deliverables. By the time you reach the code
generation phase, make certain you have substantial documentation on the software's purpose, requirements, and
design. It should be fairly easy to validate whether or not software written in this phase satisfies the system design.
Each phase has defined deliverables. A phase in the SDLC ends when the project team has accepted the
deliverables for that stage. Deliverables are up to standard when they satisfy all of the goals, including security
goals. Each phase generally culminates with a meeting of the project team to review the phase's deliverables. When
the team agrees that the deliverables are valid, the phase ends and the project moves to the next step. Phase
validation and testing should identify any areas in your project where you have deviated from the prior phase's
deliverables. Make sure that the deliverables for each phase satisfy all preceding deliverables. Testing at every
phase ensures that your team will quickly spot any variances from the stated design. Early detection of problems
allows you to fix the problems with the minimum cost and disruption to the project.
Managing Microsoft Windows OS and Application Software Security A security representative participating in the development process is your key to managing software security. One
benefit of a model like the SDLC is the group nature of the process. If you formally implement the SDLC, you'll
have required phase passoff meetings every time your project is ready to move from one stage to another. The
frequency of this phase passoff depends on how you scope your projects. You have many different ways to scope
software development projects. Table 141 lists the three main approaches to software project scope.
In most environments, the best choice is to create a project for a group of related software programs. This balances
the advantages and disadvantages of the other two extreme approaches. This approach also makes it easy to
include maintenance modifications after you have implemented your software product.
Once you decide how you will scope projects, include a security component in every phase. Incorporating security
in the earliest phases of software development increases the application's security and decreases the cost of adding
safeguards. In fact, many development organizations have one or more security specialists on the development
team to ensure such concerns are met. All too often organizations add security features late in the development
cycle. Waiting too late in the design or development process may cause problems that could force a partial
redesign. Include security requirements from the very beginning.
Table 141. Common approaches to setting software project scope.
APPROACH ADVANTAGES DISADVANTAGES
Create one project
to develop a
complete software
application.
Single project
Ultimate
visibility
Difficult to sift through
tasks to find related work
Difficult to move to
another phase until all
components are ready
Very difficult to manage a
large number of related
components
Create a new project
for each individual
program.
Ultimate
flexibility
Difficult to define inter
project dependencies
Easy to move
from one
phase to the
next
Status reporting among
multiple projects is
difficult.
Create a project for
a group of related
software programs.
A balance of
flexibility and
visibility
Easy to
manage
groups of
related
programs
together
Must maintain inter
project dependencies
Some projects may have to
wait for dependent
projects before moving to
a new phase.
Another way to ensure your applications include security concerns early in the development process is to pursue
security training for developers. Security classes are available that specifically target software developers. It makes
sense to find good training for your analysts and developers to help them learn how to write more secure
programs.
Along with ensuring your software developers are fully trained to write secure code, make sure your development
environment and tools don't get in the way. Many of the latest development environments integrate tools with
secure libraries to empower developers to write more sound applications. One of the most popular development
environments for Windows applications is Microsoft Visual Studio. Visual Studio supports developers working in
Visual Basic, Visual C/C++, Visual C#, and F#. Visual Studio includes many features and tools for developing
secure applications, including:
Code analyzer—Identifies many coding errors
Application verifier—Identifies stability, compatibility, and security issues
Compiler option—To help prevent buffer overflows
Secure libraries—For use in applications
Security exceptions—For debugging
Each time programs move from one phase to the next, conduct a security review. It is also a good time to perform a
risk analysis. The review should cover the programs that have changed to ensure no new vulnerabilities have been
introduced into your software. Start your security reviews with the very first phase. Microsoft has formalized the
inclusion of security activities into the classic SDLC. To punctuate the need for integrating security into all phases
of the development life cycle, Microsoft developed the Security Development Lifecycle (SDL). According to
Microsoft, the SDL "... is a security assurance process that is focused on software development." The company
based the SDL on three core concepts that support secure development: education, continuous improvement, and
accountability. The SDL groups securityrelated activities into seven phases. The SDL's phases correspond to
phases in the SDLC. Figure 142 shows the phases and activities of the SDL.
The Microsoft SDL defines the following phases of development activities:
Training—Ensure all developers are fully trained on security development topics before engaging in any
software application development activities. Training all developers on secure development techniques is
crucial to creating secure applications.
Requirements—This phase corresponds to the SDLC Software Requirements Analysis phase. During this
phase, the development team establishes security requirements as well as creates quality gates and conducts
security and privacy risk assessments.
Design—This SDL phase corresponds to the SDLC System Analysis and Design phase. SDL activities include
establishing design requirements, analyzing the application's attack surface, and modeling threats to the
application.
Implementation—This SDL phase corresponds to the Code Generation SDLC phase. During code
generation, SDL activities include using approved tools, deprecating unsafe functions, and performing static
code analysis to ensure new or modified code is secure.
Figure 142. The Microsoft Security Development Lifecycle (SDL)—simplified.
technical TIP
Find more information on the Microsoft SDL by visiting the SDL Web page at: http://www.microsoft.com/sdl.
Verification—This SDL phase corresponds to the Formal Testing SDLC phase. Formal testing focuses on
evaluating functionality, while verification activities include dynamic code analysis, fuzz testing, and attack
surface reviews.
Release—This SDL phase corresponds to the Implementation SDLC phase. Once you implement application
changes, you can create or update the incident response plan and conduct a final security review.
Response—This phase comes into play when an incident occurs. The response phase corresponds to
executing your incident response plan.
The Microsoft SDL extends the classic SDLC and complements standard development activities with a security
related focus. It provides managers with a prescribed method to ensure that the software development process
pays appropriate attention to security matters. The three core concepts ensure that developers are well educated,
always improving the development process, and accountable for the code they write.
Developing Secure Microsoft Windows OS and Application Software By this point you should be soundly convinced of the importance of securing your organization's data. You've seen
many techniques to limit access to critical resources and make your data more secure. Some of the controls you've
read about directly correspond to software vulnerabilities. If your development organization could create more
secure software, you wouldn't have to invest quite so much time and money to compensate for software
vulnerabilities. From one perspective, secure software is its own control. So, how do you get started putting the
SDLC and SDL models into action? How do you make it all result in more secure code?
A newly published framework can help you design a development process that works in real organizations.
The Building Security in Maturity Model (BSIMM) is the result of a study of large organizations that
develop software with a specific focus on security. The organizations studied include Microsoft, Adobe, Google,
Bank of America, Intel, Sallie Mae, Nokia, and Capital One. The BSIMM reveals how 30 large organizations use
developer training, tool selection, and conducting the right activities to develop secure applications. This study
wasn't based on theory, but rather it reported on real situations in today's environments.
Figure 143. The Software Security Framework (SSF).
The BSIMM defines 109 unique activities, along with the frequency each activity was observed during the study.
While that sounds like a lot of work for a development group that is just starting to look at security, the BSIMM
makes it clear. The BSIMM also organizes the 109 activities into a framework, called the Software Security
Framework (SSF), that groups 12 practices into four domains. Figure 143 shows the SSF's components.
The SSF's four domains organize activities into related practices. These domains address the highlevel concerns
throughout the development life cycle. Here are the SSF domains, along with the BSIMM's definition of each one:
Governance—"Those practices that help organize, manage, and measure a software security initiative. Staff
development is also a central governance practice."
Intelligence—"Practices that result in collections of corporate knowledge used in carrying out software
security activities throughout the organization. Collections include both proactive security guidance and
organizational threat modeling."
Secure Software Development Lifecycle (SSDL) touch points—"Practices associated with analysis and
assurance of particular software development artifacts and processes. All software security methodologies
include these practices." The touch points provide direct correlations with activities in the SDLC. The activity
groups in this domain include Architectural Analysis, Code Review, and Security Testing.
FYI
You may be thinking that the BSIMM looks like just another model. At a high level it is. But the BSIMM is a direct result of observing development behavior that works and produces secure results. That is not
to say that the participating organizations produce perfect software. These organizations have simply identified activities that decrease the number of software defects they produce. And the BSIMM translates directly into defined activities that you can put into practice in your organization. You don't have to figure out how to implement a model's theoretical steps.
technical TIP
For more information on BSIMM and SSF, visit their Web site at: http://bsimm2.com/.
Deployment—"Practices that interface with traditional network security and software maintenance
organizations. Software configuration, maintenance, and other environment issues have direct impact on
software security."
The SSF makes it easy to identify and organize activities in which you should engage throughout the software
development process. If you want to simplify the process of developing secure software even further, it all boils
down to four areas of focus:
Secure development training—Untrained developers lack the understanding, skills, and motivation to
expend extra effort to incorporate security into their code. That may sound harsh, but it is true. While software
developers are generally savvy enough to get the training they need on their own, your organization will fall
short of its secure software development goals if you ignore the need to provide comprehensive security
training for your developers.
Include security from the beginning—Don't wait for coding to begin to include security concerns. Security
goals should be part of the initial requirements and subsequent design of any software.
Use secure programming techniques—Here's where the training pays off. Since you know what attackers
are looking for and what they can use to compromise an application, don't give it to them. Write applications in
a way that is not vulnerable to known tactics.
Test for vulnerabilities—Part of the formal testing activities should include testing for security
vulnerabilities.
Each language has its own set of known vulnerabilities and techniques to avoid them. Learn how to write solid,
secure code in your languages of choice. While languages often suffer from different vulnerabilities, a few common
programming errors lead to insecure code. If you can't implement a complete secure application development
initiative immediately, you can at least alert developers to avoid a few common pitfalls for code they write. Here
are a few of the most common application vulnerabilities:
Lack of input validation—Attackers know that developers often don't validate data that comes from user
input. They use this known issue to launch buffer overflows, injection attacks, and other attacks that rely on a
lack of input checking. To avoid this in your applications, confirm that every piece of data you receive is valid
before you use it in any way. That means you should check the length of the data as well as the content for any
characters that the software might interpret as commands.
Information leakage through poor error handling—One of the early phases of any attack is
reconnaissance. Attackers poke around to get information about your application and internal infrastructure.
Error messages can be a problem. You want your error messages to provide enough information to understand
what has happened but not enough to divulge internal details of your application or environment. Consider
using coded error messages instead of explicit details.
Sloppy authentication or encryption—Some applications store authentication credentials or encryption
keys either in the application code or in easily accessed files. If attackers find these pieces of information,
neither the authentication nor the encryption offers much data security. Carefully design how you'll protect
authentication credentials and encryption keys.
Remote system access or code execution—Some applications allow users to access the server's file
system or run commands on the server. While the intention is to restrict what users can do, many software
applications lack the controls to ensure users aren't abusing this feature. Carefully validate any commands
from users that will result in server access of any type.
Dynamic code execution—Developers write many applications, and especially database applications, so
that some code is dynamically generated before it is executed. This feature is an efficient way to handle
complex database queries where you don't know all of the query components until the user provides some
input. Dynamic code is also helpful when code execution depends on data at runtime. Using dynamic code also
can make it easy for attackers to alter the intended commands and run malicious code dynamically. A secure
application limits the use of dynamic code and aggressively validates any input to ensure it doesn't contain
malicious data or instructions.
These vulnerabilities are just a few of the opportunities application developers have to make code more secure.
There is no substitute for good developer security training. Make sure to train all of your developers on application
vulnerabilities and how to write secure code.
Implementing, Evaluating, and Testing Microsoft Windows OS and Application Software Security Once you complete the code generation phase of any software project, have a reasonable level of confidence that
the software meets your security and functional requirements. However, any program changes may have
unexpected side effects when interacting with other programs. The purpose of formal testing is to evaluate how
well your application meets overall performance, functionality, and security goals. Once your development group
approves a set of application changes for testing, then the testing group applies any changed programs to their
separate environment and carries out test scenarios.
Every goal from the original specification should have at least one corresponding testing scenario. The testing
scenario evaluates whether the application satisfies the goal. Every time you identify a vulnerability in your
application, include a scenario in your testing package that assesses whether or not a vulnerability exists. Your
testing activities can be both manual and automated. Manual code reviews and functionality testing can be very
valuable for finding obvious flaws, but automated software analyzers or testing tools allow you to test for far more
vulnerabilities in a short amount of time. Numerous companies produce quality application testing and evaluation
tools. Here is a list of a few companies that produce products to help you test your applications:
Microsoft—http://www.microsoft.com/visualstudio/enus/products/2010editions/test
professional
Coverity—http://www.coverity.com/
Fortify—http://www.fortify.com/
Ounce Labs—http://www.ouncelabs.com/
Warning Don't think that once you fix a security vulnerability it stays fixed forever. It is not uncommon to see vulnerabilities you previously fixed get reintroduced into your code. Once you identify a particular vulnerability, always test future code for the presence of that vulnerability. This is also known as regression testing.
An ideal world features at least three environments: development, testing, and production. First, your code must
pass all of the required tests in the testing environment. Then, it is ready to release to your production
environment. This is the purpose of the implementation phase of the SDLC. Copying programs from your testing
environment to the production environment may not seem difficult, but it can cause issues if not handled properly.
The best way to handle implementation is to create a copy of a production environment. Then, have your testing
group test the implementation process in that environment. Passing an implementation test means you should
have no problems when you implement the real code to the real production environment.
One additional common security control for the software development environment is to employ separation of
duties. Since software developers can write software that accesses sensitive data, they have the ability to
compromise your data's security. One way to protect your production data from a malicious developer is to not
allow any developers to have access to production. Developers write code and can place their software in the
testing environment. When testing is complete, another role must have access to move software from testing into
production.
So, what can happen from just copying code to production? Lots. Today's applications tend to be large integrated
systems that depend on many small modules of code. If any don't work properly, the whole system could
encounter problems. This brief list includes some of the problems you might encounter if you implement faulty
code to a production environment:
Inconsistent code and schema changes—Many of today's applications depend on database management
systems to access their data. Database management systems use formal declarations, calledschemas, to
describe databases. When you change the way a table or column in a database is defined, you change the
database's schema. Programs rely on the database schema to access data and know how to use it. If you
implement programs that expect a new schema to a production environment that still has an old schema, your
programs may encounter problems. Depending on the language and the database product you use, your
programs could either return errors or crash.
Interfaces with other programs not consistent—Programs generally work with other programs. To do
that, each program has to know how to invoke other programs and what kind of data to exchange with them. If
you change a program's data requirements but neglect to change other programs that expect to exchange data
with that first program, they will likely not be able to operate together any longer. Those problems will
probably cause errors or program crashes.
Faulty installation procedure—Due to local environmental differences, your production environment may
be slightly different from your testing environment. Any subtle differences, such as folder locations, file
permissions, or even defined printers could cause your programs to behave in an unexpected manner.
You may encounter many more potential issues when implementing programs and application changes. It is
important to isolate as many issues as possible during your formal testing. However, you won't identify every
problem during testing. Some problems are dependent on the production environment. You won't see these issues
until your application is up and running in production. For this reason, it is necessary to test and evaluate any
application changes after implementation.
Warning Use caution when testing code in production. You don't want to run a test that may slow the system down or cause it to crash. Be very restrictive about whom you allow to run tests in a production environment and which tests you run. As a general rule, avoid running any unnecessary tests or evaluations in your production environment.
After installing changes to your application, have your production team execute controlled evaluation scripts that
validate the new software functions as prescribed. These tests also ensure that the software doesn't do what it isn't
supposed to do. Once you are comfortable with the code's functionality, test its security level. One of the best ways
to test for security vulnerabilities in code that is in production is a penetration test. You should be conducting
penetration tests periodically anyway, so this point in the implementation phase is an effective place to do it.
Schedule a penetration test soon after you install any application changes. The test will validate that your changes
are secure and that no new vulnerabilities exist in your software.
Maintaining the Security of Microsoft Windows OS and Application Software In earlier chapters, you learned about securing Windows operating systems and software. In this chapter, you've
found out how to develop secure software. To make sure you have the most secure environment to develop secure
software, combine all of these topics. Your development environment and tools need to be up to date just like the
rest of your application software. Likewise, ensure the operating systems on all of your software development
computers have the latest security patches. Take the time to treat your development environment computers like
production computers, and make sure they are hardened and current.
Once you have confidence that your development environment is secure, provide the same level of assurance to
your customers. Just as you expect to receive timely operating system and application software updates to address
any newly discovered vulnerabilities, so do your clients. It doesn't matter whether the recipients of the software
you develop are internal customers or external customers. Your goal is to provide them with secure software,
including periodic updates. Prioritize your software development to address any vulnerability discovered in your
application software. Don't take any shortcuts, but make every attempt to release security patches that address
known vulnerabilities as quickly as possible.
Maintaining a software application often requires making difficult decisions. It would be nice to deliver every
request in the order it was received. Realistically, you'll run into times when you have to fast track software
modifications. Your customers may need a critical new feature. Alternatively, you may have to address a newly
discovered vulnerability or management may simply require you to implement a specific service or function as a
priority. Or your organization may require you to suspend or postpone scheduled maintenance software
development to address other critical projects. Although it is tempting to treat fast track projects differently than
regular development, try not to bypass your development controls to speed up the process. Extreme cases calling
for speedy fixes are inevitable. So when they crop up, make sure you document what you did and have a plan to
reconcile the production change with testing as soon as possible. The secure development process you adopt isn't
there to slow you down—it's there to protect you from making common mistakes. Don't proceed without these
protections simply to try to increase the speed with which you deploy maintenance patches.
Releasing patches every few days can make your customers' system administrators scramble to validate and test
each patch before they apply it. While not all organizations test new patches in isolated environments, some do.
Those that do test patches before applying them to their production environments can get overwhelmed with
frequent patches. Further, applying patches generally requires some type of a privileged user account. Frequent
updates or patches mean more opportunities for problems during the installation process and more potential for
attackers to compromise your environment during installation.
Also, check that all maintenance procedures protect your data's security. For example, if a security patch or feature
upgrade requires data conversion, one approach is to export the data to an external file and import the file into a
new or modified database table. This strategy will expose the data while the program stores the data on disk. You
could store the data in an encrypted folder to protect it from other users, but the disk still resides, at least
temporarily, outside of the database and its internal access controls. Take care that you don't expose any data
during maintenance procedures. Keep it secure at all times.
Microsoft Windows OS and Application Software Revision, Change Management, and End-of-Life Phaseout
Developing software is basically the process of creating a collection of useful programs. Unlike other engineering
disciplines, software development isn't quite like building physical objects. Software development is far more
flexible than building physical objects and generally far less constrained. Software development is as much an art
as it is a science. The truth is, software is easy to change. Sometimes it's too easy. And not only is it easy to change,
but controlling those changes in a group environment can be difficult.
When you develop software in a group that is uncontrolled and undirected, imagination can easily turn into a
nightmare. That's where models and control methodologies come into play. Although the SDLC and the SDL
provide solid frameworks for organizing software development efforts, they still have some issues. Many software
development organizations that adhere to the SDLC or the SDL find three main areas of difficulty in producing
software products.
Software Development Areas of Difficulty The first issue is Phase Identification. As simple as it may sound, knowing where you are in the SDLC or SDL flow
is not always obvious. The reason behind the difficulty is that different parts of a software application may be at
different phases at any point in time. For example, the modifications to an accounting report may be ready for
testing while a program changed to fix tax calculation bugs is ready to be released to production. To make matters
worse, the new bug found in the general ledger posting programs hasn't been fixed and requires more work.
With so many programs in different development phases, how do you define and communicate which versions of
programs are in a specific phase? In other words, how do you know what programs you have at any time in any
phase? As the number of developers and the number of programs increase, the problem can get progressively
worse.
The second issue, Phase Transition, can also be confusing. Making the transition from one phase to the next often
is more complex than it first appears. You need to get answers to several questions each time you move from one
phase to another. These questions include:
Which programs are ready to move to the next phase?
Has the development team documented and approved the phase transition?
Is the receiving phase prepared to receive the migrated objects?
What is the residual impact to the receiving phase of migrating objects?
The last of the common issues with software development is activity coordination. It is important that all changes
to objects and phase configurations are communicated to all interested parties and agreed to by all necessary
parties. Make sure objects aren't copied to a new place without prior notice or approval. Document every change
and provide a method to undo changes if needed.
Software Control Regardless of the specific software development method you use, refer to these common needs for control
throughout the development process:
Baseline identification—It is important for any software project to be able to identify which version, or
collection of object versions, of an application exist in any defined collection, or configuration. For example,
you need to know which versions of program are currently in production, which versions are being tested, and
what your developers are currently modifying.
Control of changes—Since it is almost guaranteed that you will change some of your software, either to
address problems or enhance the functionality, you need to control how you change those items. Change
control includes the ability to enforce rules that govern how you change items, who can change them, and when
you can change them.
Communication—Another common need in any business endeavor is communication. Since software
applications are comprised of programs and other components that must work together, it is crucial that all
interested parties are in the loop throughout the change process. Good communication when using any model
is essential to ensure your software satisfies its intended requirements.
Repeatable process—Doing anything well once is good, but doing it well over and over again increases
product quality and reduces costs. Software control provides the ability to learn from what you didn't do well
last time, implements controls to keep the bad stuff from happening again, and helps you do a better job next
time. In short, good software control impacts your bottom line by minimizing loss.
Software Configuration Management (SCM)
Software Configuration Management (SCM) The traditional software configuration management (SCM) process is a collection of best practices for
handling changes in software projects. It is up to each organization to implement tools and techniques that identify
both the functional and physical attributes of software at various points in time, and then perform systematic
control of changes. This application of SCM allows you to maintain software integrity and traceability throughout
the software development life cycle and proactively manage all your software assets. The SCM process defines the
need to trace changes, and the ability to verify that the final delivered software has all of the planned
enhancements that are supposed to be included in the release. SCM identifies four procedures, also called
activities, that must be defined for each software project to ensure a sound SCM process. The four SCM activities
are:
Configuration Identification—The process of identifying the attributes that define every aspect of a
configuration item. A configuration item is a product that has an enduser purpose. In the context of software
development, configuration items commonly include files and schema definitions. The files in a software
product can include program code, documentation, configuration files, and data files. A structured collection,
or collection of specific item versions, is called a baseline, or configuration. A baseline allows the definition of a
snapshot of a configuration and enables change control.
Configuration Control—Configuration control is a set of processes and approval stages required to change a
configuration item's attributes and to rebaseline them. Any changes to item versions can only occur by
following defined procedures. Item version changes include adding and removing items, modifying item
versions, and modifying item attributes. The Configuration Control Board (CCB) plays a central role in
the configuration control process. It can have many or few members and is responsible for making decisions
about changes to the system definition during the course of the development life cycle.
Configuration Auditing—Configuration auditing is the process of confirming that all system components
that should be in a given baseline are present. It is how management ensures that a software project is on track
and building what is actually required. As long as a software product complies with all requirements in the
current baseline, and all requirements in previous baselines, the product is valid. The process of conducting an
audit can be straightforward or very complex, depending on the specific requirements. At the highest level,
configuration auditing checks the current software product to ensure it satisfies the baseline requirements.
More indepth validation may be required to ensure any changes since the previous baseline have not
invalidated other functionality. In short, the software must still satisfy all requirements. Configuration auditing
also ensures that a project satisfies all requirements. Ensuring that changes meet requirements is backward
looking validation. Ensuring all requirements have been satisfied is forwardlooking validation. Configuration
auditing checks that the baseline scope of work has been fully satisfied without violating existing requirements.
Configuration Status Accounting—Configuration status accounting is the ability to record and report on
the configuration baselines associated with each configuration item at any moment in time. Basically, it is a
snapshot of a configuration. It ensures that a complete and accessible record of the changes to a software
system and reasons for such changes are available. The objective in configuration status accounting is to record
item attributes, as well as why changes are made, when changes are made, and who made the changes.
Configuration status accounting is often a reporting function that pulls the required information out of data
stores created and managed by the configuration control tools in the SCM system.
Table 142. Common SCM tools.
PRODUCT WEB SITE CLASSIFICATION
IBM
Rational
ClearCase
http://www01.ibm.com/software/awdtools/clearcase/ SCM
Apache
Subversion
http://subversion.apache.org/ VCS
Borland
StarTeam
http://www.borland.com/us/products/starteam/index.html SCM
Microsoft
Team
Foundation
http://msdn.microsoft.com/en
us/library/fda2bad5(v=VS.100).aspx
VCS
Mercurial
SCM
http://mercurial.selenic.com/ SCM
Roundtable
TSMS
http://www.tugboatsoftware.com/roundtable/ SCM
SCM is far more than just version control. Version control systems keep track of all changes made to a file over
time. Each change creates a new version of the file. Keeping track of changes you have made to files is important
both to research a history of changes and also to have the ability to revert back to a previous specific version of a
file. SCM includes version control, but also adds build management, promotion management when promoting
software from one configuration to another, and unit of work management. Each SCM toolset provides different
capabilities, but they all help control the software development process. Table 142 lists some common SCM tools.
Each tool's classification is either Software Configuration Management (SCM) or Version Control System (VCS).
Best Practices for Microsoft Windows and Application Software Development Security Investigations Creating and maintaining secure applications is the topic of many books and articles. It has emerged as an
important concern for software developers. Numerous models and frameworks tell you how to write cleaner, more
secure code. One of the main reasons the BSIMM model is so valuable is that it reports on what works in the area
of secure application development. When considering any new procedure or technology, it is wise to learn from
those who have already used it. Learn from other people's mistakes, and adopt strategies that worked. Plan well
and you can enjoy a more productive software development environment. The following best practices for
developing secure Windows applications represent what many organizations have learned:
Think of security early and often.
Adopt a software development model to help define your organization's development activities and flow.
Define activities for each phase in your model.
Ensure all developers are trained to develop secure applications. Look for developer training from:
SANS—http://www.sans.org
SEI—http://www.sei.cmu.edu/
Cigital—http://www.cigital.com/
Validate your software product at the end of every phase.
Create separate software projects for each related group of programs or program changes.
Do not begin a software development project by writing code—plan and design first.
Keep the three SDL core concepts in focus—education, continuous improvement, and accountability.
Develop tests to ensure each component of your application meets security requirements.
Study the most common application vulnerabilities and develop programming standards to ensure you don't
include the vulnerabilities in your application.
Identify and store programs, files, and schema definitions in a centralized, secure repository.
Control and audit changes to programs, files, and schema definitions.
Organize versioned programs, files, and schema definitions into versioned components.
Organize versioned components and subsystems into versioned subsystems.
Create baselines at project milestones.
Record and track requests for change.
Organize and integrate consistent sets of versions using activities.
Maintain stable and consistent workspaces.
Ensure reproducibility of software builds.
Using these best practices as guidelines will help your organization develop more secure applications and be more
responsive to your customers.
CHAPTER SUMMARY
Securing applications that someone else wrote is one thing. Writing your own applications and ensuring they are
secure requires a different focus. Before starting any development activities, prepare to develop secure
applications. Preparation includes establishing or adopting a framework and using it to develop standards and
procedures. Writing secure applications requires that your developers start off by receiving proper training on
secure development topics. Then they'll work closely with your security personnel to incorporate security into any
development project from the beginning.
In this chapter, you learned how useful models and frameworks can be. You learned about how to formalize the
software development process and how some large organizations structure their secure development activities.
You read about the importance of controlling the development process and how SCM can provide the structure to
develop complex applications. Take what you've learned, and start directing your organization's development
activities toward writing secure application software.
KEY CONCEPTS AND TERMS Building Security in Maturity Model (BSIMM)
Configuration Control Board (CCB)
Decomposition
Deliverables
Schema
Security Development Lifecycle (SDL)
Software configuration management (SCM)
Software Security Framework (SSF)
System Development Life Cycle (SDLC)
CHAPTER 14 ASSESSMENT 1. A deliverable is an object created as a result of project activities.
1. True
2. False
2. Which of the following is the most important concept in SDLC?
1. Initialization
2. Writing code
3. Decomposition
4. Disposition
3. In which SDLC phase do you collect information about your current computing environment?
1. Initialization
2. System/Information Engineering and Modeling
3. System Analysis and Design
4. Implementation
4. Testing occurs only immediately after code generation.
1. True
2. False
5. Microsoft identifies the most important component of security by placing the ________ phase as the first
phase of the SDL.
6. Which SDL phase corresponds to executing your incident response plan?
1. Requirements
2. Verification
3. Response
4. Release
7. The ________ framework is based on secure development practices of 30 larger organizations.
8. Which SSF domain most closely maps to SCM?
1. Governance
2. Intelligence
3. SSDL Touchpoints
4. Deployment
9. A common application vulnerability that can lead to several other vulnerabilities is a lack of input ________.
10. A ________ is a description of the data stored in a database.
11. Which SCM activity verifies that all of the components that are supposed to be in a configuration are in the
configuration?
1. Configuration Control
2. Configuration Auditing
3. Configuration Identification
4. Configuration Status Accounting
12. The ________ authorizes all change to an application.
13. A structured collection, or collection of specific item versions, is called what?
1. Release
2. Work package
3. Configuration item
4. Baseline
