Assignment: 1

1. What are common sources of software insecurity?

Soln:

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).
● Flawed specification or design, or defective implementation of
○ The software’s interfaces with external entities. Development
mistakes of this type include inadequate (or nonexistent) input
validation, error handling, and exception handling.
○ The components of the software’s execution environment (from
middleware-level and operating-system-level to firmware- and
hardware-level components).
● Unintended interactions between software components, including those
provided by a third party.

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.
2. Define software assurance and its role in software security.

Soln:

Software Assurance is defined as "the level of confidence that software is free

from vulnerabilities, either intentionally designed into the software or accidentally
inserted at any time during its life cycle, and that the software functions in the
intended manner."

Roles of software assurance in software security:

1. Early Identification of Vulnerabilities: Software assurance involves

security analysis and secure engineering practices that help identify
potential vulnerabilities early in the software development lifecycle,
especially during the design phase.
2. Reduction of Exploitable Faults: By adopting security-enhanced
development processes, software assurance aims to reduce the number of
exploitable faults and weaknesses in the software.
3. Cost-Effective Security Measures: Introducing security practices early in
development is more cost-effective than addressing security issues
post-release. It leads to fewer defects, reducing the labor and costs
associated with fixing these issues later.
4. Continuous Improvement of Security Practices: As security-enhanced
practices become more established and refined, they help decrease the
likelihood of vulnerabilities being introduced into the software in the first
place.
5. Preventive Approach Over Reactive Measures: Software assurance
promotes a preventive approach, emphasizing the importance of correcting
vulnerabilities as early as possible, rather than relying on frequent patches
after the software is released.
 6. Return on Investment (ROI): The implementation of secure engineering
practices early in the development cycle has been shown to provide a
significant return on investment, particularly when security analysis is
performed during the application design phase.
7. Enhanced Software Quality: Through systematic processes and practices,
software assurance contributes to the overall quality of the software,
ensuring it meets security standards and is less prone to attacks.
8. Informed Decision-Making: It guides software engineers in making informed
decisions during the specification, design, and development phases, thereby
minimizing the introduction of security flaws.

3. List the benefits of detecting software security defects early in the SDLC.

Soln:

Detecting software security defects early in the Software Development Life Cycle
(SDLC) offers several benefits:

1. Significant Cost Reduction: Defects detected during the requirements or

design phases are much cheaper to fix compared to those found after
deployment. For example, correcting a defect during the design phase might
cost $1, but the same defect could cost $60 to $100 to fix after the
application has been released. This cost difference highlights the economic
importance of early detection.
2. Optimized Development Schedules: Projects that manage to remove at least
95% of defects before release achieve the shortest and most efficient
development schedules. As shown in the "95% defect removal" example,
organizations that succeed in reaching this threshold avoid the delays and
extended schedules that come with high defect rates. Conversely, projects
that fail to detect defects early are often plagued by longer schedules and
higher costs due to the increased time needed for post-release fixes.
 3. Prevention of Error-Prone Modules: Modules that account for a
disproportionate number of defects (e.g., 20% of modules causing 80% of
errors) are more costly and time-consuming to develop. IBM's IMS project,
for example, found that 57% of errors occurred in just 7% of modules. By
identifying and redesigning these error-prone modules early, organizations
can avoid the complexities and high costs associated with them later in the
development cycle.
4. Higher Quality and Reliability: Early detection of defects leads to a
higher-quality product with fewer vulnerabilities, bugs, and security flaws.
Projects with lower defect rates not only have shorter schedules but also
result in software that is more secure and reliable from the outset, reducing
the need for frequent patches and updates post-release.
5. Improved Return on Investment (ROI): Studies have shown that the ROI
for early defect detection and correction ranges from 12% to 21%, with the
highest returns occurring when security analysis is performed during the
design phase. This ROI is driven by the reduced need for costly rework and
the delivery of more secure and stable software products.
6. Avoiding Schedule Overruns and Cancellations: Poor quality due to high
defect rates is a leading cause of schedule overruns and even project
cancellations. Capers Jones reported that poor quality was a significant
factor in approximately 50% of all canceled projects. By focusing on early
defect detection, organizations can avoid the pitfalls that lead to these
costly outcomes.

4. Identify the primary problem with software security.

Soln:

Primary Problem with Software Security:

The primary problem with software security arises from the increased exposure of
sensitive information due to the widespread use of software-intensive systems
connected to the Internet. These systems are often not sufficiently resilient
against attacks, leading to vulnerabilities that can be exploited by malicious
entities, such as cybercriminals and terrorists. The lack of rigorous and controlled
software development practices further exacerbates these vulnerabilities, making
software security a critical issue as more personal and organizational activities
depend on these systems.

System Complexity: The Context within Which Software Lives

1. Decentralized Control: In contrast to the past when large, stand-alone

systems had centralized control, modern systems now involve multiple, often
independent control points. Project managers must account for these
dispersed control mechanisms, especially in systems of systems, which
complicates the management of security.
2. Reduced Capability for Wide-Scale Changes: The increased integration
among various systems has diminished the ability to implement broad
changes quickly. Independently managed systems often do not synchronize
upgrades, which forces project managers to ensure operational capabilities
and maintain security as services are updated and new features are added.
3. Heterogeneous Environments: Project managers now deal with a diverse
array of components and systems, each potentially having different
implementations of common interfaces and varying security policies. This
diversity introduces inconsistencies that make security management more
challenging.
4. Increased Likelihood of Failures: The mismatches and errors that arise
from the integration of independently developed and managed systems mean
that failures are more likely. These failures complicate efforts to meet
security requirements, making it harder to ensure the overall security of the
system.
5. Explain why security is considered a software issue.

Soln:

Security is considered a software issue because software is deeply integrated into

every aspect of modern life, from essential services like banking and utilities to
communication and transportation. As software controls these critical systems, any
vulnerabilities within it pose significant risks. If software is developed without
considering security, it can lead to severe consequences, much like walking a high
wire without a safety net. The interconnected nature of software systems and
their reliance on the Internet for communication makes them particularly
susceptible to attacks and failures, underscoring the importance of integrating
security into the software development process.

6. Describe the relationship between defect rates and development time.

Soln:

The relationship between defect rates and development time is critical in software
development, where projects that achieve higher defect removal rates before
release tend to have shorter and more efficient schedules. Specifically, studies
have shown that projects reaching the "95 percent defect removal" threshold tend
to hit the optimal balance between speed and quality. For instance, Capers Jones
reported that poor quality was a significant factor in approximately 50 percent of
all cancelled projects, highlighting how defect rates directly impact the project's
timeline.

An example of this relationship is IBM’s IMS project, where 57 percent of errors

were traced to just 7 percent of the modules. These "error-prone" modules, which
were often more complex and developed under schedule pressure, took
significantly longer to deliver and were more costly—around $2,000 to $4,000 per
function point compared to $500 to $1,000 for less error-prone modules. The
presence of these modules can dramatically extend development time, illustrating
the importance of early defect detection and prevention.

Moreover, reworking defects during later stages of development, such as after the
software is operational, can be 50 to 200 times more expensive than addressing
them during the requirements phase. This exponential increase in cost is due to the
expanding complexity as the project progresses, making early defect management
essential for maintaining both cost efficiency and development speed .

7. Summarize the impact of compressing the testing schedule on software security.

Soln:

Compressing the testing schedule in software development has a detrimental

impact on software security. When testing is rushed or minimized to meet
deadlines, critical security flaws are often missed, leading to a higher likelihood of
vulnerabilities in the final product. The text emphasizes that cutting corners in the
testing phase results in higher defect rates, which in turn makes the software
more susceptible to attacks. This not only compromises the security of the
software but also leads to longer development times and increased costs, as these
security issues typically need to be addressed later in the development cycle or
after release. “Skimping on software quality is one of the worst decisions,"
highlights that inadequate testing due to compressed schedules undermines both
the quality and security of the software. This can ultimately result in significant
risks, including system breaches, data loss, and costly post-release fixes.

8. Illustrate the significance of the “95 percent defect removal” line.

Soln:

The "95 percent defect removal" line is significant for several technical and
practical reasons in software development:

1. It represents the optimal point for development efficiency, where projects

achieve the shortest schedules with the least effort and highest user
satisfaction.
2. It serves as a quality threshold. Products with less than 95% defect removal
before release are vulnerable to low quality issues and longer development
times.
3. Reaching 95% defect removal reduces long-term costs. Every hour spent on
defect prevention can save three to ten hours of repair time for a system in
production.
4. Projects achieving 95% or higher defect removal rates typically have
shorter schedules, demonstrating a direct link between quality and
development speed.
5. The 95% mark serves as an industry benchmark, with most organizations
operating around this point according to the graph.
6. It highlights the importance of thorough defect removal, especially
considering that 20% of program modules are typically responsible for 80%
of errors, as reported by Barry Boehm.
7. The 95% line emphasizes the cost escalation of late-stage defect removal.
Reworking a software requirements problem in operation can cost 50 to 200
times more than addressing it during the requirements phase.
8. It underscores the economic impact of defect-prone modules. Normal
modules cost $500 to $1000 per function point to develop, while error-prone
modules cost $2000 to $4000 per function point.
These factors illustrate why the 95% defect removal line is a critical benchmark in
software development, balancing quality, cost, and development speed.

9. Apply the concept of early defect detection to explain its cost-saving potential.

Soln:

Early defect detection offers significant cost-saving potential in software

development:

1. Defect prevalence: Approximately 60% of all defects typically exist by

