CB3591 – ENGINEERING SECURE SOFTWARE SYSTEMS
UNIT I – NEED OF SOFTWARE SECURITY AND LOW-LEVEL
ATTACKS
[Detailed notes for Unit I included previously]
UNIT II – SECURE SOFTWARE DESIGN
1. Requirements Engineering for Secure Software
The process of identifying and documenting the security needs of
stakeholders during the software development lifecycle.
Involves identifying security-relevant assets, threats, potential
attackers, and regulatory requirements.
Requires collaboration between developers, security experts, business
analysts, and end users.
Key Activities: - Determining misuse and abuse cases - Specifying
confidentiality, integrity, availability (CIA) requirements - Defining security
constraints and risk tolerance levels
2. SQUARE Process Model
SQUARE (Security Quality Requirements Engineering) is a
systematic process that integrates security into requirements
engineering.
Nine Steps of SQUARE: 1. Agree on Definitions: Establish common
understanding of key terms. 2. Identify Security Goals: Define high-level
objectives based on business and system context. 3. Develop Artifacts:
Create supporting artifacts like system architecture diagrams. 4. Perform
Risk Assessment: Identify risks and their potential impact. 5. Select
Elicitation Techniques: Choose appropriate methods (e.g., interviews,
focus groups). 6. Elicit Security Requirements: Collect security
requirements from stakeholders. 7. Categorize Requirements: Organize
based on confidentiality, integrity, availability. 8. Prioritize Requirements:
Based on risk levels and stakeholder input. 9. Inspect Requirements:
Review for completeness, clarity, and feasibility.
3. Requirements Elicitation and Prioritization
Elicitation Techniques:
o Interviews, Workshops, Brainstorming, Use-case analysis, Threat
modeling
Prioritization Techniques:
o MoSCoW method (Must-have, Should-have, Could-have, Won’t-
have)
o Risk-based scoring
Challenges: - Eliciting non-functional security requirements - Aligning
business goals with technical controls
4. Isolating the Effects of Untrusted Executable Content
Refers to techniques that limit the damage from executing unverified
or malicious code.
Mitigation Strategies: - Sandboxing: Restricts code to a controlled
environment. - Virtualization/Containers: Isolate applications from host
systems. - Code Signing: Ensures that code hasn’t been tampered with. -
Application Whitelisting: Allows only trusted programs to execute.
5. Stack Inspection
A security mechanism in managed code environments (e.g., Java) to
verify whether all methods in the call stack have appropriate
permissions.
Used to prevent unauthorized access to privileged operations.
Common in Java Security Manager and .NET Code Access Security
(CAS).
Key Functions: - checkPermission(): Inspects the call stack for required
privileges. - Prevents confused deputy attacks by enforcing that all callers
are authorized.
6. Policy Specification Languages
Allow administrators to formally express access control and security
policies.
Examples: - Ponder: Supports role-based and obligation policies. - XACML:
XML-based declarative access control policy language. - SELinux Policy
Language: Used to define mandatory access control rules in Linux.
Features to Consider: - Expressiveness - Granularity - Scalability -
Compatibility with existing systems
7. Vulnerability Trends
Modern Trends:
o Increasing zero-day vulnerabilities
o Rise in cloud and IoT-specific threats
o Growing supply chain attacks
Sources for Tracking Trends: - CVE (Common Vulnerabilities and
Exposures) - NVD (National Vulnerability Database) - OWASP Top Ten
8. Buffer Overflow
Occurs when data exceeds the buffer’s storage capacity, overwriting
adjacent memory.
Impact: - Control flow hijacking - Arbitrary code execution - Privilege
escalation
Prevention: - Use of bounds-checking functions (strncpy, memcpy_s) - Stack
canaries and ASLR - Language-level protections (Rust, Java)
9. Code Injection
An attacker inserts code into a vulnerable application, which then
executes it.
Types: - SQL Injection - Command Injection - LDAP Injection
Countermeasures: - Input validation and sanitization - Use of
parameterized queries - Escaping special characters
10. Session Hijacking
Attacker takes control of a user session by stealing session identifiers
(cookies, tokens).
Techniques: - Packet sniffing - Cross-site scripting (XSS) - Man-in-the-middle
(MitM) attacks
Defense Measures: - HTTPS encryption - Secure session cookie attributes
(HttpOnly, Secure, SameSite) - Session timeout and re-authentication
11. Secure Design Principles
Least Privilege: Users should have the minimum level of access
needed.
Defense in Depth: Multiple layers of security mechanisms.
Fail-Safe Defaults: Default settings should deny access.
Economy of Mechanism: Keep design as simple as possible.
Complete Mediation: Every access to a resource must be checked.
Open Design: Security should not depend on secrecy of design.
Separation of Privilege: Require multiple conditions for access.
Least Common Mechanism: Avoid sharing mechanisms between
users.
Psychological Acceptability: Security mechanisms should not make
the system unusable.
12. Threat Modeling
Objective: Identify potential security threats, classify them, and
define mitigation strategies.
Methodologies: - STRIDE (Spoofing, Tampering, Repudiation, Information
Disclosure, Denial of Service, Elevation of Privilege) - DREAD (Damage
potential, Reproducibility, Exploitability, Affected users, Discoverability)
Steps: 1. Identify assets 2. Create an architecture overview 3. Decompose
the application 4. Identify threats 5. Document and rate the threats 6. Define
mitigation measures
Threat modeling is a critical process that ensures security is not just an
afterthought but integrated into the early stages of design.
UNIT III – SECURITY RISK MANAGEMENT
…
