W1.2 Software Security Learning Strategy

What is software security?

Software security focuses on engineering software to continue functioning correctly under malicious attacks. It balances functional requirements, non-functional requirements, and performance vs security tradeoffs.

How is security different from correctness?

• Normal users accidentally find bugs and try to avoid them
• Adversaries deliberately seek bugs and actively try to exploit them
• Adversaries systematically explore edge cases and boundary conditions that normal testing might miss

What are implementation bugs in software security?

• Detectable through program analysis tools
• Examples: buffer overflows, null pointer dereferences, race conditions
• Think of these as typos or arithmetic errors in the code

What are design flaws in software security?

• Subtle architectural problems requiring manual analysis
• Examples: authentication bypasses, privilege escalation paths
• Think of these as fundamental blueprint errors in a building's design

What three factors have increased software security risks?

• Increased Complexity: Modern apps have millions of lines of code
• Increased Extensibility: Plugin architectures and rapid deployment cycles
• Increased Connectivity: Internet eliminates need for physical access

What is the semantic gap problem in OS security?

Operating systems cannot enforce application-specific policies because they cannot understand the semantic meaning of application data and business logic.

Why are firewalls limited for software security?

• Firewall filtering is coarse-grained
• Port 80 assumed benign but can carry malicious payloads
• IDS patterns can be bypassed by modifying attack traffic
• Performance vs precision tradeoff limits detailed filtering

What was the Heartbleed vulnerability?

A buffer over-read vulnerability in OpenSSL versions 1.0.1 through 1.0.1f that allowed attackers to read server memory in 64k chunks, potentially exposing passwords, private keys, and sensitive data.

Why did traditional security fail against Heartbleed?

• OS Security: Problem wasn't at system call level
• Firewalls: Attack traffic appeared as normal SSL on port 443
• Anti-virus: No malicious files were created or downloaded
• The vulnerability was in legitimate, trusted library code

What is Principle 1: Earn or Give, But Never Assume, Trust?

Trust must be explicitly established and maintained, never assumed. Validate all data from untrusted sources and never perform authorization or access control in client code.

What is Principle 2: Use Authentication That Cannot Be Bypassed?

Authentication must be robust and consistently applied across all access paths. Prevent identity changes without re-authentication and avoid alternate authentication paths that bypass main security.

What is Principle 3: Authorize After Authentication?

• Authentication (who you are) and authorization (what you can do) are separate steps
• Both must occur explicitly
• Don't assume authorization automatically follows authentication

What is Principle 4: Strict Separation Between Data and Code?

Never allow untrusted data to be executed as code. Use parameterized interfaces, validate input data, and avoid injection-prone APIs like system() or eval().

What is SQL injection?

When user input like '

DROP TABLE users

-- is concatenated directly into SQL queries, turning data into executable code and allowing attackers to manipulate database operations.

What is Principle 5: All Data Are Explicitly Validated?

• Every piece of input data must be validated
• Use whitelisting instead of blacklisting
• Use centralized validation mechanism
• Make security review of validation scheme possible

What are point-to-point vs canonical mappings?

• Point-to-point: Each system connects directly to multiple others (N×(N-1) connections)
• Canonical: All systems connect through central standardized format (2N connections)
• Canonical approach provides single point of validation and consistency

What is Principle 6: Use Cryptography Correctly?

• Use standard, well-tested algorithms and libraries
• Don't implement your own cryptographic algorithms
• Consult with cryptography experts
• Design for crypto agility (ability to change algorithms)

What does "don't roll your own crypto" mean?

• Don't invent new encryption algorithms
• Don't implement known algorithms yourself
• Don't misuse cryptographic libraries
• Use established libraries and protocols instead

Why do smart people make crypto mistakes?

• Expertise illusion: Developers think crypto is just another technical problem
• Testing problem: Can't unit test cryptographic security properties
• Crypto requires specialized knowledge about mathematical attacks and adversarial models

What is Principle 7: Identify and Protect Sensitive Data?

• Classify data into sensitivity categories
• Implement appropriate controls for each category
• Consider context-dependent sensitivity
• Protect data confidentiality, integrity, and availability

What is Principle 8: Always Consider the Users?

• Security systems must be usable by real humans
• Make systems secure by default
• Don't make users responsible for critical security decisions
• Design security that doesn't impede legitimate use

What is Principle 9: Correctly Integrate External Components?

• Third-party components inherit their security properties into your system
• Security test all external components
• Include dependencies in security reviews
• Monitor public security information about components

What is Principle 10: Be Flexible for Future Changes?

• Security systems must adapt as threats evolve
• Design for change and updates
• Use code signing and integrity protection
• Plan for crypto algorithm obsolescence and secret compromise recovery

What are the main categories of software security approaches?

• Do nothing (ignore security)
• Ad-hoc evaluation (occasional reviews)
• Add security features after the fact
• Identify vulnerabilities in existing code
• Test security levels
• Incorporate security throughout SDLC (best approach)