design time [Gilb 1988]. Detecting these early prevents costly fixes later.
2. Cost escalation: Resolving an issue during the design phase costs $1, while
the same issue costs $60 to $100 to fix after application deployment [Soo
 Hoo 2001]. This exponential cost increase is visually represented in Figure
1-4, showing how correction costs rise sharply across development phases.
3. Resource allocation: Early detection prevents scenarios where engineers
spend more time correcting defects than they spent on initial development.
4. Schedule optimization: Addressing security throughout the SDLC, especially
in early phases, leads to shorter schedules and higher-quality products.
5. Lifecycle impact: Figure 1-4 illustrates how defects introduced in early
phases (e.g., Requirements Engineering) become increasingly expensive to
correct in later phases (e.g., Deployment and Operations).

By prioritizing early defect detection, project managers can significantly reduce

overall development costs and time while improving software security and quality.

For example, if security flaws or bugs are identified and corrected later in the
development process, they can lead to increased maintenance efforts and costs
that may exceed the original development budget. Therefore, addressing defects
early in the software development lifecycle (SDLC) not only reduces the cost per
defect but also contributes to a shorter development schedule and a higher-quality
product overall.

10. How would you integrate security practices into the SDLC to enhance software
Security?

Soln:

To integrate security practices into the SDLC and enhance software security:

1. Start early: Specify software security requirements from the beginning,

including security constraints on process behaviors, input handling, and
resistance to intentional failures (Chapter 3).
2. Use misuse/abuse cases: Anticipate abnormal and unexpected behavior to
better understand how to create secure and reliable software (Section 3.2).
3. Prioritize security-by-design: Developing with security in mind is more
effective than post-development validation. For example, design input
validation routines to check every input against predefined constraints.
4. Apply analysis and modeling: Use these techniques to protect against subtle,
complex attack patterns and strengthen interfaces with external entities.
5. Implement touchpoints: Figure 1-6 illustrates security touchpoints applied
throughout the SDLC:
○ Requirements phase: Security requirements, abuse cases
○ Architecture and design: Risk analysis, external review
○ Implementation: Code review (using tools)
○ Testing: Risk-based security tests, penetration testing
○ Deployment: Security operations

6. Use risk assessment: If resources are constrained, prioritize security

practices for high-risk components based on business-driven risk assessment
(Section 7.4.2).
7. Continuous security: Perform ongoing code reviews, security tests, strict
configuration control, and quality assurance during deployment and
operations.
8. Process neutrality: The touchpoint approach (Figure 1-6) can be applied to
various development processes like waterfall, agile, spiral, or CMMI.
This approach ensures security is integrated throughout the entire SDLC, from
requirements to deployment and operations.

11. Demonstrate how a risk management framework can be used to manage

software security risks.

Soln:

The risk management framework (RMF) for managing software security risks, as
shown in Figure 1-5, is a closed-loop process with five key stages:

1. Understand the Business Context: This initial stage involves assessing the
value to protect, identifying critical assets, and determining potential
adverse conditions and consequences.
2. Identify and Link the Business and Technical Risks: This stage includes
artifact analysis within the business context to identify specific risks.
 3. Synthesize and Rank the Risks: Risks are prioritized based on their potential
impact and likelihood.
4. Define the Risk Mitigation Strategy: Based on the ranked risks, appropriate
mitigation strategies are developed.
5. Carry Out Fixes and Validate: Implement the mitigation strategies and
validate their effectiveness.

Throughout these stages, continuous measurement and reporting activities occur

to track and understand progress in managing software risk.

This framework allows for a high-level, consistent, and iterative risk analysis
deeply integrated into the Software Development Life Cycle (SDLC). It helps in
determining investment priorities for risk mitigation and can be applied to various
development processes like waterfall, agile, or CMMI.

The RMF can be used in conjunction with other security practices such as
specifying security requirements, using misuse/abuse cases, and implementing
security touchpoints throughout the SDLC, as illustrated in Figure 1-6. This
comprehensive approach ensures that security is considered at every stage of
software development, from requirements to deployment and operations.

12. Use an example to show how error-prone modules can affect software
development.

Soln:

Error-prone modules can significantly impact software development by increasing

both the time and cost required to deliver a project. For example, if a software
project includes a module that is responsible for processing user authentication
and this module is error-prone, it may contain a disproportionate number of
defects. According to Barry Boehm’s findings, such modules typically represent 20
percent of the program but are responsible for 80 percent of the errors.
These error-prone modules are more complex, less structured, and larger than
others, making them more expensive and time-consuming to develop. For instance,
while a normal module may cost $500 to $1000 per function point to develop, an
error-prone module might cost $2000 to $4000 per function point. This significant
cost difference is due to the higher number of defects that need to be addressed,
requiring additional testing and debugging.

In the case of IBM’s IMS project, 57 percent of errors occurred in just 7 percent
of the modules, illustrating how a small portion of the codebase can dominate the
defect profile. If the error-prone user authentication module is not identified and
redesigned early, it can lead to delays in the overall project timeline, especially if
development speed is critical. Furthermore, if the module is not fully tested due to
schedule pressures, it may introduce vulnerabilities or functionality issues that
could be costly to fix after deployment, further impacting the project’s success.

Extra: Threats to Software security

Threats during development (mainly insider threats). A software engineer can
sabotage the software at any point in its development 10 Chapter 1 Why Is
Security a Software Issue? 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].

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.
 Assignment: 2

1. Define and Explain core properties of secure software

Soln:

The core properties of secure software include:

1. Confidentiality ensures that the software's characteristics, managed

assets, and content are hidden from unauthorized entities. For example, in
an open-source software project, while the code is publicly available,
confidentiality must still be maintained for sensitive managed assets like
user data.
2. Integrity requires the software and its managed assets to be resistant to
unauthorized modifications, whether by authorized users or external
threats. For example, a cross-site scripting (XSS) attack that manipulates a
web application's behavior would compromise its integrity by introducing
unintended logic.
 3. Availability mandates that the software is accessible to authorized users
whenever needed, while denying access to unauthorized users. For instance,
a denial-of-service (DoS) attack that disrupts user access would violate the
availability property.
4. Accountability involves tracking and recording all security-relevant actions
of the software, ensuring responsibility can be attributed. This is crucial for
auditing and ensuring that any changes or actions taken by the software can
be traced back to their source.
5. Non-repudiation prevents the software or its users from denying
responsibility for actions performed. For example, if a buffer overflow
attack injects malicious code that alters logs to cover tracks, it would
undermine both accountability and non-repudiation, as the true actions would
be obscured.

These properties are essential in defining and evaluating the security of software,
ensuring that any breaches can be understood in terms of their impact on these
fundamental attributes.

2. Explain Influential Properties of Secure Software

Soln:
The influential properties of secure software are:
● Dependability
● Correctness
● Predictability
● Reliability
● Safety
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 security
properties themselves.

Dependability and Security

● Dependability is the software's ability to consistently operate as intended,
sharing key properties with security, such as availability and integrity.
● Both dependability and security involve attributes like reliability, safety,
survivability, maintainability, and fault tolerance.
● Risk factors to security and dependability can be human-made or
environmental, intentional or unintentional, with intentionality and
exploitability determining security vulnerability.
● While dependability encompasses integrity and availability, it does not
inherently cover confidentiality, accountability, or non-repudiation.
Correctness and Security

● Correctness in software is critical, but security requires correctness under

both anticipated and unanticipated conditions.
● Good software engineering often neglects unanticipated conditions, leading
to potential security vulnerabilities even in correct software.
● Security requirements must be explicitly defined; requirements-driven
engineering focused solely on correctness won't ensure security.
● Security properties are often nonfunctional and harder to specify than
functional requirements, yet essential for ensuring secure software
behavior.
● Complex vulnerabilities can arise even when individual components are
correct, requiring comprehensive security-focused engineering.
 "Small" Faults, Big Consequences:

● Small defects in software can collectively lead to significant

vulnerabilities, challenging the assumption that small faults have small
impacts.
● Stack-smashing attacks exemplify how minor defects can be
exploited in combination to create serious security vulnerabilities.
● Risk analysis of all known vulnerabilities is crucial, with no tolerance
for known vulnerabilities in high-assurance systems.

Software Testing Requirements:

● Attacks are launched against the software itself

● The software’s inputs or outputs (e.g., data files, arguments, signals)
are compromised
● The software’s interfaces to other entities are compromised
● The software’s execution environment is attacked

Predictability and Security

● Predictability ensures that software behaves as expected under both
anticipated and unanticipated conditions.
● In security contexts, predictability involves minimizing vulnerabilities and
isolating the software to maintain consistent behavior during attacks.
● Ensuring predictability under unanticipated conditions strengthens the
overall security of the software.
Reliability, Safety, and Security
● Reliability ensures software executes correctly despite defects and
environmental changes, often achieved through fault tolerance.
● Safety relies on software reliability and is crucial in preventing catastrophic
outcomes, such as loss of human life or environmental damage.
● Software security extends beyond reliability and safety to address
malicious attacks and intentional vulnerabilities.
● Unlike reliability and safety failures, security failures result from human
actions and persist as long as vulnerabilities are exploited.
 ● Historically, reliability and safety were treated separately from security,
but security issues can undermine safety assurances.
● Effective software safety assurance must integrate security considerations
to prevent compromised safety due to security failures.
Size, Complexity, Traceability, and Security
● Simplicity and minimal code in software lead to easier comprehension,
maintenance, and a reduced attack surface.
● Design and implementation should be straightforward to facilitate the
discovery of design flaws and effective failure detection.
● Traceability ensures that the software design meets security requirements
and provides a basis for defining security test cases.

