Secure Software Engineering

Module I:
Security Issues in Software Development

Dr G.VENKATESWARA Rao
Professor
Dept. of CSE
GIT,GITAM University
Introduction to Software Engineering
• Software is a program or set of programs containing instructions that provide desired
functionality. And Engineering is the process of designing and building something
that serves a particular purpose and finds a cost-effective solution to problems.
• Software Engineering is mainly used for large projects based on software systems
rather than single programs or applications. The main goal of software Engineering is
to develop software application for improving the quality, budget and time efficiency.
Software Engineering ensures that the software that has to built should be
consistent, correct, also on budget, on time and within the required requirements.
There are Four main Attributes of Software Engineering:-
• Efficiency
• Reliability
• Robustness
• Maintainability
Dual Role of Software:
1. As a product –

• It delivers the computing potential across networks of

Hardware.
• It enables the Hardware to deliver the expected functionality.
• It acts as an information transformer because it produces,
manages, acquires, modifies, displays, or transmits information.
2. As a vehicle for delivering a product –

• It provides system functionality (e.g., payroll system)

• It controls other software (e.g., an operating system)
• It helps build other software (e.g., software tools)
 SDLC
• Software Development Life Cycle (SDLC) is a process used by the
software industry to design, develop and test high quality softwares. The
SDLC aims to produce a high-quality software that meets or exceeds
customer expectations, reaches completion within times and cost
estimates.
• SDLC is the acronym of Software Development Life Cycle.
• It is also called as Software Development Process.
• SDLC is a framework defining tasks performed at each step in the
software development process.
• ISO/IEC 12207 is an international standard for software life-cycle
processes. It aims to be the standard that defines all the tasks required
for developing and maintaining software.
What is SDLC?

• SDLC is a process followed for a software project, within a software

organization. It consists of a detailed plan describing how to develop,
maintain, replace and alter or enhance specific software. The life cycle
defines a methodology for improving the quality of software and the
overall development process.
• The following figure is a graphical representation of the various stages
of a typical SDLC.
SDLC
Stage 1: Planning and Requirement Analysis
• Requirement analysis is the most important and fundamental stage in
SDLC. It is performed by the senior members of the team with inputs
from the customer, the sales department, market surveys and domain
experts in the industry. This information is then used to plan the basic
project approach and to conduct product feasibility study in the
economical, operational and technical areas.
• Planning for the quality assurance requirements and identification of
the risks associated with the project is also done in the planning stage.
The outcome of the technical feasibility study is to define the various
technical approaches that can be followed to implement the project
successfully with minimum risks.
Stage 2: Defining Requirements
• Once the requirement analysis is done the next step is to clearly define
and document the product requirements and get them approved from
the customer or the market analysts. This is done through an SRS
(Software Requirement Specification) document which consists of
all the product requirements to be designed and developed during the
project life cycle.
Stage 3: Designing the Product Architecture
• SRS is the reference for product architects to come out with the best
architecture for the product to be developed. Based on the requirements
specified in SRS, usually more than one design approach for the product
architecture is proposed and documented in a DDS - Design Document
Specification.
• This DDS is reviewed by all the important stakeholders and based on
various parameters as risk assessment, product robustness, design
modularity, budget and time constraints, the best design approach is
selected for the product.
• A design approach clearly defines all the architectural modules of the
product along with its communication and data flow representation with
the external and third party modules (if any). The internal design of all the
modules of the proposed architecture should be clearly defined with the
minutest of the details in DDS.
Stage 4: product coding and Building software.
• SRS is the reference for product architects to come out with the best
architecture for the product to be developed. Based on the requirements
specified in SRS, usually more than one design approach for the product
architecture is proposed and documented in a DDS - Design Document
Specification.
• This DDS is reviewed by all the important stakeholders and based on
various parameters as risk assessment, product robustness, design
modularity, budget and time constraints, the best design approach is
selected for the product.
• A design approach clearly defines all the architectural modules of the
product along with its communication and data flow representation with
the external and third party modules (if any). The internal design of all the
modules of the proposed architecture should be clearly defined with the
minutest of the details in DDS.
Stage 5: Testing the Product
• This stage is usually a subset of all the stages as in the modern SDLC
models, the testing activities are mostly involved in all the stages of
SDLC. However, this stage refers to the testing only stage of the
product where product defects are reported, tracked, fixed and
retested, until the product reaches the quality standards defined in the
SRS.
Stage 6: Deployment in the Market and Maintenance
• Once the product is tested and ready to be deployed it is released
formally in the appropriate market. Sometimes product deployment
happens in stages as per the business strategy of that organization. The
product may first be released in a limited segment and tested in the
real business environment (UAT- User acceptance testing).
• Then based on the feedback, the product may be released as it is or
with suggested enhancements in the targeting market segment. After
the product is released in the market, its maintenance is done for the
existing customer base.
 SDLC Models