What is the difference between correctness and security testing?

• Correctness testing: Verify software does what it should under expected conditions
• Security testing: Verify software doesn't do what it shouldn't under ALL possible conditions
• Security testing is inherently more difficult and comprehensive

When was Heartbleed introduced and discovered?

• December 31, 2011: Flawed code introduced into OpenSSL
• March 14, 2012: Released in OpenSSL 1.0.1
• April 1, 2014: Privately reported by Google's Neel Mehta
• April 7, 2014: Public disclosure and patch release

What was the scale of Heartbleed's impact?

• 17% of all secure web servers affected (around 500,000 sites)
• Included major services like Yahoo
• Vulnerability existed undetected for over 2 years
• Recovery was slow: 309,000 servers still vulnerable by June 2014

What could attackers steal using Heartbleed?

• User passwords and session cookies
• Private encryption keys
• Internal system data and communications
• Any sensitive information in server memory
• Could retrieve up to 64k of memory per attack, repeatedly

How was Heartbleed discovered?

Two independent discoveries:
• Google's Neel Mehta: Line-by-line code audit
• Codenomicon: Penetration testing and attack simulations
• Both found it within weeks despite 2 years of existence

What was the root cause of Heartbleed?

A missing bounds check in the TLS heartbeat extension. The code copied data without verifying the claimed data length, allowing attackers to read arbitrary server memory beyond the intended data.

What are examples of established cryptographic libraries?

• OpenSSL: Most widely audited crypto library
• libsodium: Designed to prevent misuse
• Bouncy Castle: Comprehensive library for Java/.NET
• Platform-specific libraries like Apple's CommonCrypto

What are examples of established cryptographic protocols?

• TLS 1.3 for network communication
• Signal Protocol for messaging applications
• OAuth 2.0 for authentication delegation
• JOSE (JSON Web Encryption) for web-based cryptography

What is crypto agility?

The ability to change cryptographic algorithms without rebuilding the entire system. Includes using algorithm identifiers in data formats and planning for key rotation and algorithm migration.

What are the three levels of "rolling your own crypto"?

• Level 1: Inventing new algorithms
• Level 2: Implementing known algorithms yourself
• Level 3: Misusing established cryptographic libraries

What are common cryptographic implementation mistakes?

• Timing attacks: Implementation takes different time for different inputs
• Side-channel attacks: Power consumption leaks secret information
• Using ECB mode instead of CBC mode
• Reusing initialization vectors
• Not authenticating encrypted data

What made WEP vulnerable?

• Reused initialization vectors
• Flawed key scheduling algorithm
• Same key used for authentication and encryption
• Result: WEP can be broken in minutes

When might rolling your own crypto be justified?

• Research contexts developing new techniques
• Extreme performance requirements
• Novel threat models not addressed by existing crypto
• Even then: requires cryptographic experts and extensive peer review

What properties can't be easily tested in cryptography?

• Semantic security: Encrypted data shouldn't reveal anything about original
• Forward secrecy: Compromising today's keys shouldn't compromise past communications
• Non-malleability: Attackers shouldn't modify encrypted data meaningfully

What is the business case for using established crypto?

• Development speed: Faster than implementing yourself
• Legal protection: Demonstrates due diligence
• Maintenance burden: Experts handle ongoing security updates

What are key security engineering roles?

• Programmer: Source code properties
• System Integrator: Combining components securely
• Security Analyst: Understanding defect properties
• System Administrator: Managing system security
• Vulnerability Analyst: Analyzing deployed system vulnerabilities

What is the relationship between source code and security?

Source code → Software components → Programs → Computer systems → Networks
Security flaws → Vulnerabilities → Exploits → Mitigations
Each role focuses on different stages of this pipeline

Which CIA objectives does software security address?

All three with emphasis on:
• Integrity: Preventing unauthorized modification
• Confidentiality: Preventing unauthorized access
• Availability: Ensuring services remain accessible
Relative importance depends on application context

What is the client-side security fallacy?

Assuming you can trust code running on user devices. Attackers control their own devices completely and can modify apps, intercept traffic, or run applications in debuggers

What is the confused deputy problem?

When successful authentication is incorrectly assumed to grant authorization for all actions. Each sensitive operation needs explicit authorization checks beyond just authentication

What is the weakest link principle in integration?

Your application inherits the security vulnerabilities of every component you integrate. A vulnerability in a minor library can compromise your entire system

What is the password paradox in usable security?

Security policies requiring complex passwords often lead users to write them down or reuse variations, making the system less secure than simpler systems users follow correctly

What are the characteristics of good security validation?

• Use whitelisting (define good inputs) instead of blacklisting (list bad inputs)
• Create centralized validation that all input must pass through
• Make validation logic reviewable and maintainable
• Handle all edge cases and boundary condition