IE4042 - SSE
Lecture 02
Secure Software Architecture Concepts
Ayesha Wijesooriya
Secure Software Architecture Design
•Planning
Define security goals early (confidentiality, integrity, availability).
Identify potential threats and risks (threat modeling).
Choose technologies, frameworks, and tools that support secure development.
•Forecasting
Predicting future security threats or vulnerabilities (e.g., new types of malware or attack vectors).
Building forward-compatible designs that can adapt to new technologies (e.g., AI, IoT integration).
Planning for scalability, expecting changes in the number of users, data volume, or integration needs.
•Flexible
Easy integration of new security controls
Support for change requests from stakeholders without breaking the whole system
Allowing multiple deployment environments
•Practical
Aligns with budget, timeline, and resource availability.
Ensures the design can be implemented and maintained by the development team.
Secure Software Architectre Concepts
•Defense in Depth
•Resiliency
•Leverage Existing components
Risk
System will be attacked,
01. Intentionally
Hackers trying to exploit vulnerabilities
02. Accidentally Solution - Build resilient system
Human errors How to build Resilient System?
Hardware failures
Software bugs
Operatinal Risk
•Understand Operational Risk
- real world
- Capacity
user experience level
volume of users & transactions
cancelled transactions Requirments for : memory/storage
unrealiable enviorments CPU
network bandwith
- future funtionality power
Integration
•Legacy Systems and data •Upstream and Downstream Connections
Wrapping them with secure APIs Secured with encryption (e.g., HTTPS,
Encrypting data during transmission TLS)
Validating and sanitizing inputs and outputs Validated to prevent injection or tampering
Audited to ensure proper data flow and
•Network Resilience logging
•Speed
•encryption
Design Security Concepts
•Least Privilege
•Speration of Duties
•Defense in Depth
•Fail Secure
•Economy of Mechanisums
•Complete mediation
•Open Design
•Least Common mechanisms
•Psychological acceptability
•Weakest link
Leveraging Existing Components
1. Least Privilege
Each user, process, or system component should have only the minimum access
necessary to perform its function.
2. Separation of Duties
Responsibilities should be divided among multiple roles or people so that no one
individual has full control over a critical process.
3. Defense in Depth
Use multiple layers of security (e.g., firewalls, encryption, authentication).
If one layer fails, others still provide protection.
4. Fail Secure
When the system fails, it should default to a secure state, not an open or vulnerable one.
5. Economy of Mechanisms
Design systems with simplicity. Fewer, well-understood mechanisms are easier to test, support , secure, and
maintain.
6. Complete Mediation
Every access to every resource must be checked for proper authorization. •All acccess request from a subject
to an oblect should be MEDIATED.
•Coookies
•Cache
•Session Mgt
7. Open Design
The system’s security should not depend on secrecy of its design or implementation.
Only the keys or passwords should be secret. • Cryptographic Algorithm /Open Softwares
8. Least Common Mechanism
Minimise the use of shared components among users or processes to prevent information
leakage or unintended interactions.
•Support defense in depth and resilience
•Isolation
•Compartmentalization
9. Psychological Acceptability
Security mechanisms should be easy for users to understand and use correctly.
10. Weakest Link
Your system is only as secure as its most vulnerable component.
11. Leveraging Existing Components
Use trusted, tested, and secure components (libraries, frameworks, tools) instead of
creating new ones from scratch.
Input Validation Transaction Controls
•Allowable Characters •Limit Checks
•Range Greater control when higher risk
•Buffer Overflow •Reasonableness checks
•Incomplete Fields anti-fraud
•Databases – referential Integrity
Software Protection
•Protect:
Software
API
Drivers
Utilities
compiler
Operating Systems
Third Party services
•Security of Third party
Contracts
Service level Agreements (SLAs)
Third Party audit
Liasion
How to build a resilient Software
Fail secure
•Fail hard - The system completely shuts down or denies all access when it encounters a failure.
Ensures maximum security.
•Fail soft - The system continues to operate in a limited or degraded mode, prioritizing
availability over full security.
•Fail safe - The system defaults to a safe condition — meaning no harm to users, system, or
environment, even if functionality is lost.
Leverage Existing Components
•Allocation of all security requirments
•Cration of security Plan
used for testing, audit and system authorisation.
Examples – access control
SSO
Pasworld Vaults
- Network
- Physical Security
- Employees
- Cloud
Thank You
Q&A