There are various software development life cycle models defined and
designed which are followed during the software development process.
These models are also referred as Software Development Process Models".
Each process model follows a Series of steps unique to its type to ensure
success in the process of software development.
Following are the most important and popular SDLC models followed in the
industry −
• Waterfall Model
• Iterative Model
• Spiral Model
• V-Model
• Big Bang Model
Software Assurance and Software Security

• The increasing dependence on software to get critical jobs done means

that software's value no longer lies solely in its ability to enhance or
sustain productivity and efficiency. Instead, its value also derives from
its ability to continue operating dependably even in the face of events
that threaten it. The ability to trust that software will remain
dependable under all circumstances, with a justified level of
confidence, is the objective of software assurance.
Software assurance has become critical because dramatic increases in business and
mission risks are now known to be attributable to exploitable software [DHS
2003]. The growing extent of the resulting risk exposure is rarely understood, as
evidenced by these facts:
• Software is the weakest link in the successful execution of interdependent
systems and software applications.
• Software size and complexity obscure intent and preclude exhaustive testing.
• Outsourcing and the use of unvetted software supply-chain components increase
risk exposure.
• The sophistication and increasingly more stealthy nature of attacks facilitates
exploitation.
• Reuse of legacy software with other applications introduces unintended
consequences, increasing the number of vulnerable targets.
• Business leaders are unwilling to make risk-appropriate investments in software
security.
The objective of software security is to field software-based systems that
satisfy the following criteria:
• The system is as vulnerability and defect free as possible.
• The system limits the damage resulting from any failures caused by attack-
triggered faults, ensuring that the effects of any attack are not propagated, and
it recovers as quickly as possible from those failures.
• The system continues operating correctly in the presence of most attacks by
either resisting the exploitation of weaknesses in the software by the attacker
or tolerating the failures that result from such exploits.
Software that has been developed with security in mind generally reflects
the following properties throughout its development life cycle:
• Predictable execution. There is justifiable confidence that the software,
when executed, functions as intended. The ability of malicious input to
alter the execution or outcome in a way favorable to the attacker is
significantly reduced or eliminated.
• Trustworthiness. The number of exploitable vulnerabilities is
intentionally minimized to the greatest extent possible. The goal is no
exploitable vulnerabilities.
• Conformance. Planned, systematic, and multidisciplinary activities
ensure that software components, products, and systems conform to
requirements and applicable standards and procedures for specified uses.
The Role of Processes and Practices in Software Security

• A number of factors influence how likely software is to be secure. For

instance, software vulnerabilities can originate in the processes and
practices used in its creation. These sources include the decisions made by
software engineers, the flaws they introduce in specification and design, and
the faults and other defects they include in developed code, inadvertently or
intentionally. Other factors may include the choice of programming
languages and development tools used to develop the software, and the
configuration and behavior of software components in their development
and operational environments. It is increasingly observed, however, that the
most critical difference between secure software and insecure software lies
in the nature of the processes and practices used to specify, design, and
develop the software
Software Threats

• Software threats are malicious pieces of computer code and

