Secure Software

Design
Introduction
• ONE OF THE MOST IMPORTANT phases in the SDLC is the design
phase. During this phase, software specifications are translated into
architectural blueprints that can be coded during the implementation
(or coding) phase that follows.
Topics
• Design Processes
• Design Considerations
• Architecture
The Need for Secure Design
• Resilient and recoverable software
• Quality, maintainable software that is less prone to errors
• Minimal redesign and consistency
• Business logic flaws addressed
Architecting Software with Core Security
Concepts
• Confidentiality Design
• Integrity Design
• Availability Design
• Authentication Design
• Authorization Design
Architecting Software with Secure Design
Principles
• improper implementation of least privilege.
• Software fails insecurely.
• Authentication mechanisms are easily bypassed.
• Improper error handling.
• Weak input validation.
Least Privilege
Only the necessary and minimum level of access rights (privileges) has
been given.
• Separation of Duties
• Defense in Depth
• Disallowing dynamic query constructions using user
input to defend against injection attacks.
• Disallowing active scripting in conjunction with output encoding
and input- or request-validation to defend against Cross-Site
Scripting (XSS).

• Fail Secure
• Economy of Mechanisms
Design Processes
• Attack Surface Evaluation
• A software or application’s attack surface is the measure of its exposure of being
exploited by a threat agent.

• Threat Modeling
• Threats to software are manifold. They range from disclosure threats against
confidentiality to alteration threats against integrity to destruction threats against
availability, authentication bypass, privilege escalation, impersonation, deletion
of log files, man-in-the-middle attacks, session hijacking and replaying, injection,
scripting, overflow and cryptographic attack
Threat Modeling
• Benefits
• design flaws can be addressed before a single line of code is written.

• Challenges
• Can be a time-consuming process when done correctly.
• Requires a fairly mature SDLC.
• Requires the training of employees to correctly model threats and
address vulnerabilities.
• Is often deemed to not be a very preferential activity. Developers
prefer coding and quality assurance personnel prefer testing over
threat modeling.
• Is often not directly related to business operations and it is difficult
to show demonstrable return on investment for threat models.
Threat Modeling Process
Model Application Architecture
• Identify the Physical Topology.
• Identify the Logical Topology.
• Identify Human and Non-Human Actors of the System.
• Identify Data Elements.
• Generate a Data Access Control Matrix.
Identify Threats
• Identify Trust Boundaries
• Identify Entry Points
• Identify Exit Points
• Identify Data Flows
• Attack Trees
• Identify, Prioritize and Implement Controls
• Document and Validate
Architectures
• Mainframe Architecture
• Distributed Computing
• Cloud Computing
• Mobile Applications