CISSP 20.1 - Introducing Systems Development Controls (Part 2 of 5)

This episode of the ISC2 Certified Information Systems Security Professional (CISSP) exam prep series continues Domain 8 by shifting from language choices to the practical safeguards that keep running software from failing dangerously. It examines input handling, failure behavior, and the discipline of a formal life cycle, so an application stays resilient rather than becoming an attacker’s roadmap.

Frequently Asked Questions

How do you stop bad input from breaking a program?

You validate it. Input validation checks that whatever a user submits matches what the code expects before anything acts on it, using rules like a limit check that insists a month be a whole number from one to twelve. It scans for suspicious characters and can neutralize risky sequences by escaping them. The rule you never break is to validate on the server, because anything running in the browser can be tampered with.

How should applications handle authentication and sessions?

Match the strength of the login to the sensitivity of what lies behind it, giving sensitive applications strong multi-factor authentication rather than just a password. Wherever possible, plug into the organization’s existing hardened identity system rather than inventing your own. Sessions need the same care: any cookie that tracks a session should travel only over encrypted channels, carry a long random identifier, and expire after a set time.

What do error messages reveal, and to whom?

Developers love verbose errors because they make debugging painless, but those same messages can hand an attacker an internal map, leaking database table names, internal server addresses, and other reconnaissance detail. On anything publicly reachable, switch off detailed error output, often called debugging mode, and show users only a bland, safe message. The valuable detail should not vanish, though, because it belongs in your logs.

When software fails, should it lock down or open up?

You must decide this in advance. A fail-secure state throws the system into a high-security posture, or shuts it down entirely, until an administrator can investigate and restore it. A fail-open state lets users slip past the broken control and errs toward permissiveness. In almost every environment fail-secure is the right default, because it blocks unauthorized access when things go wrong, as a desktop crash screen halts rather than run in an untrusted state.

How does a formal life cycle guide the early phases of a build?

A formal life cycle embeds good practice and security into every stage. It begins with a conceptual definition, a short concept statement all stakeholders agree on, then functional requirements determination, whose document captures each requirement’s inputs, behavior, and outputs. A control specifications phase analyzes the system through a security lens, building in access controls, encryption, and audit trails, and design review confirms the design honors those control specifications.

Reference: This article is based on concepts discussed in CISSP 20.1 - Introducing Systems Development Controls (Part 2 of 5).