CISSP 8.1 - Secure Design Principles (Part 1 of 3)

This episode of the ISC2 Certified Information Systems Security Professional (CISSP) exam prep series opens the secure design principles topic in Domain 3, building secure systems from the ground up. It examines why security belongs in design from day one, how subjects and objects interact, and the trust and configuration assumptions that quietly decide whether a system is safe.

Frequently Asked Questions

Why should security be part of design from day one?

Retrofitting protection onto a finished product is slow, costly, and leaky, like bolting locks onto a completed building. Secure-by-design guidance pushes three ideas: own your customers’ security outcomes so products ship safe by default, be transparent about flaws so the whole community improves, and drive security from the top with leaders accountable during development. Security becomes a business goal, not a late patch.

What is the difference between a subject and an object?

Every access request has two sides. The subject is the active side that asks for access, often a user but also a process, service, or whole organization. The object is the passive side being requested, like a file, printer, or database. These roles are not fixed. A service that is the object of one request can turn around and become the subject of the next, like a relay runner who receives the baton and then hands it on.

What makes transitive trust dangerous?

Transitive trust is the chain where if A trusts B and B trusts C, then A quietly ends up trusting C, even though A never vetted C directly. For example, if a worker cannot reach a blocked website, they may connect to an outside proxy or VPN that reaches the blocked site on their behalf, bypassing the control through a middleman. Any time you allow a bridge, you may inherit everything on the far side of it.

How do open and closed systems differ, and is open source the same thing?

A closed system uses private, unpublished specifications and mostly works with gear from one maker, while an open system follows shared industry standards and common interfaces, or APIs, so it plugs into many vendors. Open systems integrate easily but draw more attackers through predictable entry points. Open versus closed source is a separate idea about whether internal code is visible to the public, so read exam questions slowly because these terms sit one word apart.

Why should you never trust default settings?

Defaults are chosen to make installation painless and minimize support calls, not to make you secure, which is why so many devices ship with a known default password that attackers scan for. Treat every default as the worst possible option for your environment, then review and restrict each one deliberately. If you build products, document every setting so customers can harden intelligently instead of guessing.

Reference: This article is based on concepts discussed in CISSP 8.1 - Secure Design Principles (Part 1 of 3).