3. Discuss the importance of threat modeling in the software development process.

How does it help in enhancing security?

Soln:

Importance of Threat Modeling in Software Development:

1. Identification of Assets and Threats:

○ Threat modeling helps in identifying and characterizing critical assets
within the software, such as sensitive data and important
functionalities. It also identifies potential threats these assets might
face, providing a clear understanding of what needs protection.
2. Assessment of Attack Surface and Trust Boundaries:
○ By analyzing the software’s attack surface and trust boundaries,
threat modeling helps in understanding where the software is most
vulnerable. This involves identifying how attackers might exploit
weaknesses and how data flows through various components.
3. Integration of Attack Vectors and Risk Identification:
○ Threat modeling integrates information about potential attack vectors
with the characteristics of the attack surface and identified threats.
 This helps in mapping out security risks and understanding how
different attack vectors might be used by adversaries.
4. Utilization of Attack Patterns:
○ Attack patterns provide a structured way to identify likely attack
scenarios and their mitigations. They serve as a valuable tool for
characterizing attacks and ensuring that security measures are
comprehensive and effective.
5. Support for Red Teaming and Attack Resistance Analysis:
○ During attack resistance analysis, threat modeling helps in adopting
attacker perspectives to test and evaluate the software's defenses.
This proactive approach simulates real-world attack scenarios,
improving the software’s robustness.
6. Creation of Risk-Based Tests:
○ Threat modeling informs the creation of risk-based tests tailored to
the expected threats. For instance, automated tools might be used to
test against script kiddies if they are a significant threat, ensuring
that security measures are effective against likely attack methods.
7. Informed Fault Modeling:
○ Understanding the software’s environment and developer assumptions
through threat modeling supports the development of a fault model.
This helps in predicting and mitigating potential issues before they
become security vulnerabilities.

Enhancing Security:

● Proactive Risk Management: Threat modeling enables developers to

anticipate and address potential security risks early in the development
process, rather than reacting to vulnerabilities discovered later.
● Focused Security Measures: By identifying specific threats and attack
vectors, threat modeling helps in implementing targeted security controls
and countermeasures, making the software more resilient to attacks.
● Improved Testing: Leveraging threat modeling for creating risk-based tests
ensures that security testing aligns with actual threat scenarios, leading to
more effective identification of weaknesses and verification of defenses.
 ● Comprehensive Understanding: It provides a holistic view of the software’s
security posture, including how components interact and where potential
issues may arise, leading to more informed design and development decisions.

4. Justify the statement “Small Faults, Big Consequences”.

Soln:

Justification for the Statement “Small Faults, Big Consequences”

1. Conventional Wisdom and Its Flaw: Conventional wisdom suggests that

small faults in software can be tolerated, assuming they have minor
consequences. However, this belief is flawed when it comes to security
vulnerabilities.
2. Accumulation of Minor Defects: Nancy Leveson argues that vulnerabilities
in large, complex systems often arise from multiple minor defects. Each
defect may be insignificant individually but, when combined, can collectively
create a significant vulnerability.
3. Example of Stack-Smashing Attack: A classic example is the
stack-smashing attack:
■ Defect: An input function writes data to a buffer without
bounds checking.
■ Scenario: An attacker provides a long input string containing
malicious code and a return address pointer.
■ Outcome: The input overflows the stack buffer, overwrites the
return address with the malicious code location, and executes it
with root privileges. This can lead to full system compromise.
4. Inadequate Size as a Predictor of Impact: The size of a vulnerability is
not a reliable indicator of its impact. Small faults can combine to create
severe security risks, as illustrated by the stack-smashing attack example.
5. Necessity for Explicit Analysis: All known vulnerabilities, regardless of
perceived size, should be explicitly analyzed and mitigated or accepted by
 authoritative individuals within the development organization. Assumptions
about the harmlessness of small faults are a primary root of insecurity.
6. Testing for High-Assurance Systems: For high-assurance systems, it is
crucial to verify that the software behaves correctly under various
conditions, including:
■ Direct Attacks: Attacks launched against the software itself.
■ Compromised Inputs/Outputs: Attacks targeting the
software’s data files, arguments, or signals.
■ Interface Compromise: Attacks on the software’s interfaces
with other entities.
■ Environmental Attacks: Attacks on the software’s execution
environment.

5. Draw and explain the diagram of Addressing expected issues with security
architecture and features.

Soln:

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:
● Address expected issues through the application of appropriate security
architecture and features
● Address unexpected issues through the avoidance, removal, and mitigation
of weaknesses that could lead to security vulnerabilities
● 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. As shown in Figure 2–3, 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.

Without security architecture and features, adequate levels of confidentiality,

integrity, accountability, and non-repudiation may be unattainable. However, fully
addressing these properties (as well as availability) requires the development team
not only to provide functionality to manage the security behavior of the software,
but also to ensure that the functionality and architecture of the software do not
contain weaknesses that could render the software vulnerable to attack in
potentially unexpected ways.

6. Draw and explain the diagram of Addressing the unexpected through software
security.

Soln:

Addressing the unexpected in software security involves integrating security

measures throughout the software development life cycle (SDLC) to prevent
weaknesses from being introduced or to remove them as early as possible. This
approach focuses on proactive prevention rather than reactive defense.

Key aspects include:

1. Preventing Weaknesses Early: Security practices aim to identify and

mitigate potential vulnerabilities from the beginning of the development
process. This involves secure requirements engineering, where security
requirements are clearly defined to prevent weak or ambiguous requirements
from leading to vulnerabilities.
2. Comprehensive Security Practices: The development team must engage in
various security practices such as architectural risk analysis, secure code
reviews, risk-based security testing, and software penetration testing.
These practices help to identify and address potential security issues at
different stages of the SDLC.
3. Involvement of Entire Team: Software security is not solely the
responsibility of developers but requires the involvement of the entire
development team and supporting organization. Effective software security
demands a collaborative approach to integrate security into every phase of
development.
4. Continuous Integration: By incorporating security-focused practices
throughout the SDLC, teams can build software that is resilient, tolerant,
and resistant to attacks. This proactive approach ensures that security
weaknesses are addressed before the software is deployed, reducing the
likelihood of security breaches.

In summary, addressing the unexpected through software security involves early

prevention of vulnerabilities, comprehensive security practices, team-wide
involvement, and continuous integration of security measures throughout the
development process.
7. Discuss Attack Resistance, Attack Tolerance, and Attack Resilience.

Soln:

Attack Resistance, Attack Tolerance, and Attack Resilience The ultimate goal of
defensive software security efforts can be most clearly seen in their ability to
maintain security properties in the face of motivated and intentional attempts to
subvert them. The ability of software to function in the face of attack can be
broken down into three primary characteristics: attack resistance, attack
tolerance, and attack resilience.
● Attack resistance is the ability of the software to prevent the capability of
an attacker to execute an attack against it. The most critical of the three
characteristics, it is nevertheless often the most difficult to achieve, as it
involves minimizing exploitable weaknesses at all levels of abstraction, from
architecture through detailed implementation and deployment. Indeed,
sometimes attack resistance is impossible to fully achieve.
● Attack tolerance is the ability of the software to “tolerate” the errors and
failure that result from successful attacks and, in effect, to continue to
operate as if the attacks had not occurred.
● Attack resilience is the ability of the software to isolate, contain, and limit
the damage resulting from any failures caused by attack-triggered faults
that the software was unable to resist or tolerate and to recover as quickly
as possible from those failures.
Attack tolerance and attack resilience are often a result of effective
architectural and design decisions rather than implementation wizardry. Software
that can achieve attack resistance, attack tolerance, and attack resilience is
implicitly more capable of maintaining its core security properties.

8. Describe The Attacker’s Perspective with its advantages.

Soln:

The attacker’s perspective involves analyzing software from an external viewpoint,

focusing on how an adversary would approach exploiting it. This approach is crucial
for identifying vulnerabilities that may not be evident from a developer's
standpoint.

Advantages:

1. Identification of Vulnerabilities: It is easier for attackers to find

vulnerabilities than for developers to secure all potential weaknesses. By
understanding how attackers might exploit the software, developers can
address these vulnerabilities proactively.
2. Remote Exploitation: Attackers can exploit software remotely without
needing physical access, which exposes vulnerabilities more widely. This is
compounded by attackers using anonymous or public networks, making it
harder to trace and defend against attacks.
3. Knowledge Disparity: Attackers often have more practical experience in
exploiting software than developers do. Understanding the attacker’s
perspective helps bridge this knowledge gap and improves defense
strategies.
4. Complexity of Security: Just as securing a bank vault involves protecting
against various attack methods, securing software requires addressing
numerous potential attack vectors. By thinking like an attacker, developers
can design more comprehensive security measures.
5. Continuous Learning: Attackers continuously evolve their techniques, and
developers must keep up with these changes to maintain security. Adopting
the attacker’s perspective helps in staying ahead of evolving threats.

In summary, adopting the attacker’s perspective is essential for identifying and

mitigating vulnerabilities, understanding the impact of remote attacks, bridging
knowledge gaps, and continuously improving security measures.

9. How to Assert and Specify Desired Security Properties?

Soln:
To effectively assert and specify desired security properties, it is crucial to build
a security assurance case. This structured artifact demonstrates that a system
meets specific security claims through a combination of claims, arguments, and
evidence.

1. Building a Security Assurance Case: This involves creating a structured

