Secure Software Design

Lecture 2&3

Module 1!
Security Oriented
Modeling
Security Requirements:
Security Requirements:

Shall not
Should not
Could not
Will Not
Must not
 Functional Security Requirements:

Directly implement security functionalities

Category Security Functional Requirement

Authentication The system must require a
username and password to log in.
The system must log all failed login
Logging
attempts.
Session Management Users must be logged out after 15
minutes of inactivity.
 Nonfunctional Security Requirements:

•Define quality attributes of security controls

•Focus on performance, resilience, compliance, and usability
•Ensure security features work efficiently, effectively, and reliably

The system must process 1000 authentication

Performance
requests per second.
The application must have 99.99% uptime for
Availability
security services.
The system must comply with GDPR, ISO 27001, or
Compliance
PCI DSS.
Users should not require more than 3 steps to
Usability
reset their password.
The system must withstand 10,000 failed login
Resilience
attempts per hour.
Security Requirements:
Security Requirements:
Requirements
You can also write
Example: with out should not
Security Requirements
Example:
 Security Design Principles
1. Principle of least privilege
2. Principle of fail-safe defaults
3. Principle of economy of mechanism
4. Principle of complete mediation
5. Principle of open design
6. Principle of separation of privilege
7. Principle of least common mechanism
8. Principle of psychological acceptability
 1. Principle of least privilege
A subject/program should be given only
1 the minimum set of privileges necessary
to complete its task:

1. Entity should be given only those

privilege needed to finish a task.
2. Temporary elevation of privilege
should be abandoned immediately
3. Append permission only for logging
process.
System operator should not perform security administration
functions
Run server processes as their own users with exactly
the set of privileges they require
 2. Fail-Safe (permission based)
Defaults
2
Unless a subject is given explicit access to an
object, it should be denied access to that
object :
1. Basic access decisions are made on
permissions rather than exclusion.
2. Default action is to deny, not grant, access
3. If action fails, system as secure as when
action began

New file is accessible only to its creator - not world

On access request system must get the user ID.

 2. Sample Code
Consider the following general code for allowing
2 access to a resource:

a. Explain the security flaw in this program.

b. Rewrite the code to avoid the flaw.
 2. Solution

2
 3. Economy of Mechanism
3 Security mechanisms should be as simple as
possible

Keep the design, implementation, operation,

interaction with other components as simple as
possible, so that it can be analysed, verified, tested
 4. Open Design
4
The security of a mechanism should not depend on
the secrecy of its design or implementation. Key is
secret, algo should be open to public scrutiny
The design of TLS is publicly available and
open for scrutiny
This principle suggests that complexity does not
add security.
 5. Check every access
5

Every access to every object must be checked for authority

 6. Separation of Privilege
6 A system should not grant permission
based on a single condition:
Students can not access the details of
submission 1. Separation of duty :Functions are
The system should send a message divided so that one entity does not
when the user login the system
have control over all parts of a
Each User activity in android have its own transaction
virtual machine (sandbox)
2. Compartmentalization
(encapsulation):
A security violation in one process
should not affect others
 7. Least Common Mechanism
7 It focuses on minimizing the sharing of resources and
mechanisms between different services or components in
a system.
You have two different services, of different priorities and
value, provided to two different sets of users. The more
resources they share, the more likely one can influence the
other

The system should start registration software for student attendance

if teacher desire to switch
 8. Complete Mediation
8 Every access must to checked against access control mechanism.
System should not rely on access decisions are a cache.
Careful consideration be given to how changes in authority
are propagated in local memories

Whenever file is read, a data item in database must exercise

access control.
 9. Psychological acceptability
9 Should not interfere unduly with those who have authorized access.

Should be transparent to users, may be turned off or give

minimum obstructions.
If protection do not make sense to user, user is likely to make
errors

If a user has a valid login session, they should

be able to continue their work without
constant re-authentication or interruptions.
 10. Isolation
10
Public access systems should be isolated to critical systems.

No physical connection should exist. Process and files of

individual users should be isolated.
Modern OS provide isolated process space, memory space,
and file space

Logical access control provide means of isolating cryptographic

software from other parts for protecting from tempering and
disclosure.
 11. Encapsulation
11 Protection is provided by encapsulation a collection of
procedures and data objects in domain of its own.

So that internal structure of data object is accessible only to

the procedures of protected subsystem.

In object-oriented programming (OOP), the internal data of a

class is often marked as private, and only public methods
(getters/setters) are provided to interact with this data.
 12. Modularity
12
Development of separate and protected modules.

Example:In a web application, the authentication module handles user

login, while the payment module processes transactions. Each module is
independent and can be modified without affecting the others

Modules should be loosely coupled, meaning that they depend as little

as possible on one another. This reduces the risk that changes in one
module will require changes in other modules.

Modular architecture, security mechanism should support

migration to new upgraded features without requiring
redesign.
 13. Layering
13
Multiple protection approaches

Failure of one will not leave system unprotected

Defence in depth
 14. Least astonishment
14 Program or user interface should be designed in a way that is least
likely to astonish the user
Mechanism of authorization should be transparent enough to
user that user has a good intuitive understanding of how
security goals map to the provided security mechanism.
 Misuse Case
