ISC2 Information Systems Security Engineering

How you build shapes when security can act. You compare sequential, iterative and agile life cycles, place security work in each, and apply the design principles that guide choices throughout the system’s life.

• Waterfall, V-model, iterative and agile life cycles
• Where security decisions fall in each model
• Security design principles in engineering practice
• Modularity, layering and minimizing trust
• Penetration resistance and failure behavior
• Tailoring processes to project size and risk

You build A tailored security engineering plan for one life cycle model, with each activity and its output.

Risk changes at every stage, and so do the choices it drives. You assess risk at the system level, treat it with engineering choices rather than paperwork, and monitor it as the design and environment change.

• System-level risk assessment methods
• Threats, vulnerabilities and adversary capability
• Loss scenarios and consequence analysis
• Treating risk through design, not only controls
• Linking engineering risk to the risk management framework
• Tracking risk as the system changes

You build A system risk assessment with treatment options traced to design decisions.

Requirements are where security engineering earns or loses its place. You gather stakeholder needs, derive security requirements, resolve conflicts with performance and cost, and keep every requirement traceable.

• Stakeholder needs and the concept of operations
• Deriving security requirements from needs and risk
• Constraints from policy, law and the operating environment
• Resolving conflicts between requirements
• Requirements that can be verified
• Traceability from need to test

You build A security requirements set with a traceability matrix back to stakeholder needs.

Security work needs its own plan, budget and checkpoints. You plan activities, roles and reviews, decide how evidence will be gathered, and write the security plan that the project team can follow.

• Security engineering management plan
• Scheduling security reviews and decision gates
• Staffing, skills and independence of review
• Planning evidence collection from the start
• Interfaces and interconnection agreements
• Documenting security in the system plan

You build A security engineering plan with milestones, reviews and an evidence strategy.

Requirements become structure in design. You allocate security functions to components, run trade studies when requirements pull in different directions, and design interfaces and boundaries so that failures stay contained.

• Allocating security requirements to system elements
• Defense in depth within the system boundary
• Trade studies and design alternatives
• Secure interface and interconnection design
• Trust boundaries and containment of failure
• Design documentation and review

You build A security architecture and trade study for one subsystem, with the rationale for the chosen design.

Design intent can be lost between drawings and delivery. You oversee implementation, secure configuration and integration, manage acquired components and the supply chain, and run developer-level testing.

• Implementation oversight and secure configuration
• Integrating components and checking interfaces
• Acquisition and supply chain risk in components
• Developmental testing of security functions
• Configuration control during integration
• Recording as-built security documentation

You build An implementation and integration checklist with as-built records for one system.

Verification asks whether each requirement was met. You choose among inspection, analysis, demonstration and test, write verification plans, run them, and keep the evidence that a reviewer will ask for.

• Verification methods: inspection, analysis, demonstration, test
• Writing test procedures from requirements
• Test environments and their limits
• Handling failures and deficiencies
• Evidence retention and traceability
• Preparing verification results for review

You build A verification plan and results record for ten security requirements.

A system can meet every requirement and still not meet the need. You validate against stakeholder intent, support independent assessment and authorization, and decide whether a system is ready to go into operation.

• Validation compared with verification
• Operational scenarios and mission-based validation
• Independent test and evaluation
• Supporting an authorization decision
• Acceptance criteria and conditional acceptance
• Residual risk at handover

You build A validation plan and acceptance report that supports an authorization decision.

Security erodes through ordinary change. You support operations with monitoring and configuration control, run vulnerability management, analyze the security impact of every change, and keep the engineering record current.

• Handover from engineering to operations
• Configuration management and baselines
• Security impact analysis for change requests
• Vulnerability and patch management
• Monitoring and ongoing assessment
• Upgrades, technology refresh and re-engineering

You build A change control procedure with a security impact analysis template, tested on three sample changes.

The last stage of a system is the one most often forgotten. You plan transition and archiving, sanitize data and media, deal with residual data in components and suppliers, and close out access and records.

• Disposal planning from the start of the life cycle
• Data sanitization and media destruction
• Residual data in components, firmware and cloud
• Transition of data and function to a successor
• Closing accounts, keys and interfaces
• Final records and lessons learned

You build A disposal plan for one system, with a sanitization record and closeout checklist.

Follow a single system through every stage of its life. You make the engineering choices at each handoff, keep the evidence trail unbroken and defend the result as you would to a program review.

• Framing the system, stakeholders and risk
• Requirements, design and planning
• Implementation, verification and validation
• Operations and change control
• Disposal and lessons learned
• Presenting the engineering record

You build A complete security engineering record for a sample system, from needs to disposal.