UNIT I: NEED OF SOFTWARE SECURITY AND LOW-LEVEL
ATTACKS
1. Software Assurance and Software Security
Software Assurance refers to the confidence that software is free from
vulnerabilities, whether intentional or accidental, and operates in compliance
with its functional and security requirements. It involves applying best
practices throughout the software development life cycle (SDLC) to prevent,
detect, and correct security flaws.
Software Security, on the other hand, is the discipline of designing,
developing, and testing software to be resistant to attacks. It emphasizes
proactive techniques such as threat modeling, secure coding, code reviews,
and security testing to build secure software.
Key Differences: - Software Assurance focuses on quality, including
security. - Software Security focuses purely on protecting software from
threats.
2. Threats to Software Security
Common threats to software security include: - Malicious code injection
(e.g., SQL injection, Cross-site Scripting) - Buffer overflow vulnerabilities -
Malware embedding - Privilege escalation attacks - Insecure third-
party components - Social engineering attacks (e.g., phishing)
These threats can lead to data breaches, system downtime, financial loss,
and reputational damage.
3. Sources of Software Insecurity
Poor programming practices (e.g., unsafe functions, lack of
validation)
Inadequate requirements and design
Improper integration of third-party modules
Insecure configurations and defaults
Failure to apply patches and updates
4. Benefits of Detecting Software Security Issues Early
Cost-effectiveness: Fixing security bugs early reduces remediation
costs.
Enhanced trust: Secure software increases user and stakeholder
confidence.
Regulatory compliance: Helps in meeting standards like GDPR,
HIPAA, ISO 27001.
Reduced risk exposure: Early detection mitigates the risk of
exploitation.
5. Properties of Secure Software
Confidentiality: Ensuring information is not disclosed to unauthorized
entities.
Integrity: Safeguarding the accuracy and completeness of data.
Availability: Ensuring that services are available when needed.
Authentication and Authorization: Verifying user identity and
access rights.
Accountability and Auditability: Ensuring actions can be traced and
audited.
6. Memory-Based Attacks
a. Low-Level Attacks Against Heap
Heap Overflow: Attacker overflows a buffer allocated on the heap,
potentially overwriting metadata and gaining control of the execution
flow.
Use-After-Free: Using memory after it has been freed, potentially
leading to code execution.
Double-Free: Freeing the same memory location twice, corrupting
memory management structures.
b. Low-Level Attacks Against Stack
Stack Buffer Overflow: Overwriting the return address on the stack
to execute arbitrary code.
Stack Smashing: Similar to buffer overflow but specifically targets
the stack to alter control flow.
Return-to-libc Attacks: Redirecting execution to existing library
functions to perform malicious actions.
7. Defense Against Memory-Based Attacks
Stack Canaries: Random values placed before return addresses to
detect overflows.
Address Space Layout Randomization (ASLR): Randomizing
memory layout to make exploitation difficult.
Data Execution Prevention (DEP): Marking certain memory regions
as non-executable.
Safe Libraries and Languages: Using memory-safe languages like
Rust and Java.
Compiler Defenses: Using flags like -fstack-protector,
AddressSanitizer, and UndefinedBehaviorSanitizer.
UNIT II: SECURE SOFTWARE DESIGN
1. Requirements Engineering for Secure Software
Secure software begins with identifying and specifying clear security
requirements. This includes understanding what needs to be protected, who
might attack the system, and what the potential threats are.
Key Tasks in Secure Requirements Engineering: - Asset identification -
Threat and risk analysis - Defining security goals - Prioritization of security
requirements
Security requirements are often captured through misuse cases, which show
how an attacker might misuse the system.
2. SQUARE Process Model (Security Quality Requirements
Engineering)
The SQUARE model is a nine-step process for incorporating security early in
the software lifecycle: 1. Agree on definitions 2. Identify security goals
3. Develop artifacts (e.g., use/misuse cases) 4. Perform risk
assessment 5. Select elicitation techniques 6. Elicit security
requirements 7. Categorize requirements 8. Prioritize requirements
9. Inspect and finalize requirements
SQUARE is especially effective for systems that require regulatory
compliance or have critical confidentiality, integrity, or availability needs.
3. Isolating Untrusted Executable Content
Running potentially harmful code from external sources in isolation is crucial:
- Sandboxing: Restricts what resources code can access. - Virtual
Machines and Containers: Create separated environments. - Browser
Security Models: Enforce policies like the Same-Origin Policy.
4. Stack Inspection
Used in managed environments (e.g., Java, .NET) to check if a method has
appropriate permissions by walking the call stack. Prevents untrusted code
from accessing sensitive resources.
5. Policy Specification Languages
Policy languages allow specification of access control and security policies: -
XACML (XML-based access control) - Ponder (used in enterprise systems) -
SPL (Security Policy Language)
These languages define what is allowed or denied in system access and
behavior.
6. Vulnerability Trends
Past: Buffer overflows, file inclusion, insecure configurations.
Present: Web attacks (XSS, CSRF, SSRF), cloud misconfigurations.
Future: AI model poisoning, supply chain attacks.
Sources for trends: CVE database, OWASP Top 10, CWE Top 25.
7. Code-Level Vulnerabilities
Buffer Overflow: Writing beyond buffer bounds.
Code Injection: Inserting code that gets executed by the interpreter
(SQL, command-line).
Session Hijacking: Stealing valid session identifiers (tokens/cookies)
to impersonate users.
8. Secure Design Techniques
a. Threat Modeling
A process to identify and prioritize potential threats: - STRIDE: Spoofing,
Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation
of Privilege. - DREAD: Damage, Reproducibility, Exploitability, Affected
Users, Discoverability.
b. Secure Design Principles
Least Privilege: Grant minimum access necessary.
Defense in Depth: Layered security.
Fail Securely: Systems should fail in a safe manner.
Separation of Duties: Divide tasks and privileges.
Keep It Simple: Avoid complexity to reduce vulnerabilities.
Minimize Attack Surface: Reduce code paths, services, and open
ports.
(Continued in UNIT III…)
