Secure Software Design: Basic Concepts
Application security has always been a concern, and we don’t spend enough time thinking about application and total systems security. CSSLP is a certification that ensures that security is considered at appropriate levels across the SDLC. The following concepts permeate all of material:
- Least Privilege: only the rights necessary to perform the task at hand
- Separation of Duties: completion of a task requires at least two actors
- Defense in Depth: multiple controls in place
- Fail Secure: reverting to a safe state on failure/error (e.g. no disclosure)
- Economy of Mechanisms: reduce the attack surface by simplicity of design
- Compete Mediation: actors are authorized in every request for an object
- Open Design: implementation is independent of design
- Least Common Mechanism: components/processes should not share resources
- Psychologically Acceptable: there is a buy-in to comply to controls
- Weakest Link: only as strong as…
- Leverage Existing Components: reduce the attack surface is minimized by not introducing redundant components
How are you applying these to your systems? Think about these layers and phases of the SDLC:
- Network Design: Physical and Logical Topology
- Software Architecture
- Software Implementation
- Quality Assurance
- Deployment
- Operations and Maintenance
Consider a fairly common enterprise architecture: JavaScript based RIA, with a n-tiered architecture, with multi-factor authentication, distributed over a zero-trust based network architecture (each tier in it’s own subnet). Without diving into too much detail, you can imagine
- defense in depth: multi-factor authentication, zero-trust topology
- complete mediation: the RIA probably includes an authorization model to enforce entitlements to features AND we probably include that same check on the server side. If this is an intranet application, a Next-Generation Firewall can be used to verify the identity to of the end user and enforce authentication prior to hitting the server
- fail secure: if the user has no entitlements they probably see nothing on the screen. Errors are handled on the server side with generic messages. Deployment shouldn’t error out and leave the software partially installed (e.g. without the authentication and authorization modules).
- least privilege: the application probably limits what the user can interact with. The server-process should be run in a special account with limited rights on the operating system
and so on…
Where do these items come into your software design? Are they provided in the functional specification or added as non-functional requirements? Are network and deployment getting focus when the software is in the design phase?
