SESSION-4
SECURE SOFTWARE ENGINEERING
21CS3262R
Topic:
Threats to Software Security &Sources of
Software Security
THREAT AND ITS CATEGORIES
• In information security, the threat—the source of danger—is often a person intending to do harm,
using one or more malicious software agents.
Categories
Threats during development (mainly insider threats).
• A software engineer can sabotage the software at any point in its development life cycle through
intentional exclusions from, inclusions in, or modifications of the requirements specification, the
threat models, the design documents, the source code, the assembly and integration framework,
the test cases and test results, or the installation and configuration instructions and tools.
• The secure development practices described in this book are, in part, designed to help reduce the
exposure of software to insider threats during its development process. For more information on
this aspect, see "Insider Threats in the SDLC" [Cappelli 2006].
CONTD
Threats during operation (both insider and external threats).
• Any software system that runs on a network-connected platform is likely to have its
vulnerabilities exposed to attackers during its operation.
• Attacks may take advantage of publicly known but unpatched vulnerabilities, leading to memory
corruption, execution of arbitrary exploit scripts, remote code execution, and buffer overflows.
Software flaws can be exploited to install spyware, adware, and other malware on users' systems
that can lie dormant until it is triggered to execute
CONTD
• A number of well-known attacks target software that incorporates interfaces, protocols, design
features, or development faults that are well understood and widely publicized as harboring
inherent weaknesses.
• That software includes Web applications (including browser and server components), Web
services, database management systems, and operating systems.
• Misuse (or abuse) cases can help project managers and software engineers see their software from
the perspective of an attacker by anticipating and defining unexpected or abnormal behavior
through which a software feature could be unintentionally misused or intentionally abused
• Today, most project and IT managers responsible for system operation respond to the increasing
number of Internet-based attacks by relying on operational controls at the operating system,
network, and database or Web server levels while failing to directly address the insecurity of the
application-level software that is being compromised.
CRITICAL SHORTCOMINGS
1. The security of the application depends completely on the robustness of operational protections
that surround it.
2. Many of the software-based protection mechanisms (controls) can easily be misconfigured or
misapplied. Also, they are as likely to contain exploitable vulnerabilities as the application
software they are (supposedly) protecting.
• Attackers can study numerous reports of security vulnerabilities in a wide range of commercial
and open-source software programs and access publicly available exploit scripts.
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 transit 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.
Contd
• A large percentage of security weaknesses in software could be avoided if project managers and
software engineers were routinely trained in how to address those weaknesses systematically and
consistently.
• Unfortunately, these personnel are seldom taught how to design and develop secure applications
and conduct quality assurance to test for insecure coding errors and the use of poor development
techniques.
• The absence of this knowledge means that security requirements are likely to be inadequate and
that the resulting software is likely to deviate from specified (and unspecified) security
requirements.
• In addition, this lack of knowledge prevents the manager and engineer from recognizing and
understanding how mistakes can manifest as exploitable weaknesses and vulnerabilities in the
software when it becomes operational.
SOFTWARE WEAKNESS 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).
• Unintended interactions between software components, including those provided by a third party.
Contd
• Flawed specification or design, or defective implementation of:
1. The software's interfaces with external entities. Development mistakes of this type include
inadequate (or nonexistent) input validation, error handling, and exception handling.
2. The components of the software's execution environment (from middleware-level and
operating-system-level to firmware- and hardware-level components).
Contd
• Mistakes are unavoidable.
• Even if they are avoided during requirements engineering and design (e.g., through the use of
formal methods) and development (e.g., through comprehensive code reviews and extensive
testing), vulnerabilities may still be introduced into software during its assembly, integration,
deployment, and operation.
• No matter how faithfully a security-enhanced life cycle is followed, as long as software continues
to grow in size and complexity, some number of exploitable faults and other weaknesses are sure
to exist.