applications that can damage your computer, as well as steal
your personal or financial information. For this reason, these
dangerous programs are often called malware (short
for “malicious software”).
• Many software threats now target smartphones specifically, so approaches to
cybersecurity that are based on desktop computers are not always effective. While
viruses that target smartphones are simply the mobile versions of ones that target your
desktop or laptop computer, man-in-the-middle attacks take advantage of free Wi-Fi in
order to place hackers between your device and a Wi-Fi hotspot and steal your
information and details from your apps.
• Bluejacking is the sending of unwanted or unsolicited messages to strangers
via Bluetooth technology. It can be a serious problem if obscene or threatening
messages and images are sent.
• Bluesnarfing is the actual theft of data from Bluetooth enabled devices (including both
mobile phones and laptops): contact lists, phonebooks, images and other data may be
stolen in this way.
• Mobile Ransomware is malware that locks up your device.If your device has been
infected with the malware, you lose all access to every part of your phone until you pay
a ransom to the hacker/criminal who has taken control over your device.
• Phishing or Smishing usually starts as an email or text claiming to be from a person
or business that you know. This email usually contains a link that asks you to verify
information. This information in turn goes straight to the scammer to steal and use your
details
Sources of Software Insecurity

• Most commercial and open-source applications, middleware systems,

and operating systems are extremely large and complex. In normal
execution, these systems can transition through a vast number of
different states. These characteristics make it particularly difficult to
develop and operate software that is consistently correct, let alone
consistently secure. The unavoidable presence of security threats and
risks means that project managers and software engineers need to pay
attention to software security even if explicit requirements for it have
not been captured in the software's specification.
• Software—especially networked, application-level software—is most
often compromised by exploiting weaknesses that result from the
following sources:
• Complexities, inadequacies, and/or changes in the software's
processing model (e.g., a Web- or service-oriented architecture
model).
• Incorrect assumptions by the engineer, including assumptions about
the capabilities, outputs, and behavioral states of the software's
execution environment or about expected inputs from external entities
(users, software processes).
The Benefits of Early Defect Detection
in Software Development
• Reduces Fix and Remediation Cost.
• Reduces Overall ADM Spend.
• Increased Developer and QA Staff Productivity.
• Reduces Business Risk Due to Outages.
• Improves Application Security and Overall Code
Quality.
• Limited data is available that discusses the return on investment (ROI)
of reducing security flaws in source code (refer to Section 1.6.1 for
more on this subject). Nevertheless, a number of studies have shown
that significant cost benefits are realized through improvements to
reduce software defects (including security flaws) throughout the
SDLC [Goldenson 2003]. The general software quality case is made in
this section, including reasonable arguments for extending this case to
include software security defects.
• Proactively tackling software security is often under-budgeted and
dismissed as a luxury. In an attempt to shorten development schedules
or decrease costs, software project managers often reduce the time
spent on secure software practices during requirements analysis and
design. In addition, they often try to compress the testing schedule or
reduce the level of effort. Skimping on software quality 6 is one of the
worst decisions an organization that wants to maximize development
speed can make; higher quality (in the form of lower defect rates) and
reduced development time go hand in hand. Figure 1-3 illustrates the
relationship between defect rate and development time.
Figure 1-3 Relationship between defect rate and development time
Managing Secure Software Development

• Which Security Strategy Questions Should I Ask?

• A Risk Management Framework for Software Security
• Software Security Practices in the Development Life Cycle
Which Security Strategy Questions Should I Ask?

• Achieving an adequate level of software security means more than

complying with regulations or implementing commonly accepted best
practices. You and your organization must determine your own
definition of "adequate." The range of actions you must take to reduce
software security risk to an acceptable level depends on what the
product, service, or system you are building needs to protect and what
it needs to prevent and manage.
Consider the following questions from an enterprise perspective. Answers to
these questions aid in understanding security risks to achieving project goals
and objectives.
• What is the value we must protect?
• To sustain this value, which assets must be protected? Why must they be
protected? What happens if they're not protected?
• What potential adverse conditions and consequences must be prevented and
managed? At what cost? How much disruption can we stand before we take
action?
• How do we determine and effectively manage residual risk (the risk
remaining after mitigation actions are taken)?
• How do we integrate our answers to these questions into an effective,
implementable, enforceable security strategy and plan?
A Risk Management Framework for Software Security

• A necessary part of any approach to ensuring adequate software security is

the definition and use of a continuous risk management process. Software
security risk includes risks found in the outputs and results produced by each
life-cycle phase during assurance activities, risks introduced by insufficient
processes, and personnel-related risks. The risk management framework
(RMF) introduced here and expanded in Chapter 7 can be used to implement
a high-level, consistent, iterative risk analysis that is deeply integrated
throughout the SDLC.
• Figure 1-5 shows the RMF as a closed-loop process with five activity stages.
Throughout the application of the RMF, measurement and reporting activities
occur. These activities focus on tracking, displaying, and understanding
progress regarding software risk.
Figure 1-5 A software security risk management framework
Software Security Practices in the Development Life Cycle