argument supported by evidence to show that the system satisfies security
claims. Claims are supported by subclaims and evidence, such as code
reviews, static analysis results, and robustness testing. Patterns and
templates can aid in the process, ensuring consistency and completeness.
2. Example: An assurance case might assert that a system is "acceptably
secure" by providing evidence that coding defects, like buffer overflows,
have been mitigated through developer training, static analysis, and testing.
3. Incorporating into SDLC: Integrate the assurance case throughout the
software development life cycle (SDLC). Start with an outline in the
predevelopment stage, update it during development, and maintain it
post-deployment to reflect changes and evolving threats.
4. Related Efforts: Assurance cases can complement compliance with
regulations (e.g., HIPAA) and integrate with standards like Common Criteria,
which evaluates security products.
5. Maintenance and Benefits: Assurance cases provide a structured way to
demonstrate that security requirements are met and adapt to changes in the
system and evolving threats, offering a comprehensive view of security
assurance.

or

Building a Security Assurance Case

● Definition: A security assurance case is a structured artifact that

demonstrates a system satisfies specific security claims using a set of
arguments supported by evidence.
● Components:
 ○ Claims: High-level assertions about the security state of the system
(e.g., "The system is acceptably secure").
○ Arguments: Logical reasoning that supports the claims, linking them to
evidence.
○ Evidence: Concrete data and results (e.g., results from static analysis
tools, code reviews, testing outcomes) that substantiate the claims.
● Structure: Similar to a legal case, where a top-level claim is supported by
subclaims and evidence. Patterns and templates can aid in creating and
documenting assurance cases, ensuring consistency and completeness.
● Focus: Includes not just technology but also processes and people. For
instance, a subclaim might be that the absence of buffer overflow
vulnerabilities is supported by developer training, code reviews, static
analysis, and robustness testing.

A Security Assurance Case Example

● Example Structure: Illustrated using Goal Structuring Notation (GSN), this

example focuses on buffer overflow vulnerabilities.
○ Top-Level Claim: "The system is acceptably secure."
○ Subclaims: Address specific aspects such as buffer overflow
vulnerabilities, implementation errors, design deficiencies, and
operational procedures.
○ Evidence:
■ Code Scanned: Static analysis results showing no buffer
overflow possibilities.
■ Code Review: Documentation of code review results.
■ Robustness Testing: Results from testing with invalid inputs.
■ Warnings Resolution: Explanations for any false alarms
reported by analysis tools.
○ Additional Context: Explains what “acceptably secure” means in the
context of regulatory requirements or industry standards.

Incorporating Assurance Cases into the SDLC

 ● Early Integration: Develop and refine the assurance case throughout the
SDLC to guide and document security efforts.
○ Predevelopment: Outline the security case plan and ensure the
technical proposals align with security requirements.
○ Development: Continuously update the assurance case with new
evidence and outcomes from various stages of development, including
design reviews and security testing.
○ Configuration Management: Use configuration control to maintain the
integrity of the assurance case and ensure it reflects the current
state of the system.
● Post-Deployment: Maintain and update the assurance case as the system
evolves, especially when modifications are made.

Related Security Assurance and Compliance Efforts

● Security-Privacy Laws: Utilize assurance cases to demonstrate compliance

with laws like Sarbanes-Oxley and HIPAA. Patterns for these regulations
can aid in structuring compliance arguments.
● Common Criteria: An international standard for evaluating security
products, where assurance cases can incorporate CC evaluation results to
provide a broader assurance framework. Common Criteria evaluations offer a
structured format, but assurance cases offer greater flexibility and
continuity over time.

Maintaining and Benefitting from Assurance Cases

● Benefits:
○ Structured Assurance: Assurance cases provide a formal, reviewable
structure to demonstrate that security requirements are met.
○ Planning and Conduct: Aid in planning and identifying new security
issues during development.
● Maintenance: Regular updates to the assurance case are necessary to
reflect changes in the system and adapt to evolving threats.
 ○ Meta-Arguments: Assurance cases can integrate and assess various
certification methods and tools, providing a comprehensive view of
security assurance beyond individual certifications.
● Adaptability: Given the evolving nature of security threats, assurance cases
should be revisited frequently to ensure ongoing relevance and
effectiveness.

10. Explain partially expanded security assurance case that focuses on buffer
overflow

Soln:
In a partially expanded security assurance case focusing on buffer overflow, the
Goal Structuring Notation (GSN) is used to structure the argument that the
system is “acceptably secure.”

Key Components:

1. Top-Level Claim: The system is "acceptably secure," meaning it meets

required security standards.
2. Context: Clarifies what "acceptably secure" means, often referencing
regulatory requirements like HIPAA or security breach classifications.
 3. Strategy: The assurance case follows a strategy based on the Software
Development Life Cycle (SDLC), addressing security at stages such as
requirements, design, implementation, and operation.
4. Subclaims for Buffer Overflow:
○ Code Scanned: Static analysis confirms no buffer overflow defects.
■ Evidence: Tool output showing no defects and resolution of any
warnings as false alarms.
○ Robustness Testing: Tests show that invalid inputs are handled
correctly, avoiding harm.
○ Code Review: Reviews confirm no potential buffer overflow conditions.
5. Additional Elements: The full GSN notation includes justifications and
assumptions, providing reasoning and context for claims.

In essence, the assurance case uses a combination of static analysis, robustness

testing, and code reviews to demonstrate the system’s resilience against buffer
overflow vulnerabilities.

11. Describe the importance of Requirements Engineering for Secure Software

Soln:

Requirements engineering is crucial for secure software development because it

significantly impacts the success and security of the final product. Studies show
that defects originating during the requirements phase are costly and
time-consuming to fix once the system is operational, sometimes costing 10 to 200
times more than if they were detected early. Additionally, reworking defects in
requirements, design, and code accounts for 40 to 50 percent of the total project
effort, with a significant portion of these defects arising from poor requirements
engineering. These issues can lead to projects being over budget, delayed, or even
canceled, and result in poor-quality software that may not meet user needs.
Moreover, today's dynamic development environment, where requirements
frequently change due to market evolution, stakeholder conflicts, and other
factors, adds complexity to the process. Common problems in requirements
engineering, such as the failure to involve all relevant stakeholders, the use of
outdated techniques, and the lack of thorough analysis, contribute to these
challenges. Poorly specified requirements are often ambiguous, incomplete,
inconsistent, and difficult to test, making it harder to ensure security. Therefore,
effective requirements engineering is essential for creating secure software that
is reliable and meets the needs of all stakeholders

Requirements engineering is vital for the development of secure software because

it addresses the foundational issues that can lead to major project failures. Poor
requirements engineering is a top cause of several undesirable outcomes, such as:

● Projects exceeding budgets, missing deadlines, reducing scope, or getting

canceled.
● Development teams delivering low-quality applications.
● Products not being significantly used after delivery.

These failures often stem from issues in the requirements engineering process,
which suffers from several common problems:

● Incomplete Stakeholder Involvement: Requirements identification often

fails to include all relevant stakeholders and does not use the most modern
or efficient techniques.
● Inadequate Requirements Specification: Requirements are often written as
architectural constraints or implementation mechanisms, rather than clear
statements of what the system must achieve.
● Lack of Analysis and Modeling: Requirements are frequently specified
without proper analysis or modeling, and when analysis is done, it typically
focuses only on functional end-user requirements, neglecting quality
requirements like security and other crucial aspects such as architecture,
design, and testing constraints.
 ● Haphazard Requirements Specification: The requirements that are
specified are often ambiguous, incomplete, inconsistent, infeasible, obsolete,
and neither testable nor usable by all intended audiences.
● Weak Requirements Management: Management of requirements is often
ineffective, with poor data capture methods and limited to basic tracing,
scheduling, and prioritization, lacking robust change tracking or
configuration management.

Given the high costs and risks associated with poor requirements engineering,
particularly in terms of security, improving this process is essential for developing
secure, high-quality software.

12. Explain techniques of ensuring that the resulting product effectively meets
security requirements.

Soln:

To ensure that a resulting product effectively meets security requirements,

several techniques and approaches are highlighted in security requirements
engineering. These methods aim to integrate security throughout the development
lifecycle, ensuring that security is not an afterthought but a fundamental aspect
of the software design and implementation process. Here are the key techniques:

● Comprehensive, Lightweight Application Security Process (CLASP) approach

to security requirements engineering. CLASP is a lifecycle process that
suggests a number of different activities across the development life cycle
in an attempt to improve security. Among these is a specific approach for
security requirements [BSI 12].
● Security Quality Requirements Engineering (SQUARE). This process is aimed
specifically at security requirements engineering. SQUARE provides a
systematic method specifically for security requirements, focusing on
 identifying, prioritizing, and refining these requirements to ensure they are
clearly articulated and addressed throughout the development process.
● Core security requirements artifacts [Moffett 2004]. This approach takes
an artifact view and starts with the artifacts that are needed to achieve
better security requirements. It provides a framework that includes both
traditional requirements engineering approaches to functional requirements
and an approach to security requirements engineering that focuses on assets
and harm to those assets.
● Other useful techniques:
● Formal Specification Approaches: Techniques like Software Cost Reduction
(SCR) and the higher levels of the Common Criteria use formal specifications
to define and rigorously validate security requirements, ensuring precision
and robustness in meeting security standards.
● SOAR Report: Software Security Assurance: The SOAR report offers a
comprehensive discussion of SDLC processes and various security
requirements engineering approaches, providing valuable guidance on applying
these techniques throughout the software development lifecycle.

13. Explain Misuse Cases and Abuse case with appropriate example.

Soln:

