DashboardModulesSecurity Fundamentals
MODULE 01

Security Fundamentals

Master the foundations of secure software development by learning to identify security requirements from multiple sources (compliance, users, platforms), understand the attacker mindset and attack surface analysis, find common vulnerabilities in code, and leverage threat intelligence resources like NVD, CVE, CVSS, and the OWASP Top 10:2025.

5 hours 30 minutes
4 Topics
Exam Weight: 20%

Learning Objectives

  • Identify and document security requirements from user expectations, compliance standards (PCI DSS, HIPAA, GDPR), platform requirements, and organizational policies
  • Understand the CIA Triad (Confidentiality, Integrity, Availability) and AAA (Authentication, Authorization, Accounting) frameworks
  • Recognize factors that undermine software security including the builder vs. breaker mindset, attack surface analysis, and the Cyber Kill Chain phases
  • Classify threat actors (white hat, black hat, nation-state, insider) and understand their motivations, capabilities, and typical attack patterns
  • Find common vulnerabilities in software including injection flaws, authentication weaknesses, cryptographic failures, and third-party dependency risks
  • Apply secure coding practices for password hashing, input validation, SQL injection prevention, and XSS mitigation
  • Gather threat intelligence using NVD, CVE, CVSS scoring, OWASP Top 10:2025, CWE, and security advisories
  • Implement automated vulnerability monitoring and establish a continuous threat intelligence program

Topics

TOPIC 1A

Identify Security Requirements and Expectations

Understanding the various sources of security requirements including user expectations, compliance standards, platform requirements, and how to document them effectively in software specifications. This topic covers the foundation of building secure software by establishing clear security goals from the start.

1 hour
  • User Requirements and Privacy Expectations: Users expect their data to be protected, their privacy respected, and their interactions secure. Understanding explicit vs. implicit security expectations is crucial for building trust.
  • Standards and Compliance Requirements: PCI DSS (Payment Card Industry Data Security Standard) for payment processing, HIPAA (Health Insurance Portability and Accountability Act) for healthcare data, GDPR (General Data Protection Regulation) for EU citizen data, SOX (Sarbanes-Oxley) for financial reporting, and FERPA for educational records.
  • Platform and Cloud Provider Requirements: AWS, Azure, and GCP each have shared responsibility models. Understanding what security the provider handles vs. what you must implement is critical for cloud-native applications.
  • Organizational Security Policies: Internal security policies, acceptable use policies, data classification schemes, and security governance frameworks that guide development practices.
  • Non-Functional Security Requirements (NFRs): Performance under attack (DDoS resilience), availability targets (99.9% uptime), recovery time objectives (RTO), and recovery point objectives (RPO).
  • Security in Software Requirements Specifications (SRS): Documenting security requirements alongside functional requirements using structured formats like IEEE 830 or agile security stories.
  • The CIA Triad Foundation: Confidentiality (protecting data from unauthorized access), Integrity (ensuring data accuracy and trustworthiness), Availability (ensuring systems are accessible when needed).
  • Authentication, Authorization, and Accounting (AAA): The three pillars of access control that must be defined early in requirements gathering.
  • Data Classification Levels: Public, Internal, Confidential, and Restricted data categories with corresponding protection requirements.
  • Regulatory Landscape by Industry: Financial services (GLBA, SOX), Healthcare (HIPAA, HITECH), Retail (PCI DSS), Government (FISMA, FedRAMP), and Education (FERPA).

Security Requirements Template

Template for documenting security requirements in an SRS

markdown
# Security Requirements Specification

## 1. Authentication Requirements
- REQ-SEC-001: System SHALL support multi-factor authentication
- REQ-SEC-002: Passwords SHALL meet complexity requirements:
  - Minimum 12 characters
  - At least one uppercase, lowercase, number, special char
- REQ-SEC-003: Session timeout SHALL be 30 minutes of inactivity

## 2. Authorization Requirements
- REQ-SEC-010: System SHALL implement role-based access control
- REQ-SEC-011: Principle of least privilege SHALL be enforced
- REQ-SEC-012: All access attempts SHALL be logged

## 3. Data Protection Requirements
- REQ-SEC-020: PII SHALL be encrypted at rest using AES-256
- REQ-SEC-021: Data in transit SHALL use TLS 1.2 or higher
- REQ-SEC-022: Encryption keys SHALL be rotated annually

## 4. Compliance Requirements
- REQ-SEC-030: System SHALL comply with GDPR Article 25
- REQ-SEC-031: Payment data SHALL meet PCI DSS Level 1

Security User Story Format

Agile security user story examples

markdown
# Security User Stories (Agile Format)

## Evil User Stories (Abuse Cases)
AS A malicious user
I WANT TO perform SQL injection attacks
SO THAT I can access unauthorized data
MITIGATION: Parameterized queries, input validation

## Security User Stories
AS A registered user
I WANT my password to be securely stored
SO THAT my account cannot be compromised if the database is breached
ACCEPTANCE CRITERIA:
- Passwords hashed with bcrypt (cost factor 12+)
- Unique salt per password
- No plaintext password logging

AS A system administrator
I WANT to receive alerts on suspicious activity
SO THAT I can respond to potential security incidents
ACCEPTANCE CRITERIA:
- Alert on 5+ failed login attempts
- Alert on access from new geographic location
- Alert on privilege escalation attempts
  • Start with a security requirements workshop involving developers, security team, legal, and business stakeholders to capture all perspectives
  • Use the OWASP ASVS as a checklist to ensure comprehensive coverage of security requirements
  • Document both functional security requirements (what the system must do) and non-functional requirements (how well it must do it)
  • Create security acceptance criteria for every user story that handles sensitive data or critical functions
  • Map compliance requirements to specific technical controls early to avoid costly retrofitting
  • Consider data residency requirements - where data can be stored and processed geographically
  • Include security requirements for third-party integrations and APIs
  • Define security SLAs (Service Level Agreements) for incident response times and system availability