Code review practice comes under which domain of bsimm

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 post­implementation 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 end­of­life

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 14­1 shows a 10­phase

SDLC model.

https://www.safaribooksonline.com/library/view/security-strategies-in/9780763791933/ch14.html#figure_14-1
Figure 14­1. 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 10­phase

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 pass­off meetings every time your project is ready to move from one stage to another. The

frequency of this phase pass­off depends on how you scope your projects. You have many different ways to scope

software development projects. Table 14­1 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

https://www.safaribooksonline.com/library/view/security-strategies-in/9780763791933/ch14.html#table_14-1
redesign. Include security requirements from the very beginning.

Table 14­1. 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 security­related activities into seven phases. The SDL's phases correspond to

phases in the SDLC. Figure 14­2 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

https://www.safaribooksonline.com/library/view/security-strategies-in/9780763791933/ch14.html#figure_14-2
code analysis to ensure new or modified code is secure.

Figure 14­2. 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 14­3. 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 14­3 shows the SSF's components.

The SSF's four domains organize activities into related practices. These domains address the high­level concerns

throughout the development life cycle. Here are the SSF domains, along with the BSIMM's definition of each one:

Governance