Misuse Cases and Abuse Cases are critical components in the field of security
requirements engineering, designed to help developers anticipate abnormal or
malicious behavior that might exploit vulnerabilities in a system. These concepts
extend beyond traditional use cases, which typically focus on intended, normative
behavior, by exploring how features could be misused or abused.

Understanding Misuse Cases

Misuse cases are scenarios where an attacker intentionally uses a system in ways
that were not intended by the developers. These cases highlight potential
vulnerabilities by considering how features or functionalities could be exploited.
Misuse cases are especially useful in identifying security gaps by analyzing how the
system might behave under negative or unintended conditions.

● Example: Imagine a car’s security system designed with various use cases
such as "Lock the car" and "Drive the car." A misuse case might be "Steal
the car," which explores how an attacker might short the ignition to bypass
the car's locking mechanism. This misuse case forces the designers to
consider and mitigate this potential threat, perhaps by enhancing the
ignition security or adding a secondary authentication layer.

Understanding Abuse Cases

Abuse cases are a specific subset of misuse cases that focus on scenarios where
the system is subjected to harmful or malicious activities with the intent to cause
damage or disruption. Abuse cases are directly concerned with the negative
impacts that could result from malicious behavior and emphasize the importance of
securing the system against such attacks.

● Example: Consider a client-server application where the client is responsible

for managing data-access permissions. In an abuse case, a malicious user
could intercept network traffic, alter the data, and inject unauthorized
 commands into the system. For instance, if the server trusts that any data
sent by the client is legitimate, the attacker could exploit this trust to
inject harmful data into the system's database, bypassing security controls
and potentially causing significant damage.

Creating and Using Misuse and Abuse Cases

The process of creating misuse and abuse cases involves identifying potential
negative interactions with the system and determining how the system should
react to such scenarios. This typically begins with informed brainstorming sessions,
where security experts and system designers collaborate to think like attackers.
The goal is to foresee potential threats and design defenses against them.

● Key Questions: When creating these cases, developers might ask:

○ What assumptions are implicit in our system?
○ How could these assumptions be invalidated by an attacker?
○ What types of attack patterns might be employed against this
system?
○ How can the system differentiate between legitimate and illegitimate
use?
● Approach: The creation of misuse and abuse cases should not be a
stand-alone activity but integrated into the broader security requirements
engineering process. This integration ensures that security is considered
from the very beginning of the software development lifecycle (SDLC) and is
revisited at every stage, from design to deployment.

Practical Application of Misuse and Abuse Cases

Misuse and abuse cases are not merely theoretical tools but practical methods
for enhancing system security. For example, in the case of a client-server
application where the client manages sensitive data, abuse cases might reveal that
relying solely on client-side validation is a significant security risk. This insight
would lead developers to implement additional server-side checks and balances,
ensuring that unauthorized data cannot be injected, even if the client is
compromised.
 ● Use in Development: As new features or use cases are developed,
developers should concurrently create misuse and abuse cases to explore
how these new functionalities could be exploited. This continuous, proactive
approach ensures that security is built into the system from the ground up
rather than being added as an afterthought

14. Explain the first six steps of the SQUARE Process.

Soln:
The SQUARE (Security Quality Requirements Engineering) process is a systematic
approach designed to integrate security requirements into the software
development lifecycle. Here's an explanation of the first six steps of the SQUARE
process:
Step 1: Agree on Definitions
This foundational step ensures that all team members have a unified understanding
of key terms related to security requirements. Given that different team members
might have varying interpretations of terms based on their previous experiences,
this step involves selecting or tailoring definitions from recognized sources like
IEEE or SWEBOK. A focus group meeting with stakeholders is typically held to
agree on a consistent set of definitions, which helps prevent misunderstandings
during the subsequent steps of the process.

Step 2: Identify Security Goals

Security goals are established at the organizational level to ensure consistency
with the company’s policies and operational environment. Different stakeholders,
such as those in human resources or finance, may have unique security concerns,
such as protecting confidential information or ensuring financial data integrity.
This step involves gathering input from a representative set of stakeholders to
identify and prioritize these goals, ensuring they align with the core properties of
the organization.

Step 3: Develop Artifacts

Artifacts are essential documents and materials that support the security
requirements engineering activities. These may include the concept of operations,
project goals, normal usage scenarios, threat scenarios, misuse or abuse cases, and
more. Without these artifacts, the requirements process may rely on unstated
assumptions, leading to gaps in the security requirements. Developing these
artifacts ensures that the requirements process is built on a solid foundation.

Step 4: Perform Risk Assessment

A risk assessment is conducted to identify and prioritize potential security risks.
This step requires the expertise of a risk assessment specialist who, along with
stakeholders and security requirements engineers, selects an appropriate risk
assessment method based on the organization’s needs. The artifacts developed in
Step 3 provide critical input for this assessment, and the results help in
identifying high-priority security risks that should be addressed in the security
requirements.

Step 5: Select Elicitation Technique

Choosing the right elicitation technique is crucial, especially in projects with
diverse stakeholders. Depending on the complexity and diversity of the project, a
formal elicitation technique such as the Accelerated Requirements Method, Joint
Application Design, or structured interviews may be employed. These techniques
help overcome communication barriers and ensure that the security requirements
of all stakeholders are understood and documented.

Step 6: Elicit Security Requirements

This step involves the actual gathering of security requirements using the selected
elicitation technique from Step 5. The process is guided by the artifacts and the
risk assessment outcomes from previous steps. Techniques such as misuse cases,
attack trees, and threat scenarios are typically utilized to facilitate the elicitation
process. The goal is to capture detailed security requirements that align with the
organization’s goals and identified risks.

15. Discuss Ranking of Assessment Techniques

Soln:
Ranking of Assessment Techniques

In the context of risk assessment for secure software development, several

methodologies were evaluated to determine their effectiveness across four key
criteria. The techniques considered in this evaluation include:

1. General Accounting Office Model (GAO)

2. National Institute of Standards and Technology (NIST) Model
3. NSA’s INFOSEC Assessment Methodology (NSA/IAM)
4. Security Attribute Evaluation Method (SAEM) by Shawn Butler
5. Vendor Risk Assessment and Threat Evaluation (V-Rate) by Carnegie
Mellon
6. Risk Filtering, Ranking, and Management Model by Yacov Haimes
7. Survivable Systems Analysis (SSA) by Carnegie Mellon
8. Defect Detection and Prevention (DDP/Feather) by Martin Feather

These techniques were assessed based on the following criteria:

1. Suitability for Small Companies: How appropriate the technique is for

smaller organizations with potentially limited resources.
2. Feasibility to Complete within Time Frame: Whether the technique can be
completed within a practical and reasonable timeframe.
 3. Does Not Require Additional Data Collection: The extent to which the
technique can be applied without needing extra data beyond what is typically
available.
4. Suitable for Requirements: How well the technique addresses the specific
security requirements of the project.

Analysis of Ranking Results

Based on the assessment:

● SAEM received the highest overall score (4.00), indicating its strong
suitability across all criteria. It is particularly noted for its adaptability,
making it highly effective for different types of projects, including those
with stringent requirements and limited timeframes.
● V-Rate (3.75) also performed well, demonstrating a robust capability to
meet the needs of small companies while being feasible to implement without
additional data collection.
● DDP/Feather (3.25) scored well, especially in addressing the security
requirements, although it may not be as suitable for very small companies
compared to the top-ranked methods.
● GAO, NSA/IAM, and SSA each scored an average of 2.50. These methods
are generally balanced but may not excel in all areas. They are practical for
certain scenarios, particularly when the specific project or organizational
context aligns with their strengths.
● Haimes (2.00) and NIST (1.50) scored lower overall, indicating they may be
less suitable for small companies and could require additional data or have
other limitations that make them less ideal in certain contexts. NIST in
particular was noted for being less suitable in addressing requirements and
requiring more data collection, which contributed to its lower score.

Conclusion

The rankings suggest that SAEM and V-Rate are the most versatile and effective
techniques, particularly for small companies needing a practical and timely risk
assessment solution. These methods can be confidently recommended for a wide
range of projects. NIST and Haimes, while valuable in certain contexts, may
require more resources or be less adaptable, making them less favorable for
general use without careful consideration of their specific advantages.

16. Describe any six elicitation methods.

Soln:

The following list identifies several methods that could be considered for eliciting
security requirements. Some have been developed specifically with security in mind
(e.g., misuse cases), whereas others have been used for traditional requirements
engineering and could potentially be extended to security requirements.

● Misuse Cases
● Soft Systems Methodology (SSM)
● Quality Function Deployment (QFD)
● Controlled Requirements Expression (CORE)
● Issue-Based Information Systems (IBIS)
● Joint Application Development (JAD)
● Feature-Oriented Domain Analysis (FODA)
● Critical Discourse Analysis (CDA)
● Accelerated Requirements Method (ARM)

