Secure Software Engineering - 7-Chapter Cheat Sheet
Condensed guide based on the uploaded chapters (1-7)
1) Why Security Is a Software Issue
- Software runs critical infrastructure and services; ubiquitous connectivity expands the attack surface and risk.
- Secure SDLC practices reduce exploitable faults; fixing earlier in the lifecycle is far more cost-effective.
- Objectives: vulnerability-minimized, attack-resistant/tolerant/resilient software that continues correct operation under attack.
- Security touchpoints continue into deployment/operations: code reviews, security tests, strict configuration control, QA.
2) What Makes Software Secure
- Core properties: Confidentiality, Integrity, Availability, Accountability, Non-repudiation; influenced by dependability,
correctness, predictability, reliability, safety, size, complexity, traceability.
- Attack patterns (e.g., CAPEC) provide a formal attacker's view; use them to inform requirements, design, coding standards,
and tests.
- Assurance cases (claims-arguments-evidence) to plan, track, and communicate security assurance across the SDLC.
- Static analysis & code review: select rules guided by applicable attack patterns; customize rules to enforce org standards.
3) Requirements Engineering for Secure Software
- Quality requirements (security, reliability, safety, etc.) are often neglected; treat them explicitly and iteratively.
- Capture attacker perspective with misuse/abuse cases, attack trees; document architectural diagrams, assets/services.
- Risk assessment & prioritization: compare methods, pick one that fits constraints; maintain rationale and rankings.
- Translate what the system must NOT do into verifiable security requirements; revisit as business context changes.
4) Secure Architecture & Design
- Do architectural risk analysis iteratively: asset/threat identification, attack surface & trust boundaries, threat modeling.
- Use security principles & guidelines (least privilege, least common mechanism, complete mediation, reluctance to trust,
never assume secrets are safe, psychological acceptability).
- Leverage proven design & security patterns; pair them with attack patterns to select mitigations and reduce risk.
- Consult vulnerability taxonomies/references (CWE, CVE/NVD, BugTraq) and classify weaknesses to guide mitigations.
5) Secure Coding & Testing
- Security testing differs from traditional QA: think like an adversary; exercise negative behaviors and edge cases.
- Complementary strategies: white-box, black-box, and penetration testing; risk-based tests from misuse/abuse cases &
attack patterns.
- Prefer allow-list validation to block-lists; validate inputs and encode outputs; test mitigations for effectiveness.
- Testing can show presence of problems, not absence; retest fixes with the same rigor as original features.
6) System Assembly, Web Services & Identity
- Complex, distributed systems fail via interactions: cascading events, operational errors, and resource stresses.
- Web services risks: service-level (e.g., SQLi) + message-level (e.g., XML content threats); network firewalls alone are
insufficient - use content-aware controls where appropriate.
- Identity management: align policy and enforcement across diverse systems; treat identity as a first-class architectural
concern.
- Plan for failure: fault tolerance, reduced visibility, changing goals, and incremental integration impact security options.
7) Governance & Managing for More Secure Software
- Avoid the checklist/tool trap; scanners and SSO are not panaceas. Focus on improving attack resistance across activities.
- Enterprise Software Security Framework (ESSF): align WHO-WHAT-WHEN responsibilities across roles; grow
competencies over time.
- Risk Management Framework (RMF): identify & prioritize risks; design cost-effective mitigation strategies; fix & validate;
measure and report continuously; manage residual risk.
- Define adequate security relative to business risk tolerance; iterate via roadmaps (3-5 years to mature, show early wins).
Quick Implementation Checklists
- Requirements: document CIAAN goals; write misuse/abuse cases; rank/prioritize with clear criteria; keep traceability.
- Design: map assets, trust boundaries, entry points; record mitigation, residual risk, owner, metric; enable logging/audit.
- Code: enforce secure coding standards; automate static analysis per attack patterns; mandatory code reviews.
- Testing: combine positive & negative tests; develop risk-based suites across unit/integration/system; include pen tests.
- Assembly: threat-model integrations and messages; verify identity/SSO assumptions; deploy defense-in-depth controls.
- Governance: define ESSF roles/activities; run RMF as continuous loop; track metrics (likelihood, impact, severity,
mitigation coverage).
Cheat sheet generated for study purposes.