• Managers and software engineers should treat all software faults and
weaknesses as potentially exploitable. Reducing exploitable
weaknesses begins with the specification of software security
requirements, along with considering requirements that may have been
overlooked. Software that includes security requirements (such as
security constraints on process behaviors and the handling of inputs,
and resistance to and tolerance of intentional failures) is more likely to
be engineered to remain dependable and secure in the face of an
attack. In addition, exercising misuse/abuse cases that anticipate
abnormal and unexpected behavior can aid in gaining a better
understanding of how to create secure and reliable software
Figure 1-6 Software development life cycle with defined security touchpoints
Defining Properties of Secure Software
• Before we can determine the security characteristics of software and
look for ways to effectively measure and improve them, we must first
define the properties by which these characteristics can be described.
These properties consist of (1) a set of core properties whose
presence (or absence) are the ground truth that makes software
secure (or not) and (2) a set of influential properties that do not
directly make software secure but do make it possible to characterize
how secure software is.
Core Properties of Secure Software
• Confidentiality. The software must ensure that any of its characteristics (including its
relationships with its execution environment and its users), its managed assets,
and/or its content are obscured or hidden from unauthorized entities. This remains
appropriate for cases such as open-source software; its characteristics and content
are available to the public (authorized entities in this case), yet it still must maintain
confidentiality of its managed assets.
• Integrity. The software and its managed assets must be resistant and resilient to
subversion. Subversion is achieved through unauthorized modifications to the
software code, managed assets, configuration, or behavior by authorized entities, or
any modifications by unauthorized entities. Such modifications may include
overwriting, corruption, tampering, destruction, insertion of unintended (including
malicious) logic, or deletion. Integrity must be preserved both during the software’s
development and during its execution.
• Availability. The software must be operational and accessible to its intended,
authorized users (humans and processes) whenever it is needed. At the same time,
its functionality and privileges must be inaccessible to unauthorized users (humans
and processes) at all times.
Two additional properties commonly associated with human users are
required in software entities that act as users (e.g., proxy agents, Web
services, peer processes):
• Accountability. All security-relevant actions of the software-as-user
must be recorded and tracked, with attribution of responsibility. This
tracking must be possible both while and after the recorded actions
occur. The audit-related language in the security policy for the
software system should indicate which actions are considered
“security relevant.”
• Non-repudiation. This property pertains to the ability to prevent the
software-as-user from disproving or denying responsibility for actions
it has performed. It ensures that the accountability property cannot
be subverted or circumvented.
 Influential Properties of Secure Software