• Misuse case is a business process modeling tool used in the software development
industry.
• The term Misuse Case or mis-use case is derived from and is the inverse of use
case.
• Use cases specify required behavior of software and other products under
development, and are essentially structured stories or scenarios detailing the
normal behavior and usage of the software.
• A Misuse Case on the other hand highlights something that should not happen (i.e.
a Negative Scenario) and the threats hence identified, help in defining new
requirements, which are expressed as new Use Cases.
• A developer or designer can then define the requirements of the user and the
hacker in the same UML diagram which in turn helps identify the security risks of
the system.
 Why build misuse cases?
• You draw your teams attention to forms of attack.
• You get the team thinking about security issues
early in the project
• You make it more likely to prevent attacks
• Security becomes part of the functional
requirements
 OWASP guidelines for secure software
at usecases level
• security is integrated into the functional
requirements of software from the very beginning
 1. User Authentication
• Guideline: Implement strong authentication
mechanisms.
• Use Case: When users log into the application.
• Best Practices:
– Use multi-factor authentication (MFA) for added
security.
– Ensure passwords are stored using strong, salted
hashing algorithms (e.g., bcrypt).
– Implement account lockout after a predefined number
of failed login attempts to prevent brute-force attacks.
– Use secure password recovery mechanisms, avoiding
security questions that can be easily guessed.
 2. User Authorization
• Guideline: Enforce access controls consistently.
• Use Case: When users attempt to access different
resources or features.
• Best Practices:
– Implement role-based access control (RBAC) to restrict
user permissions based on their role.
– Validate permissions server-side, never trusting
client-side checks.
– Use least privilege principles, granting users the
minimum access necessary to perform their tasks.
– Regularly review and update permissions as user roles
and responsibilities change.
 [Link] Validation
• Guideline: Validate all inputs to prevent injection and
other attacks.
• Use Case: When accepting input from users, APIs, or
other sources.
• Best Practices:
– Implement input validation both on the client and server
sides.
– Use allowlist validation (permitting only known good data)
wherever possible.
– Sanitize input to remove potentially dangerous characters or
code.
– For SQL queries, always use prepared statements with
parameterized queries to avoid SQL injection.
 4. Session Management
• Guideline: Securely manage user sessions.
• Use Case: When users interact with the application
over multiple requests.
• Best Practices:
– Use secure, randomly generated session identifiers
(session IDs).
– Store session IDs in secure, HttpOnly cookies to prevent
access from JavaScript.
– Implement session timeout and logout mechanisms,
especially for sensitive applications.
– Use HTTPS to protect session data in transit and avoid
session fixation vulnerabilities.
 5. Error Handling and Logging
• Guideline: Implement secure error handling and logging
practices.
• Use Case: When errors occur or unusual activity is
detected.
• Best Practices:
– Display generic error messages to users while logging
detailed errors server-side.
– Ensure logs do not expose sensitive information, such as
passwords or credit card numbers.
– Monitor and alert on suspicious patterns in logs, such as
multiple failed login attempts.
– Use secure logging practices that ensure log integrity and
confidentiality, especially for sensitive logs.
 6. Data Encryption
• Guideline: Protect sensitive data using strong
encryption.
• Use Case: When storing or transmitting sensitive data.
• Best Practices:
– Use strong, industry-standard encryption algorithms (e.g.,
AES-256) for data at rest and in transit.
– Encrypt sensitive data before storing it in databases,
especially PII, financial information, and health data.
– Ensure that cryptographic keys are stored securely and
separately from the encrypted data.
– Implement TLS (Transport Layer Security) for all data
transmissions, ensuring certificates are valid and up to date.
 7. File Uploads
• Guideline: Securely handle file uploads to prevent
malicious files from being executed or processed.
• Use Case: When allowing users to upload files (e.g.,
images, documents).
• Best Practices:
– Restrict file types to only those that are necessary (e.g.,
allowlist approved file extensions).
– Validate and sanitize file names to prevent path traversal
attacks.
– Store uploaded files outside of the web root and serve them
via a secure mechanism.
– Scan uploaded files for malware before processing or storing
them.
 8. Cross-Site Scripting (XSS)
Prevention
• Guideline: Prevent XSS by sanitizing and escaping user
input.
• Use Case: When displaying user-generated content on a
web page.
• Best Practices:
– Escape user input before rendering it in HTML, JavaScript, or
other formats.
– Use Content Security Policy (CSP) to restrict the sources from
which scripts can be loaded.
– Implement proper output encoding based on the context
(e.g., HTML, URL, JavaScript).
– Validate and sanitize input to remove malicious scripts
before storing or displaying it.
 9. Cross-Site Request Forgery
(CSRF) Protection
•Guideline: Implement CSRF protection for state-changing
requests.
•Use Case: When performing actions that change data, such as
form submissions.
•Best Practices:
•Use anti-CSRF tokens that are unique to each user session
and included in forms and requests.
•Require re-authentication for critical actions (e.g., changing
passwords or email addresses).
•Validate the origin of requests using the Referer or Origin
headers, ensuring they come from your application.
•Implement same-site cookies to prevent cookies from
being sent with cross-site requests.
 10. API Security