Misuse Cases
Misuse cases apply the concept of a negative scenario—situations that the system’s
owner wants to avoid. This method is useful in identifying potential security
threats by analyzing the worst-case scenarios. For example, business leaders,
military planners, and game players use similar strategies to anticipate and counter
their opponents' best moves, identifying them as potential threats.
Soft Systems Methodology (SSM)
SSM deals with "soft problems," which are complex and involve significant social,
political, and human activities. These are not easily defined, unlike "hard problems,"
which are more technical. SSM is useful for structuring and resolving such issues.
For instance, it can be applied to situations like disaster planning or improving
Medicare, where the problems are broad and multifaceted.
Quality Function Deployment (QFD)
QFD is a method that translates customer requirements into technical
specifications throughout the product development process. Its main focus is on
customer needs, ensuring that these are central to all development activities. This
method helps organizations prioritize actions, promote teamwork, define clear
objectives, and reduce development time.
Controlled Requirements Expression (CORE)
CORE is a method that involves both the user and the developer in creating the
requirements specification. It begins with defining the problem and breaking it
down into user and developer viewpoints, followed by analysis of these viewpoints.
CORE is particularly useful in clarifying the user's perspective on the services to
be provided by the proposed system.
Issue-Based Information Systems (IBIS)
IBIS is based on the principle that designing solutions for complex problems
involves an exchange of ideas among stakeholders. Each stakeholder contributes
their expertise and perspective to resolve design issues. This method is
particularly effective for "wicked problems," where the problem itself may not be
fully understood at the outset.
Joint Application Development (JAD)
JAD is specifically designed for the development of large computer systems. It
involves all stakeholders in the design phase through structured and focused
meetings. The goal is to gather information, validate it, and establish a set of
agreed-upon security requirements. This method ensures that all stakeholders'
inputs are considered, leading to more robust and agreed-upon requirements.

17. Explain Elicitation Evaluation Criteria in detail.

Soln:
Following are example evaluation criteria that may be useful in selecting an
elicitation method, although you could certainly use other criteria. The main point
is to select a set of criteria and to have a common understanding of what they
mean.
● Adaptability. The method can be used to generate requirements in multiple
environments. For example, the elicitation method works equally well with a
software product that is near completion as it does with a project in the
planning stages.
● Computer-aided software engineering (CASE) tool. The method includes a
CASE tool.
● Stakeholder acceptance. The stakeholders are likely to agree to the
elicitation method in analyzing their requirements. For example, the method
isn’t too invasive in a business environment.
● Easy implementation. The elicitation method isn’t overly complex and can be
properly executed easily
● Graphical output. The method produces readily understandable visual
artifacts.
● Quick implementation. The requirements engineers and stakeholders can
fully execute the elicitation method in a reasonable length of time.
● Shallow learning curve. The requirements engineers and stakeholders can
fully comprehend the elicitation method within a reasonable length of time.
● High maturity. The elicitation method has experienced considerable
exposure and analysis with the requirements engineering community.
● Scalability. The method can be used to elicit the requirements of projects
of different sizes, from enterprise-level systems to smallscale applications

It's important to note that these criteria may not be equally important for all
projects. In such cases, a weighted average approach can be used to prioritize
certain criteria. For example, criteria can be classified as "essential" (weight 3),
"desirable" (weight 2), or "optional" (weight 1).

When evaluating methods, a tabular form can be used to rank them based on these
criteria. This allows for a systematic comparison of different elicitation methods.
Additional considerations when selecting elicitation methods include:

1. Combining methods: Sometimes, a combination of methods may yield the

best results.
2. Time and resources: Consider the time required to implement a method and
learn any associated tools.
3. Stakeholder diversity: Selecting a method that accommodates diverse
stakeholder needs can help address a broader range of security
requirements.

By carefully evaluating elicitation methods using these criteria, requirements

engineers can choose the most appropriate approach for their specific project,
ultimately leading to more comprehensive and effective security requirements
gathering.

18. Explain Binary Search Tree (BST) and Theory W.

Soln:

Binary Search Tree (BST):

● A binary search tree is an algorithm that is typically used in a search for

information and can easily be scaled to be used in prioritizing many
requirements [Ahl 2005]. The basic approach for requirements is as follows,
quoting from [Ahl 2005]:
● Put all requirements in one pile.
● Take one requirement and put it as the root node.
● Take another requirement and compare it to the root node.
● If the requirement is less important than the root node, compare it to the
left child node. If the requirement is more important than the root node,
compare it to the right child node. If the node does not have any
appropriate child nodes, insert the new requirement as the new child node to
 the right or left, depending on whether the requirement is more or less
important.
● Repeat Steps 3 and 4 until all requirements have been compared and
inserted into the BST.
● For presentation purposes, traverse through the entire BST in order and put
the requirements in a list, with the least important requirement at the end
of the list and the most important requirement at the start of the list

Theory-W:
Theory-W (also known as “win-win”) was initially developed at the University of
Southern California in 1989 [Boehm 1989; Park 1999]. This method supports
negotiation to solve disagreements about requirements, so that each stakeholder
has a “win.” It relies on two principles:
● Plan the flight and fly the plan.
● Identify and manage your risks.

The first principle seeks to build well-structured plans that meet predefined
standards for easy development, classification, and query. “Fly the plan” ensures
that the progress follows the original plan. The second principle, “Identify and
manage your risks,” involves risk assessment and risk handling. It is used to guard
the stakeholders’ “win-win” conditions from infringement. In win-win negotiations,
each user should rank the requirements privately before negotiations start. In the
individual ranking process, the user considers whether he or she is willing to give up
on certain requirements, so that individual winning and losing conditions are fully
understood
 Assignment: 3

1. Describe Security-Specific Objectives of Software Architecture and Design.

Soln:

Security-Specific Objectives of Software Architecture and Design

1. Comprehensive Functional Security Architecture:

○ The architecture ensures that all necessary security features and
capabilities are fully enabled and integrated. This means that from
the very foundation of the software, security is not an afterthought
but a built-in aspect that addresses various potential threats
comprehensively.
2. Attack Resistance:
○ The design aims to minimize the presence of security weaknesses that
could be exploited by attackers. By reducing vulnerabilities at the
design stage, the software becomes more robust against potential
security breaches, ensuring that it can withstand attempted attacks
without being easily compromised.
3. Attack Tolerance:
○ Even when under attack, the software is designed to maintain its
functionality and capabilities. This means that while the software may
be targeted, its core functions remain operational, preventing
significant disruption to its intended use or service.
4. Attack Resilience:
○ In situations where an attack is successful, the architecture is
designed to limit the impact of that attack. The software is built to
minimize the damage and recover quickly, ensuring that the effects of
any compromise are contained and do not lead to catastrophic failures
or widespread vulnerabilities.
2. Discuss General Objectives of Software Architecture and Design.

Soln:

General Objectives of Software Architecture and Design

1. Completeness:
○ The architecture and design must fully support the scope of all
defined requirements. This ensures that the software can meet the
expectations and needs set out during the requirements phase without
gaps, covering all functional aspects necessary for the system's
operation.
2. Stability:
○ The design must ensure that the software consistently performs as
intended within its defined operational context. This means that
under normal conditions, the software should function reliably without
unexpected behavior, ensuring confidence in its operation over time.
3. Flexibility:
○ The architecture should be adaptable to changing conditions and
requirements. It should be designed in a way that allows for easy
modification or replacement of components with minimal impact on the
overall system. This ensures that the software can evolve and adapt
to future needs without requiring a complete overhaul.
4. Extensibility:
○ The design should leverage industry standards, making the software
long-lived and resistant to obsolescence. By adhering to widely
accepted practices and technologies, the software can be extended or
enhanced in the future without becoming outdated or incompatible
with newer systems.
5. Scalability:
○ The architecture must ensure that the software operates effectively
at any size and load. Whether the system is handling a small number
 of users or scaling up to support a much larger user base, the design
should accommodate growth without performance degradation.

3. Explain the six activities of risk analysis methodology.

Soln:

4. Draw and explain High-level, one-page system software architecture diagram.

Soln:

High-Level, One-Page System Software Architecture Diagram

A high-level, one-page system software architecture diagram is a critical tool for

understanding the structure, components, and interactions of a software system.
It provides an overview that helps in identifying architecture and design-level
flaws that may not be apparent at the code level. Here’s a breakdown of the key
elements typically included in such a diagram:

1. System Tiers:
○ First Tier (Untrusted): This layer often includes client-side
components. For instance, it may differentiate between:
■ Thick Client: A more complex client application, such as an
applet.
■ Thin Client: A simpler client that operates via a web browser
using JavaScript.
○ Second Tier (Trusted): This tier encompasses the main application
logic and infrastructure, including:
■ Application Server: Where core business logic is executed.
■ Web Container: Hosts web components like Servlets and
JavaServer Pages (JSP).
■ Session and Business Beans: Manage user sessions and
business logic.
■ Entity Beans: Represent and manage data entities.
○ Third Tier (Highly Trusted): This layer involves the data storage,
represented by:
■ Database Host: The system that stores and retrieves data.
2. Networking:
○ Internet: Connects clients to the host system, representing external
interactions.
○ LAN (Local Area Network): Internal network connecting the host
system and the database.
3. Additional Components:
○ Middleware: Facilitates communication between different system
parts.
○ Cache/Store: Temporary storage used to improve performance and
manage data.
4. Zones of Trust:
○ The diagram illustrates different zones of trust:
■ Untrusted Zone: Often includes the client-side components.
 ■ Trusted Zones: Typically include the application server and
database, which are considered more secure.
5. Data and Control Flow:
○ Arrows in the diagram show how data and control move between
components, indicating interactions and dependencies.
6. Business Interactions:
○ B2C (Business-to-Consumer): Interactions between the system and
individual users.
○ B2B (Business-to-Business): Interactions between the system and
other businesses or systems.
7. Potential Attack Vectors:
○ Avatars and Arrows: Represent potential attackers and their attack
vectors. These are crucial for understanding where vulnerabilities
might exist and how attackers could exploit them.
8. Purpose and Utility:
○ Overview: Provides a “forest-level” view of the system, showing major
components and their interactions.
○ Risk Identification: Helps in identifying high-level architectural and
design flaws.
○ Foundation for Detailed Analysis: Serves as a basis for more
detailed risk assessments and threat modeling.