• Some properties of software, although they do not directly make
software secure, nevertheless make it possible to characterize how
secure software is
• These influential properties are further influenced by the size, complexity,
and traceability of the software. Much of the activity of software security
engineering focuses on addressing these properties and thus targets the
core
Dependability and Security
• In simplest terms, dependability is the property of software that ensures
that the software always operates as intended. It is not surprising that
security as a property of software and dependability as a property of
software share a number of subordinate properties (or attributes). The
most obvious, to security practitioners, are availability and integrity. in
“Basic Concepts and Taxonomy of Dependable and Secure Computing,” a
number of other properties are shared by dependability and security,
including reliability, safety, survivability, maintainability, and fault tolerance
security properties themselves.
Correctness and Security
• From the standpoint of quality, correctness is a critical attribute of
software that should be consistently demonstrated under all
anticipated operating conditions. Security requires that the attribute
of correctness be maintained under unanticipated conditions as well.
One of the mechanisms most commonly used to attack the security of
software seeks to cause the software’s correctness to be violated by
forcing it into unanticipated operating conditions, often through
unexpected input or exploitation of environmental assumptions.
“Small” Faults, Big Consequences
• There is a conventional wisdom espoused by many software
engineers that says vulnerabilities which fall within a specified range
of speculated impact (“size”) can be tolerated and allowed to remain
in the software. This belief is based on the underlying assumption that
small faults have small consequences. In terms of defects with
security implications, however, this conventional wisdom is wrong.
Nancy Leveson suggests that vulnerabilities in large softwareintensive
systems with significant human interaction will increasingly result
from multiple minor defects, each insignificant by itself, thereby
collectively placing the system into a vulnerable state
Predictability and Security
• Predictability means that the software’s functionality, properties, and behaviors
will always be what they are expected to be as long as the conditions under which
the software operates (i.e., its environment, the inputs it receives) are also
predictable. For dependable software, this means the software will never deviate
from correct operation under anticipated conditions. Software security extends
predictability to the software’s operation under unanticipated conditions—
specifically, under conditions in which attackers attempt to exploit faults in the
software or its environment. In such circumstances, it is important to have
confidence in precisely how the software will behave when faced with misuse or
attack. The best way to ensure predictability of software under unanticipated
conditions is to minimize the presence of vulnerabilities and other weaknesses, to
prevent the insertion of malicious logic, and to isolate the software to the
greatest extent possible from unanticipated environmental conditions.
Reliability, Safety, and Security
• The focus of reliability for software is on preserving predictable, correct
execution despite the presence of unintentional defects and other
weaknesses and unpredictable environment state changes. Software
that is highly reliable is often referred to as high-confidence software
(implying that a high level of assurance of that reliability exists) or fault-
tolerant software (implying that fault tolerance techniques were used to
achieve the high level of reliability). Software safety depends on
reliability and typically has very real and significant implications if the
property is not met. The consequences, if reliability is not preserved in a
safety-critical system, can be catastrophic: Human life may be lost, or the
sustainability of the environment may be compromised.
Size, Complexity, Traceability, and Security
• Software that satisfies its requirements through simple functions that are
implemented in the smallest amount of code that is practical, with process
flows and data flows that are easily followed, will be easier to comprehend and
maintain. The fewer the dependencies in the software, the easier it will be to
implement effective failure detection and to reduce the attack surface. Size and
complexity should be not only properties of the software’s implementation, but
also properties of its design, as they will make it easier for reviewers to discover
design flaws that could be manifested as exploitable weaknesses in the
implementation. Traceability will enable the same reviewers to ensure that the
design satisfies the specified security requirements and that the
implementation does not deviate from the secure design. Moreover,
traceability provides a firm basis on which to define security test cases.
How to Influence the Security Properties of
Software
• Once you understand the properties that determine the security of software,
the challenge becomes acting effectively to influence those properties in a
positive way. The ability of a software development team to manipulate the
security properties of software resolves to a balance between engaging in
defensive action and thinking like an attacker. The primary perspective is that of
a defender, where the team works to build into the software appropriate
security features and characteristics to make the software more resistant to
attack and to minimize the inherent weaknesses in the software that may make
it more vulnerable to attack. The balancing perspective is that of the attacker,
where the team strives to understand the exact nature of the threat that the
software is likely to face so as to focus defensive efforts on areas of highest risk.
These two perspectives, working in combination, guide the actions taken to
make software more secure.
 The Defensive Perspective
• Assuming the defensive perspective involves looking at the software from the
inside out. It requires analyzing the software for vulnerabilities and
opportunities for the security of the software to be compromised through
inadvertent misuse and, more importantly, through malicious attack and
abuse. Doing so requires the software development team to perform the
following steps:
1. Address expected issues through the application of appropriate security
architecture and features
2. Address unexpected issues through the avoidance, removal, and mitigation of
weaknesses that could lead to security vulnerabilities
3. Continually strive to improve and strengthen the attack resistance, tolerance,
and resilience of the software in everything they do
Addressing the Expected: Security
Architecture and Features
• When most people think of making software secure, they think in
terms of the architecture and functionality of security features.
Security features and functionality alone are insufficient to ensure
software security, but they are a necessary facet to consider., security
features aim to address expected security issues with software such
as authentication, authorization, access control, permissions,
privileges, and cryptography. Security architecture is the overall
framework that holds these security functionalities together and
provides the set of interfaces that integrates them with the broader
software architecture.
Addressing the Unexpected: Avoiding,
Removing, and Mitigating Weaknesses
• Many activities and practices are available across the life cycle of
software systems that can help reduce and mitigate weaknesses
present in software. These activities and practices can typically be
categorized into two approaches: application defense and software
security.
Application Defense

