9781284239614_Ch09_Pass1.fm Page 209 Friday, October 9, 2015 2:31 PM
DEVELOPMENT AND IMPLEMENTATION C HA P T E R
9
.
Development is a critical phase for any software system. This is when the security
requirements are either met or lost. It is also the phase of development in which the
attack surface of the system sees the most growth; this is caused by the increase in the
technology needed for the system to actually implement the requirements established
and perform according to the regulations determined in the planning phase. A decision
needs to be made with regard to the system architecture, the hardware that will be used,
support resources needed, and software solutions implemented. Part of assessing the
software needs will be selecting a software source and identifying the programming lan-
guages that will be used in creating the system.
The languages used will be critical to the security measures that you will need to
implement. All programming languages have inherent vulnerabilities and possibly have
libraries or functions that are known to be insecure. Investigating these issues is critical
to successfully reducing the attack surface of the system. There are also general steps
that should be taken for any software system. Documenting actions taken for security
and any remaining vulnerabilities is essential to the successful testing and rollout of the
new system.
Objectives
The chapter covers the following topics and concepts:
• Security implications of the architecture mode
• Software sources and trade-off analysis
• Language-related security issues
• Secure coding practice for both procedural and object-oriented languages
• System documentation
Goals
When you complete this chapter, you will be able to:
• Identify security issues in a given architecture.
• Identify vulnerabilities inherent to common programming languages.
209
,9781284239614_Ch09_Pass1.fm Page 210 Friday, October 9, 2015 2:31 PM
210 CHAPTER 9 | Development and Implementation
• Implement secure programming practices.
• Perform variable and data tracking throughout a software system.
• Determine necessary documentation as it relates to security.
NONLINEAR REALITY
Theodor Richardson
Moving from a system map to a developed and implemented system is not a straightforward
task. This is typically the arena in which compromises are made and system expectations and
the reality of what is possible collide. This type of collision can result in project death if the
development team is not part of the planning stage; what may seem trivial in a business
description may be impossible in code or impossible to produce with the expected resources.
Your development team is the best resource for determining if something can be created or
not, whether it will ultimately be developed internally or externally. Salt the whole situation
with the need for security, and the entire thing gets more complex. Fortunately, if you have
followed the advice so far, this step can also be accomplished with some concerted effort
and cooperation across your organization.
The focus of this chapter is on retaining and maintaining the security designed into the
system while the attack surface naturally expands during deployment. Key decisions, such as
the chosen system architecture, the source of the software for the system, and the source of
any impact on the organization should be considered holistically among the developers, sys-
tem planners, project manager, and any affected stakeholders. Maintaining and implement-
ing the established security requirements in development is the focus of the remainder of the
chapter; this will be of primary interest for the development team.
From the security standpoint, if the system has been designed with security as an inherent
consideration, the implementation should continue what has already been established with
minimal burden on the development team. Most of the described security procedures require
careful guarding of variables and system states, which is a best practice in software develop-
ment even without the inclusion of security concerns. The development will be bogged
down by security demands when security is added as an afterthought; it becomes even worse
when security is left entirely to the team that is also responsible for the functionality of the
system. Concentrating on both is difficult at best, given the typical case where the two com-
pete. As a former member of a development team, I will give you a hint: functionality will
always win in the debate if the developer gets to decide.
Your development team should be responsible for making the system happen as specified.
They should be focused on how the system will work and not what the system will do; this
applies to both functionality and security. The developers will do their best work figuring out
the implementation of the functionality and security if the two have always coexisted in the
system plan; they should not be held responsible for establishing the security guidelines of
the system, just for upholding them in implementation. As I have stated many times before,
I loved being a developer and I have a huge respect for development teams, but efficiency
will dictate that the security outcomes that are not explicit will be an afterthought to mak-
ing the system work and delivering it on time.
This is not to say that there will never be difficulties if the security is already planned,
especially when the planned system has to interact with anything that already exists or when
it utilizes an API that has no inherent security. Mitigating these risks is necessary and should
, 9781284239614_Ch09_Pass1.fm Page 211 Friday, October 9, 2015 2:31 PM
9
9.1 Architecture Decision 211
Development and
Implementation
involve communication with the project manager, the developers, and the security expert for
the organization or project. Decisions that affect deployment will affect the business out-
comes as well as the system that is developed. Involvement of key personnel, in addition to
the development team, and open communication across all areas of development and con-
cern, such as the network environment and database environment, are essential for estab-
lishing and maintaining a uniform security level for the system.
9.1 Architecture Decision
The architecture decision is a critical moment for a system, much like the decision for
the project scope. After this decision is made, it is unlikely to be easily revoked and
changed. In the case of internal development, resources are usually purchased after the
trigger is pulled on the final architecture. The architecture of a system involves both the
hardware that will support the system and the software that will perform the system
processes that have been decided in the planning phase of the system. Therefore, archi-
tecture needs to be chosen carefully and decided irrevocably.
There are numerous architecture descriptions that apply to most of the systems in
development today. These may not capture your system exactly, but you should still
find some comparable items to consider in the security of these systems that can trans-
late to your project in particular. If you are new to architecture decisions, these are gen-
erally based on strategic views of the planned system that will determine the needs of the
programming languages, hardware, and communication for the system.
There is no general consensus of what are the necessary elements to an architecture
diagram. However, some of the common diagrams are the structural view, the behav-
ioral view, the physical view, and the data view. The main goal is to determine the
boundary between elements of the system, and all of these diagrams can contribute to
this information. The decision of architecture is systemic, so ensuring that the chosen
architecture satisfies all of the requirements and supports the integrity of the system is
crucial.
If the UML design has been successful to this point, the analysis class diagram can
provide a significant view of the architecture itself. Deciding where to deploy the vari-
ous classes and the integration with any data diagrams is the next view that is needed.
Although UML does not encompass a standard for architecture, its tools and existing
diagrams do allow for the architecture views to be represented easily. The use case
overview diagram is another useful tool in predicting system behavior and asserting that
the architecture will facilitate system completeness. The next element to consider is the
interactivity of the system components and the communication necessary to support the
system processing. The boundary allowing the easiest updating, upgrading, or addition
of features should also be considered.
DEVELOPMENT AND IMPLEMENTATION C HA P T E R
9
.
Development is a critical phase for any software system. This is when the security
requirements are either met or lost. It is also the phase of development in which the
attack surface of the system sees the most growth; this is caused by the increase in the
technology needed for the system to actually implement the requirements established
and perform according to the regulations determined in the planning phase. A decision
needs to be made with regard to the system architecture, the hardware that will be used,
support resources needed, and software solutions implemented. Part of assessing the
software needs will be selecting a software source and identifying the programming lan-
guages that will be used in creating the system.
The languages used will be critical to the security measures that you will need to
implement. All programming languages have inherent vulnerabilities and possibly have
libraries or functions that are known to be insecure. Investigating these issues is critical
to successfully reducing the attack surface of the system. There are also general steps
that should be taken for any software system. Documenting actions taken for security
and any remaining vulnerabilities is essential to the successful testing and rollout of the
new system.
Objectives
The chapter covers the following topics and concepts:
• Security implications of the architecture mode
• Software sources and trade-off analysis
• Language-related security issues
• Secure coding practice for both procedural and object-oriented languages
• System documentation
Goals
When you complete this chapter, you will be able to:
• Identify security issues in a given architecture.
• Identify vulnerabilities inherent to common programming languages.
209
,9781284239614_Ch09_Pass1.fm Page 210 Friday, October 9, 2015 2:31 PM
210 CHAPTER 9 | Development and Implementation
• Implement secure programming practices.
• Perform variable and data tracking throughout a software system.
• Determine necessary documentation as it relates to security.
NONLINEAR REALITY
Theodor Richardson
Moving from a system map to a developed and implemented system is not a straightforward
task. This is typically the arena in which compromises are made and system expectations and
the reality of what is possible collide. This type of collision can result in project death if the
development team is not part of the planning stage; what may seem trivial in a business
description may be impossible in code or impossible to produce with the expected resources.
Your development team is the best resource for determining if something can be created or
not, whether it will ultimately be developed internally or externally. Salt the whole situation
with the need for security, and the entire thing gets more complex. Fortunately, if you have
followed the advice so far, this step can also be accomplished with some concerted effort
and cooperation across your organization.
The focus of this chapter is on retaining and maintaining the security designed into the
system while the attack surface naturally expands during deployment. Key decisions, such as
the chosen system architecture, the source of the software for the system, and the source of
any impact on the organization should be considered holistically among the developers, sys-
tem planners, project manager, and any affected stakeholders. Maintaining and implement-
ing the established security requirements in development is the focus of the remainder of the
chapter; this will be of primary interest for the development team.
From the security standpoint, if the system has been designed with security as an inherent
consideration, the implementation should continue what has already been established with
minimal burden on the development team. Most of the described security procedures require
careful guarding of variables and system states, which is a best practice in software develop-
ment even without the inclusion of security concerns. The development will be bogged
down by security demands when security is added as an afterthought; it becomes even worse
when security is left entirely to the team that is also responsible for the functionality of the
system. Concentrating on both is difficult at best, given the typical case where the two com-
pete. As a former member of a development team, I will give you a hint: functionality will
always win in the debate if the developer gets to decide.
Your development team should be responsible for making the system happen as specified.
They should be focused on how the system will work and not what the system will do; this
applies to both functionality and security. The developers will do their best work figuring out
the implementation of the functionality and security if the two have always coexisted in the
system plan; they should not be held responsible for establishing the security guidelines of
the system, just for upholding them in implementation. As I have stated many times before,
I loved being a developer and I have a huge respect for development teams, but efficiency
will dictate that the security outcomes that are not explicit will be an afterthought to mak-
ing the system work and delivering it on time.
This is not to say that there will never be difficulties if the security is already planned,
especially when the planned system has to interact with anything that already exists or when
it utilizes an API that has no inherent security. Mitigating these risks is necessary and should
, 9781284239614_Ch09_Pass1.fm Page 211 Friday, October 9, 2015 2:31 PM
9
9.1 Architecture Decision 211
Development and
Implementation
involve communication with the project manager, the developers, and the security expert for
the organization or project. Decisions that affect deployment will affect the business out-
comes as well as the system that is developed. Involvement of key personnel, in addition to
the development team, and open communication across all areas of development and con-
cern, such as the network environment and database environment, are essential for estab-
lishing and maintaining a uniform security level for the system.
9.1 Architecture Decision
The architecture decision is a critical moment for a system, much like the decision for
the project scope. After this decision is made, it is unlikely to be easily revoked and
changed. In the case of internal development, resources are usually purchased after the
trigger is pulled on the final architecture. The architecture of a system involves both the
hardware that will support the system and the software that will perform the system
processes that have been decided in the planning phase of the system. Therefore, archi-
tecture needs to be chosen carefully and decided irrevocably.
There are numerous architecture descriptions that apply to most of the systems in
development today. These may not capture your system exactly, but you should still
find some comparable items to consider in the security of these systems that can trans-
late to your project in particular. If you are new to architecture decisions, these are gen-
erally based on strategic views of the planned system that will determine the needs of the
programming languages, hardware, and communication for the system.
There is no general consensus of what are the necessary elements to an architecture
diagram. However, some of the common diagrams are the structural view, the behav-
ioral view, the physical view, and the data view. The main goal is to determine the
boundary between elements of the system, and all of these diagrams can contribute to
this information. The decision of architecture is systemic, so ensuring that the chosen
architecture satisfies all of the requirements and supports the integrity of the system is
crucial.
If the UML design has been successful to this point, the analysis class diagram can
provide a significant view of the architecture itself. Deciding where to deploy the vari-
ous classes and the integration with any data diagrams is the next view that is needed.
Although UML does not encompass a standard for architecture, its tools and existing
diagrams do allow for the architecture views to be represented easily. The use case
overview diagram is another useful tool in predicting system behavior and asserting that
the architecture will facilitate system completeness. The next element to consider is the
interactivity of the system components and the communication necessary to support the
system processing. The boundary allowing the easiest updating, upgrading, or addition
of features should also be considered.