By offering a comprehensive yet succinct representation of the software system,

this diagram is essential for effective architectural risk analysis. It enables
stakeholders to quickly understand the system’s structure, potential
vulnerabilities, and areas that may need further scrutiny..

5. Explain any four threat source with their motivation and threat actions.

Soln:

Explanation of Four Threat Sources

1. Cracker
○ Motivation:
■ Crackers are typically motivated by challenge, ego, or rebellion.
They may seek to prove their skills, gain recognition, or defy
authority.
○ Threat Actions:
■ System Profiling: Gathering information about a system to
identify potential vulnerabilities.
■ Social Engineering: Manipulating individuals to divulge
confidential information.
■ System Intrusion and Break-ins: Gaining unauthorized access
to systems.
■ Unauthorized System Access: Exploiting weaknesses to enter
systems without permission.
2. Computer Criminal
○ Motivation:
■ Computer criminals are primarily motivated by monetary gain,
destruction of information, or illegal information disclosure.
○ Threat Actions:
■ Cyberstalking: Using technology to harass or stalk individuals.
■ Fraudulent Acts: Includes replay attacks, impersonation, and
interception to deceive or defraud individuals or organizations.
■ Information Bribery and Spoofing: Offering bribes for
information or misleading users into believing false identities.
■ System Intrusion: Unauthorized access and control over
systems.
■ Malware: Deploying malicious software like Trojans, viruses,
worms, and spyware.
■ Spam and Phishing: Sending unsolicited messages or fraudulent
attempts to obtain sensitive information.
3. Terrorist
○ Motivation:
 ■ Terrorists are driven by motives such as blackmail, destruction,
exploitation, revenge, monetary gain, or political gain.
○ Threat Actions:
■ Bombs and Information Warfare: Using explosive devices or
cyber attacks to cause disruption or damage.
■ System Attack: Includes distributed denial of service (DDoS)
attacks or other methods to overwhelm and disable systems.
■ System Penetration and Tampering: Gaining unauthorized
access to manipulate or destroy system resources.
4. Industrial Espionage
○ Motivation:
■ The primary motivations for industrial espionage include
obtaining competitive advantages, economic espionage, and
blackmail.
○ Threat Actions:
■ Economic Exploitation and Information Theft: Stealing
proprietary or sensitive business information to gain a
competitive edge.
■ Social Engineering and Intrusion: Manipulating individuals or
breaking into systems to access confidential data.
■ Unauthorized Access: Gaining access to classified or
proprietary information through various means.

6. Describe structured external, transnational external, and unstructured external

threats.

Soln:

Some threat actors are external. These attackers could include structured
external, transnational external, and unstructured external threats:
 ● Structured external threats are generated by a state-sponsored entity,
such as a foreign intelligence service. The resources supporting the
structured external threat are usually quite substantial and highly
sophisticated.
● Transnational threats are generated by organized non-state entities, such
as drug cartels, crime syndicates, and terrorist organizations. Such threats
generally do not have as many resources behind them as do structured
threats (although some of the larger transnational threat organizations may
have more resources than some smaller structured threat organizations).
The nature of the transnational external threat makes it more difficult to
trace and provide a response, however. These kinds of threats can target
members or staff of the Treasury, for example, by employing any or all of
the techniques mentioned above.
● Unstructured external threats are usually generated by individuals such as
crackers. Threats from this source typically lack the resources of either
structured or transnational external threats but nonetheless may be very
sophisticated. The motivation of such attackers is generally—but not
always—less hostile than that underlying the other two classes of external
threats. Unstructured threat sources generally limit their attacks to
information system targets and employ computer attack techniques. New
forms of loosely organized virtual hacker organizations (hacktivists—hackers
and activists) are also emerging.

7. Discuss any three CAPEC classes in detail.

Soln:

Common Attack Pattern Enumeration and Classification describes the following

classes of attack, among others:
● Abuse of functionality
● Spoofing
● Probabilistic techniques
● Exploitation of privilege or trust
● Injection • Resource manipulation
● Time and state attacks

1. Abuse of Functionality:
○ Description: This attack pattern involves exploiting the intended
functionality of a software application to perform unintended actions.
Attackers leverage legitimate features of the system in a way that
was not anticipated by the developers, often leading to security
breaches.
○ Example: An attacker might use a feature designed for legitimate
user administration to gain unauthorized access or perform actions
beyond the scope of normal user privileges.
2. Spoofing:
○ Description: Spoofing attacks involve an attacker pretending to be
someone or something they are not, in order to deceive users or
systems. This can involve falsifying user identities, or masquerading as
a trusted entity to gain access or information.
○ Example: An attacker could spoof an email address to make it appear
as if a message is coming from a trusted source, thereby tricking the
recipient into revealing sensitive information or installing malicious
software.
3. Injection:
○ Description: Injection attacks occur when an attacker is able to
insert malicious code into a program’s input fields, which is then
executed by the system. This type of attack can compromise the
system by executing unintended commands or queries.
○ Example: SQL injection is a common form of injection attack where
an attacker inputs malicious SQL statements into a query field,
allowing them to access or manipulate database contents in ways not
intended by the application.
8. Discuss any six top-level CWE categories for architecture and source code.

Soln:

Common Weakness Enumeration (CWE) includes seven top-level categories for

architecture and source

Certainly! Let's ensure that the response covers all the key technical terms and
details from the provided content. Here's a revised and more detailed version of
the response:

Top-Level CWE Categories for Architecture and Source Code:

1. Data Handling:
○ Description: This category encompasses vulnerabilities related to the
improper handling and management of data within the software. It
includes issues like incorrect validation, inadequate protection of
sensitive information, and improper data processing.
○ Example: An application failing to validate input data correctly, which
could lead to data corruption, unauthorized access, or data loss.
2. API Abuse:
○ Description: This category addresses vulnerabilities that arise from
the misuse or abuse of Application Programming Interfaces (APIs). It
involves exploiting APIs in ways that were not intended, which can
lead to security issues such as unauthorized data access or
manipulation.
○ Example: Exploiting a public API endpoint that lacks proper security
controls, allowing attackers to access or modify data inappropriately.
3. Security Features:
○ Description: This category deals with flaws in the design and
implementation of security features. It includes weaknesses in
mechanisms such as authentication, authorization, encryption, and
other security controls.
 ○ Example: An authentication system that uses weak passwords or fails
to implement multi-factor authentication, making it easier for
attackers to bypass security controls.
4. Time and State:
○ Description: This category covers vulnerabilities related to timing and
state management within the software. Issues include race conditions
and improper handling of time-dependent actions, which can result in
unpredictable system behavior.
○ Example: A race condition where concurrent processes or threads
access shared resources without adequate synchronization, leading to
potential security breaches or system instability.
5. Error Handling:
○ Description: This category involves weaknesses in how the system
handles errors and exceptions. Poor error handling can lead to
information leakage, system crashes, or other unintended behaviors.
○ Example: Revealing detailed error messages or stack traces to users,
which can provide attackers with insights into the system’s internal
workings and vulnerabilities.
6. Code Quality:
○ Description: This category addresses vulnerabilities stemming from
poor coding practices. It includes issues such as inadequate input
validation, coding errors, and lack of thorough code reviews.
○ Example: Buffer overflow vulnerabilities resulting from improper
bounds checking in code, which can lead to system crashes or
exploitation.
7. Encapsulation:
○ Description: This category focuses on vulnerabilities related to the
improper encapsulation of data and functionality. Poor encapsulation
can result in unintended access to internal components or sensitive
data.
○ Example: Exposing internal class variables or methods that should be
private, thereby allowing external code to interact with and
potentially misuse internal components.
9. Explain Risk Impact Determination in detail.

Soln:

1. Identify Threatened Assets:

● Explanation: To determine the impact of a risk, it is crucial to first identify

which assets are threatened if the risk materializes. This involves
understanding what will happen to these assets in the event of a risk
occurring. Common impacts on information assets include:
○ Loss of data
○ Corruption of data
○ Unauthorized or unaudited modification of data
○ Unavailability of data
○ Corruption of audit trails
○ Insertion of invalid data

By identifying these aspects, you can assess how critical the threatened assets are
to the organization and what the specific consequences might be if these assets
are compromised.

2. Identify Business Impact:

● Explanation: Beyond the technical impacts, it is essential to evaluate the

business impact of a risk. This involves characterizing the effects on the
business in specific terms. Risk management is often driven by the monetary
implications of risks. For example:
○ If addressing a risk costs more than the potential financial damage
from the risk itself, it may not be justified.
○ Prioritizing risks that could lead to significant financial losses, such as
a $25 million drop in market capitalization, over risks with lesser
financial consequences, like a $500,000 regulatory penalty, ensures
resources are allocated effectively.
Examples of business impacts include: - Loss of market share - Loss of reputation -
Depreciation of stock value - Fines, legal fees, and judgments - Costs of technical
remediation - Theft

A concrete example is the TJX data breach, where lax security led to significant
financial consequences, including potential costs estimated at $4.5 billion due to
fines, legal fees, notification expenses, and brand damage.

3. Risk Exposure Statement:

● Explanation: The risk exposure statement integrates the likelihood of a risk

with its impact to provide an overall summary of risk exposure for the
organization. This statement helps in understanding the general risk profile
of the organization and offers detailed visibility into both the impact and
likelihood of each risk.

The risk exposure statement enables organizations to manage risks more

effectively by providing a clearer picture of their potential exposure. It allows for
informed decision-making regarding risk management priorities and helps in
balancing the need to mitigate risks with the recognition that not all risks can be
eliminated. As Alan Greenspan noted, managing risk is crucial for economic growth,
and it’s important to recognize that some level of risk-taking is necessary.

