Secure by Design - Software Assurance

Vocabulary flashcards covering key concepts from the lecture notes on Secure by Design.

Secure by Design

An approach that treats security as a cross‑cutting concern integrated into design, not as an add‑on feature; aims to build security into the system from the start.

Cross-cutting concern

A concern that affects multiple parts of a system across its functionality, not confined to a single module.

Security as a concern vs. feature

Security should be treated as an overarching concern throughout development, not just a list of features to implement.

Billion Laughs attack

An XML-based attack that exploits entity expansion to create a huge memory footprint, illustrating risks of untrusted XML data.

CIA Triad

Confidentiality, Integrity, and Availability—the three core information security goals.

Confidentiality

Keeping sensitive information secret from unauthorized parties; e.g., protecting healthcare records.

Integrity

Ensuring information remains accurate and is changed only in authorized ways; e.g., election results not being manipulated.

Availability

Ensuring data and services are accessible when needed; e.g., emergency services knowing a fire location promptly.

Non-functional attributes

Qualities such as performance, security, maintainability, and usability that affect overall system quality.

Security-minded development

A mindset of consistently considering security throughout the software development process.

Design as conscious decision-making

Design involves deliberate choices about how a system is built, spanning code to architecture.

Design as guiding principle

Design acts as the overarching principle guiding both implementation and architectural decisions.

Traditional approach to software security

A view where developers are taught about vulnerabilities (e.g., XSS, OWASP Top 10) and rely on security experts and testers.

Explicit thinking about security

The idea that developers must constantly think about security during coding; can be problematic with competing goals.

Everyone should be a security expert

An unrealistic expectation that all developers become security experts.

Unknown vulnerabilities problem

Even with experts, not all potential vulnerabilities can be anticipated or countered.

Driving security through design

Shifting focus from reactive security measures to embedding security in the design process.

Secure by design advantages

Design-centered security aligns with developers’ interests, gives equal priority to business and security, enables non-security experts to write secure code, and often resolves bugs through domain focus.

Domain focus

Focusing on the domain helps solve many security issues implicitly and reduces design and security complexity.

Invariants

Constraints that must always hold for a domain object (e.g., valid usernames) to maintain security by design.

Data representation risk

Using overly generic types (like strings) for specific data (like phone numbers) can create security weaknesses.

XML parser configuration risk

Choosing XML parser settings without understanding security implications can introduce vulnerabilities; better to reject malicious XML before parsing.

Entity attacks

Attacks exploiting XML entities (e.g., Billion Laughs) to exhaust resources and compromise security.

Defense in depth

A layered security approach; secure by design promotes multi-layer protection.

Summary takeaway

View security as a concern, not a set of features; use design practices to guide secure solutions; design is central across levels.