• Guideline: Secure APIs by implementing robust
authentication, authorization, and input validation.
• Use Case: When exposing application functionality
through APIs.
• Best Practices:
– Use OAuth2 or another secure method for API authentication
and authorization.
– Implement rate limiting and throttling to protect against
denial of service (DoS) attacks.
– Ensure all API inputs are validated and sanitized to prevent
injection attacks.
– Encrypt API traffic using TLS to protect sensitive data.
 [Link] Software Update
Mechanisms
• Guideline: Ensure secure distribution and application of
software updates.
• Use Case: When providing patches or updates to users.
• Best Practices:
– Sign software updates with a cryptographic signature to
verify their authenticity.
– Use secure channels for distributing updates (e.g., HTTPS).
– Implement automatic updates with user consent to ensure
that critical patches are applied promptly.
– Validate update integrity before applying it to prevent
tampering.
 12. Handling Sensitive Data
• Guideline: Protect sensitive data throughout its
lifecycle.
• Use Case: When processing, storing, or transmitting
sensitive information (e.g., credit card numbers,
personal data).
• Best Practices:
– Minimize the storage and exposure of sensitive data; only
collect what is necessary.
– Use strong encryption for sensitive data at rest and in transit.
– Apply data masking or tokenization to reduce the risk of
exposure in non-production environments.
– Implement strong access controls to restrict who can view or
modify sensitive data.
 13. Secure Configuration
Management
• Guideline: Maintain secure configuration settings across
all environments.
• Use Case: When deploying and managing software in
production.
• Best Practices:
– Follow the principle of least privilege for all configuration
settings.
– Disable or remove unnecessary features, services, or
components.
– Regularly review and update configurations to align with the
latest security best practices.
– Monitor for and remediate configuration drift to maintain
security baselines.
 14. Logging and Monitoring
• Guideline: Implement robust logging and monitoring to
detect and respond to security incidents.
• Use Case: When tracking application activity and
responding to potential security breaches.
• Best Practices:
– Log all security-relevant events, including login attempts,
changes to sensitive data, and access to critical resources.
– Protect logs from tampering and unauthorized access.
– Implement real-time monitoring and alerting to detect
unusual behavior.
– Regularly review and analyze logs to identify potential
security issues.
 15. Third-Party Components
• Guideline: Manage third-party components to minimize
risks.
• Use Case: When using libraries, frameworks, or other
third-party software components.
• Best Practices:
– Regularly update third-party components to their latest
versions.
– Monitor for and address any vulnerabilities reported in
third-party components.
– Prefer well-maintained and widely used libraries to reduce
the risk of using vulnerable or unsupported code.
– Use software composition analysis (SCA) tools to identify and
manage third-party risks.
 16. Mobile Application Security

• Guideline: Ensure mobile applications follow secure

coding practices.
• Use Case: When developing or maintaining mobile apps.
• Best Practices:
– Use secure storage mechanisms for sensitive data (e.g.,
Keychain, Keystore).
– Implement strong authentication and session management
tailored for mobile environments.
– Secure communications using TLS and avoid relying on
client-side security checks.
– Regularly review and update mobile app security practices to
address emerging threats.
 17. Secure Deployment
• Guideline: Deploy software securely by following best
practices.
• Use Case: When deploying software to production
environments.
• Best Practices:
– Automate deployment processes to reduce human error and
improve consistency.
– Use environment-specific configurations to minimize
exposure in production.
– Perform security testing (e.g., penetration testing) before
deployment.
– Monitor deployment processes for any signs of compromise.
 18. Security Awareness and Training

• Guideline: Ensure all team members are aware of

security best practices.
• Use Case: When onboarding new developers or
regularly training existing staff.
• Best Practices:
– Provide ongoing security training for developers, testers, and
operations staff.
– Promote a security-first mindset within the organization.
– Keep teams updated on the latest security threats and
mitigation strategies.
– Encourage the adoption of secure coding practices across all
stages of development.
 19. Continuous Security Testing

• Guideline: Regularly test and validate security controls.

• Use Case: Throughout the software development and
deployment lifecycle.
• Best Practices:
– Implement continuous integration/continuous deployment
(CI/CD) pipelines with integrated security testing.
– Perform regular security assessments, including static
analysis, dynamic analysis, and penetration testing.
– Automate security testing to identify vulnerabilities early in
the development process.
– Remediate identified vulnerabilities promptly and retest to
ensure fixes are effective.
 20. Secure Software Lifecycle Management

• Guideline: Integrate security throughout the software

development lifecycle (SDLC).
• Use Case: Across all phases of software development,
from planning to decommissioning.
• Best Practices:
– Include security requirements during the planning and design
phases.
– Perform threat modeling to identify and mitigate potential
security risks early.
– Integrate security checks and balances at each phase of the
SDLC.
– Continuously monitor and improve security practices
throughout the software lifecycle.
 Graded task
• Discuss NIST and CERT guidelines at use-case levels
of the system ?