10. Explain any three Common Security Bugs and Attack Strategies with Known
Solution Approaches.

Soln:
Common Security Bugs and Attack Strategies with Known Solution Approaches
● Incorrect or incomplete input validation
● Poor or missing exception handling
● Buffer overflows
● SQL injection
● Race conditions
1. Input Validation:

● Description: Input validation issues occur when a system does not properly
check the data it receives from users or other sources. This lack of
validation can lead to various security vulnerabilities, such as cross-site
scripting, integer overflows, and DNS cache poisoning.
● Attack Strategy: Attackers exploit insufficient input validation by injecting
malicious data or commands into the system. For example, SQL injection
attacks rely on improper validation of user inputs to execute unauthorized
SQL queries.
● Known Solution Approach: An effective solution is to implement a whitelist
approach for input validation. This involves specifying all acceptable inputs
and rejecting anything that does not meet these criteria. This approach
helps to prevent common attacks by ensuring only valid data is processed by
the system.

2. Buffer Overflows:

● Description: Buffer overflows occur when a program writes more data to a

buffer than it can hold, leading to the overwriting of adjacent memory. This
vulnerability is common in languages like C and C++ that do not perform
automatic bounds checking.
● Attack Strategy: Attackers exploit buffer overflows by injecting malicious
code into the overflowed memory. This can lead to various outcomes,
including program crashes, unexpected behavior, or unauthorized code
execution.
● Known Solution Approach: To prevent buffer overflows, developers should
implement bounds checking within their code to ensure that data written to
buffers does not exceed their allocated size. Additionally, using safer
programming languages with built-in memory management features can help
mitigate these risks.

3. SQL Injection:
 ● Description: SQL injection vulnerabilities arise when an application
improperly constructs SQL queries using user-supplied data. Attackers can
manipulate these queries to execute arbitrary SQL commands on the
database.
● Attack Strategy: By injecting malicious SQL code into input fields,
attackers can bypass authentication controls, access or modify database
records, and even execute commands at the operating system level if the
database permits.
● Known Solution Approach: The primary defense against SQL injection is to
use parameterized queries or prepared statements. These techniques ensure
that user input is treated as data rather than executable code, thereby
preventing unauthorized SQL commands from being executed.

11. Explain any three problems detected by static code analyzers.

Soln:
Static analysis tools look for a fixed set of patterns or rules in the code in a
manner similar to virus-checking programs. While some of the more advanced tools
allow new rules to be added to the rulebase, the tool will never find a problem if a
rule has not been written for it. Here are some common problems detected by
these tools:

1. Syntax Problems
2. Unreachable Code
3. Unconditional Branches into Loops
4. Undeclared Variables
5. Uninitialized Variables
6. Parameter Type Mismatches
7. Uncalled Functions and Procedures
8. Variables Used Before Initialization
9. Non-Usage of Function Results
10. Possible Array Bound Errors
 11. Misuse of Pointers

Explanation of Three Problems:

1. Syntax Problems:
○ Description: Syntax problems occur when the code does not conform
to the language's grammar rules. These issues can include missing
punctuation, incorrect keywords, or malformed statements.
○ Example: A missing semicolon at the end of a statement in C++ can
cause a syntax error. Static code analyzers detect these issues by
checking the code structure against the language’s syntax rules.
○ Impact: Syntax errors prevent the code from compiling and running,
making them critical to fix before further testing or deployment.
2. Unreachable Code:
○ Description: Unreachable code refers to portions of the code that
can never be executed due to the flow of control in the program. This
can happen if there are return statements or breaks that render
subsequent code segments inaccessible.
○ Example: If a function has a return statement before the end, any
code after that return statement is unreachable. Static analyzers
identify such dead code to improve code quality and remove
redundancy.
○ Impact: Unreachable code can clutter the codebase, making it harder
to maintain and understand. Removing such code can simplify the logic
and improve readability.
3. Uninitialized Variables:
○ Description: Uninitialized variables are those that are declared but
not assigned a value before they are used. This can lead to
unpredictable behavior or runtime errors since the variable might
contain random data.
○ Example: In C++, if a local variable is declared without an initial value
and is used in a calculation, the result can be erroneous. Static
analyzers detect these variables and flag them for initialization.
 ○ Impact: Using uninitialized variables can cause bugs that are difficult
to reproduce and diagnose, leading to unreliable software behavior.
Initializing variables properly helps ensure predictable and stable
operation.

12. Explain Metric Analysis with example.

Soln:

Metric analysis involves measuring quantitative aspects of code to assess various

attributes, helping to improve code quality and decision-making. Metrics are used
to gain insights into code characteristics and their impacts.

Explanation:

1. Definition and Process:

○ Metric analysis provides a numerical representation of code
attributes. It starts with deriving appropriate metrics for the code,
followed by data collection, computation, and comparison against
guidelines or historical data.
○ Example: To evaluate the security of a software application, one
might track the “number of security breaches” and “lines of code.” By
calculating a metric like "number of breaches per 1,000 lines of code,"
you obtain a comparative measure of security defect density.
2. Types of Metrics:
○ Absolute Metrics: These are straightforward numerical values
representing specific attributes of the code without ambiguity.
Examples include the total number of lines of code or the number of
variables.
■ Example: An absolute metric could be "1000 lines of code" for a
particular module in a software application.
 ○ Relative Metrics: These provide a comparative measure and involve
some degree of estimation or approximation. They reflect attributes
that cannot be precisely quantified, such as testing difficulty.
■ Example: "Number of breaches per lines of code" is a relative
metric that indicates how secure the code is in relation to its
size. This helps in comparing different versions of the code or
different systems.

Example of Metric Analysis:

Consider a software project where you want to assess the effectiveness of recent
security improvements. You collect data on the number of security breaches and
the total lines of code in the software:

● Previous Version: 500 breaches, 50,000 lines of code

● Current Version: 300 breaches, 60,000 lines of code

Using the metric "breaches per 1,000 lines of code":

● Previous Version: (500 breaches / 50,000 lines) × 1,000 = 10 breaches per

1,000 lines
● Current Version: (300 breaches / 60,000 lines) × 1,000 = 5 breaches per
1,000 lines

Analysis: The metric shows that the security defect density has decreased from
10 to 5 breaches per 1,000 lines of code, indicating an improvement in security
relative to the size of the codebase.

Conclusion: Metric analysis helps in comparing different aspects of code and

tracking improvements or regressions. It turns raw data into actionable insights,
aiding in informed decision-making and enhancing code quality.
13. Differentiate Software Testing and Software Security Testing.

Soln:

14. Discuss any three Functional Testing Techniques.

Soln:

Functional testing usually means testing the system’s adherence to its functional
requirements. A functional requirement usually has the following form: “When a
specific thing happens, then the software should respond in a certain way.” This
way of specifying a requirement is convenient for the tester, who can exercise the
“if” part of the requirement and then confirm that the software behaves as it
should.
Three Functional Testing Techniques:

1. Requirement-Based Testing:
○ Definition: Requirement-based testing involves designing test cases
based on the functional requirements of the software. Each test case
is derived from a specific requirement to ensure that the software
meets its defined functionalities.
○ Example: If a requirement states that "A user’s account should be
disabled after three unsuccessful login attempts," the test case would
involve trying to log in with incorrect credentials three times and then
verifying that the account is indeed disabled after the third attempt.
2. Boundary Value Testing:
○ Definition: Boundary value testing focuses on testing the edges or
boundaries of input values. This technique checks the software’s
behavior at the boundaries of input ranges to ensure it handles
extreme values properly.
○ Example: For a requirement specifying that a user’s password must be
between 8 and 16 characters, boundary value testing would involve
testing passwords of exactly 8 characters, 16 characters, and values
just outside these boundaries (e.g., 7 and 17 characters) to verify
correct handling.
3. Equivalence Partitioning:
○ Definition: Equivalence partitioning divides input data into equivalent
partitions where the software is expected to behave similarly. Each
partition represents a set of inputs that should be treated the same
way by the software.
○ Example: For a field that accepts age as input and requires values
between 0 and 120, equivalence partitioning would create partitions
for valid ages (e.g., 0-120) and invalid ages (e.g., below 0 and above
120). Test cases would be created for each partition to ensure the
software handles these groups of inputs appropriately.
15. Discuss the role of security testing in Unit testing and in Integration testing.

Soln:

Security Testing in Unit Testing:

In unit testing, security testing is integral for validating the functionality of

individual components, such as classes, methods, or functions, against potential
vulnerabilities. White-box testing, a common approach in unit testing, is
particularly effective for this purpose. It involves analyzing the internal workings
of the code to find programming errors, implementation flaws, and security
vulnerabilities. This approach requires understanding what makes software secure
or insecure, thinking like an attacker, and utilizing appropriate testing tools and
techniques. By focusing on the code's data flows, control flows, and exception
handling, security testing at this level ensures that each unit adheres to security
requirements and can help uncover exploitable vulnerabilities before they affect
the larger system.

Security Testing in Integration Testing:

Integration testing examines how multiple subsystems or components work

together, making it crucial for identifying security issues related to their
interactions. Integration errors often stem from unjustified assumptions between
subsystems, such as one component assuming another is responsible for input
validation. Security testing at this stage focuses on ensuring that each subsystem
properly handles data flows and control flows, which can be influenced by
attackers. This testing is essential for detecting and addressing vulnerabilities
that arise from the integration of components, ensuring that data integrity and
security measures are maintained across the entire system