• Employing practices focused at detecting and mitigating weaknesses in

software systems after they are deployed is often referred to as application
defense which in many cases is mislabeled as application security. Application
defense techniques typically focus on the following issues:
• Establishing a protective boundary around the application that enforces rules
defining valid input or recognizes and either blocks or filters input that
contains recognized patterns of attack  Constraining the extent and impact of
damage that might result from the exploit of a vulnerability in the application
• Discovering points of vulnerability in the implemented application through
black-box testing so as to help developers and administrators identify
necessary countermeasures
Software Security
While application defense takes a somewhat after-the-fact
approach, practices associated with “software security”
and its role in secure software engineering processes focus
on preventing weaknesses from entering the software in
the first place or, if that is unavoidable, at least removing
them as early in the life cycle as possible and before the
software is deployed (see Figure 2–5). These weaknesses,
whether unintentional or maliciously inserted, can enter
the software at any point in the development process
through inadequate or incorrect requirements;
ambiguous, incomplete, unstable, or improper
architecture and design; implementation errors;
incomplete or inappropriate testing; or insecure
configuration and deployment decisions.
How to Assert and Specify Desired Security
Properties
• Identifying and describing the properties that determine the security profile of
software gave us the common language and objectives for building secure
software. Outlining mechanisms for how these properties can be influenced
gave us the ability to take action and effect positive change in regard to the
security assurance of the software we build. Taken in combination, these
achievements lay a foundation for understanding what makes software secure.
Unfortunately, without a mechanism for clearly communicating the desired or
attained security assurance of software in terms of these properties and
activities, this understanding is incomplete. What is needed is a mechanism for
asserting and specifying desired security properties and using them as a basis
for planning, communicating, and assuring compliance. These assertions and
specifications are typically captured and managed in an artifact known as an
assurance case
Building a Security Assurance Case
• A security assurance case uses a structured set of arguments and a
corresponding body of evidence to demonstrate that a system satisfies specific
claims with respect to its security properties. This case should be amenable to
review by a wide variety of stakeholders. Although tool support is available for
development of these cases, the creation and documentation of a security
assurance case can be a demanding and time-consuming process. Even so,
similarities may exist among security cases in the structure and other
characteristics of the claims, arguments, and evidence used to construct them.
A catalog of patterns (templates) for security assurance cases can facilitate the
process of creating and documenting an individual case. Moreover, assurance
case patterns offer the benefits of reuse and repeatability of process, as well
as providing some notion of coverage or completeness of the evidence.
A Security Assurance Case Example
• The structure for a partially developed security assurance case
focusing on buffer overflow coding defects appears in Figure 2–7. This
case is presented in a graphical notation called Goal Structuring
Notation (GSN)
Incorporating Assurance Cases into the SDLC
• Developing a security assurance case is not a trivial matter. In any real system,
the number of claims involved and the amount of evidence required will be
significant. The effort involved is offset by an expected decrease in effort
required to find and fix security-related problems at the back end of product
development and by a reduced level of security breaches and their attendant
costs. Creating and evolving the security case as the system is being developed
is highly recommended. Developing even the preliminary outlines of an
assurance case as early as possible in the SDLC can improve the development
process by focusing attention on what needs to be assured and which evidence
needs to be developed at each subsequent stage of the SDLC. Attempting to
gather or generate the necessary security case evidence once development is
complete may be not just much more costly, but simply impossible.
Related Security Assurance and Compliance
Efforts
• Security-Privacy Laws and Regulations
• Laws and regulations such as Sarbanes–Oxley and HIPAA mandate specific
security and privacy requirements. Security assurance cases can be used to
argue that a corporation is in compliance with a given law or regulation. One
can envision the development of security case patterns for particular laws or
regulations to assist in demonstrating such compliance.
Maintaining and Benefitting from Assurance
Cases
• Assurance cases for security provide a structured and reviewable set
of artifacts that make it possible to demonstrate to interested parties
that the system’s security requirements have been met to a
reasonable degree of certainty. Moreover, the creation of an
assurance case can help in the planning and conduct of development.
The process of maintaining an assurance case can help developers
identify new security issues that may arise when changes are made to
the system. Developing and maintaining security cases throughout
the SDLC is an emerging area of best practice for systems with critical
security requirements.