Secure, Private and Resilient Software Engineering

Introduction

Software engineering is not complete when a system performs its intended functions. A professional system must also protect information, resist misuse, preserve privacy, remain available under disruption, and recover within acceptable limits. Security, privacy, and resilience are therefore quality attributes that must be designed into the software life cycle rather than added after implementation.

Security protects systems and information against unauthorized access, alteration, disclosure, destruction, and disruption. Privacy concerns the fair and lawful handling of information about identifiable people. Resilience is the ability of a system or organization to continue providing important services during adverse conditions and to restore normal operation afterwards.

These concerns are strategic because a failure may cause financial loss, legal liability, safety risks, reputational damage, and loss of public trust. This chapter presents practical foundations for integrating threat modeling, secure design, identity controls, cryptography, vulnerability management, privacy by design, backup, recovery, and resilience into software development.

Learning Objectives

By the end of this chapter, students should be able to:

1. Distinguish security, privacy, availability, and resilience requirements.
2. Perform a basic threat-modeling exercise using assets, threats, vulnerabilities, and controls.
3. Apply secure design principles to software architecture and implementation.
4. Explain authentication, authorization, encryption, hashing, and key management.
5. Describe vulnerability management across the software life cycle.
6. Apply privacy-by-design principles to data collection and processing.
7. Explain backup, recovery, disaster recovery, and business continuity concepts.
8. Evaluate a system’s security and resilience using professional practices and suitable metrics.

1. Security, Privacy and Resilience as Quality Attributes

A functional requirement states what a system must do. A quality requirement states how well or under what conditions it must do it. Security and resilience requirements should be measurable where possible. Examples include:

• Only authorized clinicians may view a patient record.
• Passwords must never be stored in recoverable form.
• The service must restore critical operations within four hours of a major failure.
• Users must be able to request deletion of personal data where applicable.

The classic security objectives are confidentiality, integrity, and availability, often called the CIA triad. Confidentiality prevents unauthorized disclosure; integrity prevents unauthorized or accidental modification; availability ensures that authorized users can access services when required. Authenticity, accountability, and non-repudiation are also important supporting properties.

Privacy is broader than confidentiality. A system may keep data secret from outsiders yet still violate privacy by collecting unnecessary data, retaining it indefinitely, or using it for an unexpected purpose. Privacy therefore includes purpose limitation, data minimization, transparency, user rights, and responsible governance.

Resilience includes prevention, resistance, adaptation, response, recovery, and learning. It addresses not only cyberattacks but also hardware failure, human error, software defects, natural disasters, supply-chain disruption, and excessive demand.

2. Threat Modeling

Threat modeling is a structured method for identifying what can go wrong, why it might happen, and how risk can be reduced. It should begin during requirements and architecture work and continue as the system changes.

Important terms are:

• Asset: Something valuable, such as personal data, credentials, source code, money, or service availability.
• Threat: A possible cause of harm, such as phishing, malware, fraud, or equipment failure.
• Vulnerability: A weakness that can be exploited or triggered.
• Attack vector: The route or technique used to reach a target.
• Control: A safeguard that reduces likelihood, impact, or both.
• Risk: The possibility of harm arising from a threat exploiting a vulnerability.

A practical threat-modeling process is:

1. Define system scope and security objectives.
2. Identify assets and classify their sensitivity.
3. Draw a system context or data-flow diagram.
4. Identify trust boundaries and entry points.
5. Enumerate threats.
6. Estimate likelihood and impact.
7. Select and prioritize controls.
8. Record assumptions, owners, and residual risks.
9. Review the model after significant changes.

STRIDE is a useful mnemonic for threat discovery: spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. It is not a complete risk assessment, but it encourages systematic questioning. For example, an online payment service should ask whether an attacker can impersonate a customer, alter a transaction, deny having made a transaction, disclose payment data, overwhelm the service, or gain administrative privileges.

A simple risk matrix may classify likelihood and impact as low, medium, or high. Such ratings are qualitative and depend on evidence and organizational context. A numerical risk score can be useful for prioritization, but it should not create false precision. A low-probability event with catastrophic impact may deserve immediate treatment even if its arithmetic score appears moderate.

Threat Modeling Example

Consider a student portal containing names, grades, and fee information. Assets include student records, staff credentials, and availability of examination services. Entry points include the web interface, mobile application, password-reset function, and administrative API. Trust boundaries exist between the public internet, the application server, and the database.

Possible threats include credential theft, SQL injection, unauthorized grade modification, denial-of-service attacks, and accidental disclosure through insecure reports. Controls may include multifactor authentication for staff, parameterized database queries, role-based authorization, rate limiting, audit logging, encryption in transit and at rest, and tested backups. The model should document who owns each control and how its effectiveness will be verified.

3. Secure Design Principles

Secure design reduces the number and consequences of mistakes. Important principles include:

• Least privilege: Give each user, process, and service only the permissions required for its task.
• Separation of duties: Divide sensitive activities so that one person or component cannot complete an abuse-prone process alone.
• Fail-safe defaults: Deny access unless authorization is explicitly established.
• Complete mediation: Check authorization whenever access to a protected resource occurs, not only at login.
• Defense in depth: Use multiple independent safeguards, such as validation, authorization, monitoring, and network segmentation.
• Secure by default: Initial configurations should use protective settings.
• Minimize attack surface: Remove unnecessary ports, functions, dependencies, and privileges.
• Avoid security through obscurity: Secret design details should not be the primary protection; secrets such as keys must remain confidential.
• Economy of mechanism: Prefer simple designs that are easier to inspect and test.
• Psychological acceptability: Security controls should be understandable and usable; impractical controls encourage unsafe workarounds.

Input validation should use allowlists where feasible, enforce type and length constraints, and occur on the server. Output encoding helps prevent injection into browsers, documents, or commands. Parameterized queries should be used instead of constructing database commands by string concatenation. Error messages should assist legitimate operators without revealing secrets, internal paths, or exploitable details.

Secure architecture also requires isolation. Separate public-facing components from sensitive databases, restrict service-to-service communication, protect management interfaces, and treat third-party components as potential sources of risk. Zero-trust approaches avoid assuming that a network location automatically makes a request trustworthy; access is evaluated using identity, device, context, and policy.

4. Identity, Authentication and Authorization

Identification claims an identity; authentication verifies it; authorization determines what an authenticated identity may do; accounting records relevant activity.

Authentication factors generally belong to three categories: something known, such as a password; something possessed, such as a security key or authenticator device; and something inherent, such as a biometric characteristic. Multifactor authentication combines factors from different categories. Two passwords are not normally two independent factors.

Passwords should be long, unique, and protected against guessing and reuse. Systems should store password verifiers using a deliberately slow, salted, adaptive password-hashing function rather than plaintext or reversible encryption. A salt is a unique random value stored with the verifier; it prevents identical passwords from producing identical stored results and makes precomputed attacks less useful.

Authorization models include:

Authorization must be enforced on the server and at the resource level. Hiding a button in a user interface is not authorization. Insecure direct object references occur when a user changes an identifier and accesses another user’s resource without a proper authorization check.

Audit logs should record important authentication, authorization, administrative, and data-access events. Logs need reliable timestamps, protection against alteration, appropriate retention, and monitoring. They should not expose passwords, secret keys, or unnecessary personal data.

5. Cryptography and Key Management

Cryptography supports confidentiality, integrity, authentication, and non-repudiation, but it is not a substitute for sound access control. Encryption transforms plaintext into ciphertext using an algorithm and a key. Decryption reverses the transformation for an authorized party.

Symmetric encryption uses the same secret key for encryption and decryption. It is efficient for large data volumes but requires secure key sharing. Asymmetric cryptography uses a public key and a private key. It supports key establishment and digital signatures, but is generally more computationally expensive.

A cryptographic hash function produces a fixed-length digest from input data. A secure hash is designed to make it computationally difficult to find an input producing a chosen digest or to find two inputs with the same digest. Hashing is one-way in intended use; it is not encryption.

Message authentication codes provide integrity and authenticity when communicating parties share a secret. Digital signatures use a private key to sign data and a public key to verify the signature. Certificates bind public keys to identities through a certificate authority or another trust system.

Encryption in transit should use current, correctly configured secure protocols. Encryption at rest should protect databases, backups, portable devices, and sensitive files. Key management is often more difficult than selecting an algorithm. Keys require generation from suitable randomness, restricted access, rotation where appropriate, secure backup, revocation, and eventual destruction. Secrets should not be committed to source code or ordinary configuration files.

6. Vulnerability Management and Secure Development

A vulnerability is a weakness that may be exploited or cause harm. Vulnerability management is a continuing process rather than a one-time scan:

1. Maintain an inventory of applications, libraries, services, and owners.
2. Discover weaknesses through code review, dependency analysis, testing, scanning, and responsible reports.
3. Validate findings and assess exploitability and business impact.
4. Prioritize treatment according to risk, exposure, available controls, and required deadlines.
5. Remediate through patches, configuration changes, code fixes, compensating controls, or retirement.
6. Verify the fix and record evidence.
7. Monitor for newly disclosed issues and regression.

A secure development life cycle integrates security into requirements, design, coding, testing, deployment, and maintenance. Examples include security acceptance criteria, peer review, static analysis, dynamic testing, dependency pinning, secret scanning, software composition analysis, penetration testing, and security-focused operations monitoring.

Automated tools are valuable but imperfect. Static analysis can produce false positives and miss runtime weaknesses. Penetration testing samples possible attack paths and does not prove that a system is secure. Human review, threat modeling, and operational evidence remain necessary.

7. Privacy by Design and Responsible Data Governance

Privacy by design means considering privacy from the earliest stage and embedding safeguards into architecture, processes, and defaults. Core practices include:

• Collect only data needed for a defined purpose.
• State purposes clearly and avoid incompatible secondary use.
• Provide lawful, fair, and transparent processing.
• Keep data accurate and allow correction where appropriate.
• Establish retention periods and securely delete data when no longer required.
• Restrict access according to purpose and role.
• Protect data throughout its life cycle.
• Assess risks to individuals, especially for sensitive or large-scale processing.
• Provide mechanisms for applicable rights such as access, correction, portability, or deletion.

Data classification helps determine controls. Public information, internal information, confidential business data, and highly sensitive personal or regulated data should not receive identical treatment. Pseudonymization replaces direct identifiers with alternative values, but the data may remain personal if re-identification is possible. Anonymization aims to make identification no longer reasonably possible, but it is difficult to guarantee when datasets can be combined.

Privacy notices should explain what is collected, why it is used, with whom it is shared, how long it is retained, and how individuals can exercise relevant rights. Legal requirements vary by jurisdiction; engineers should work with legal, compliance, and data-protection specialists rather than assuming that a technical measure alone satisfies the law.

8. Backup, Recovery and Resilience

A backup is a separate copy of data or system state maintained so that information can be restored. Backups do not automatically provide resilience: they must be protected, monitored, and tested.

Recovery planning uses two important targets. The recovery time objective (RTO) is the maximum acceptable time to restore a service after disruption. The recovery point objective (RPO) is the maximum acceptable amount of data loss measured in time. For example, an RTO of four hours and an RPO of fifteen minutes mean the service should be restored within four hours and data loss should not exceed approximately fifteen minutes under the stated assumptions.

Common backup types include full, incremental, and differential backups. A full backup copies selected data; an incremental backup copies changes since the most recent backup of any type; a differential backup copies changes since the last full backup. Incremental backups can reduce daily storage and transfer requirements but may require a longer restoration chain.

Resilient systems use redundancy, health monitoring, graceful degradation, retry policies with limits, circuit breakers, capacity planning, failover, and tested restoration procedures. Redundancy without independence is misleading: two services depending on the same power supply, region, identity provider, or software defect may fail together.

A useful availability approximation for independent components in series is:

Here A_i is the availability of component i, and the approximation assumes component failures are independent and that all components are required. If a service depends on two components each with availability 0.99, the series availability is 0.99 × 0.99 = 0.9801, or 98.01%. Independence is a strong assumption; common-cause failures can make actual availability lower.

A disaster recovery plan should define roles, contact methods, dependencies, failover steps, data restoration, validation, communication, and return-to-normal procedures. Exercises should include technical recovery tests and decision-making practice. After an incident, a blameless review should identify contributing conditions and improvements.

9. Illustrative Case: A Regional Health Appointment Platform

Background

A regional health service operates a platform for appointment scheduling, clinician access, reminders, and billing. It processes personal and health-related information and must remain available during seasonal demand peaks.

Problem

An assessment finds shared staff accounts, excessive database privileges, unencrypted backups, outdated libraries, no tested recovery procedure, and logs containing full patient identifiers. The platform has experienced intermittent outages caused by database overload.

Analysis

Threat modeling identifies credential theft, unauthorized record access, ransomware, accidental disclosure, dependency compromise, and denial of service. High-value assets include patient records, appointment availability, billing data, and clinical trust. Privacy analysis finds excessive collection of reminder details and indefinite retention of old appointment data. Resilience analysis shows that the database is a single point of failure and that the stated four-hour recovery target has never been tested.

Approach and Solution

The organization introduces individual accounts and multifactor authentication for staff. Role-based permissions separate reception, clinical, billing, and administrative functions. Server-side authorization checks every record request. Backups are encrypted, access-controlled, monitored, and restored during scheduled exercises. The database is replicated, capacity-tested, and protected by connection limits and carefully designed indexes.

The development team establishes dependency inventory, automated vulnerability checks, code review, secret scanning, and a patch-priority process. Sensitive fields are minimized, retention rules are implemented, and logs use pseudonymous identifiers where operationally sufficient. Threat models and privacy impact assessments become release activities rather than occasional documents.

Outcome

The platform reduces unnecessary access, improves detection, and demonstrates restoration within the target time during an exercise. Availability improves after capacity and dependency changes. The organization also discovers that its recovery plan depends on an external identity provider, leading to an additional emergency access procedure and documented contingency.

Learning Points

Security, privacy, and resilience are interconnected. Strong encryption cannot compensate for excessive privileges; backups cannot compensate for untested restoration; and a recovery plan is incomplete if critical suppliers and identity services are ignored. Controls must be assigned, tested, monitored, and revised.

10. Governance, Ethics and Contemporary Practice

Security decisions affect people, not only machines. Excessive surveillance, discriminatory automated decisions, insecure defaults, and inaccessible authentication can cause harm. Ethical engineering requires proportionality, transparency, accessibility, and respect for human autonomy.

Organizations should define security ownership, risk acceptance authority, incident-reporting procedures, supplier requirements, secure coding standards, and audit responsibilities. Regulatory obligations may include breach notification, records protection, payment security, or sector-specific controls. Exact duties depend on jurisdiction and should be verified with authoritative guidance.

Artificial intelligence can assist anomaly detection, code review, vulnerability triage, and incident analysis. However, AI-generated code may contain vulnerabilities, reproduce insecure patterns, leak confidential prompts or training data, and create uncertain accountability. AI outputs require human review, testing, data governance, and approval controls. An AI system itself must also be threat-modeled for prompt injection, data poisoning, model theft, privacy leakage, and unsafe actions.

Best-Practice Checklist

Before release, a team should be able to show that it has:

• identified important assets, threats, trust boundaries, and residual risks;
• defined security, privacy, availability, RTO, and RPO requirements;
• enforced least privilege and server-side authorization;
• protected passwords, secrets, communications, stored data, and backups;
• inventoried dependencies and addressed important vulnerabilities;
• tested validation, logging, monitoring, failover, and restoration;
• minimized personal data and documented retention and access purposes;
• assigned control owners and incident responsibilities; and
• reviewed lessons from tests, incidents, and system changes.

Chapter Summary

Secure, private, and resilient software engineering treats protection and recovery as life-cycle responsibilities. Threat modeling identifies assets, trust boundaries, threats, vulnerabilities, and controls. Secure design applies least privilege, defense in depth, secure defaults, isolation, validation, and fail-safe behavior. Authentication verifies identity, authorization limits actions, and audit records support accountability. Cryptography protects confidentiality and integrity, but effective key management is essential.

Vulnerability management combines inventory, discovery, prioritization, remediation, verification, and monitoring. Privacy by design minimizes data, limits purpose and retention, supports transparency and individual rights, and considers risks throughout the data life cycle. Backups, RTO, RPO, redundancy, monitoring, failover, and tested recovery procedures support resilience. Finally, governance, ethics, supplier dependencies, and human review are necessary because technical controls operate within social, legal, and organizational contexts.

Key Terms

Authentication: Verification of a claimed identity.

Authorization: Determination of what an authenticated subject may do.

Availability: Accessibility of a system or information when required.

Backup: A separate copy retained for restoration.

Confidentiality: Protection against unauthorized disclosure.

Defense in depth: Use of multiple independent protective layers.

Encryption: Transformation of readable data into protected ciphertext using a key.

Hash function: Function producing a fixed-length digest from input data.

Integrity: Protection against unauthorized or inappropriate modification.

Least privilege: Granting only the permissions necessary for a task.

Multifactor authentication: Authentication using independent factor categories.

Privacy by design: Embedding privacy protection throughout system design and operation.

Recovery point objective: Maximum acceptable data loss expressed as time.

Recovery time objective: Maximum acceptable time to restore a service.

Resilience: Capacity to withstand disruption, continue important operations, and recover.

Risk: Possibility of harm resulting from threats and vulnerabilities.

Threat model: Structured representation of assets, threats, vulnerabilities, and controls.

Vulnerability: A weakness that may be exploited or triggered to cause harm.

Review Questions

Short Answer Questions

1. What are confidentiality, integrity, and availability?
2. Distinguish authentication from authorization.
3. Why should passwords be hashed rather than encrypted for storage?
4. Define RTO and RPO.
5. What is meant by data minimization?

Long Answer Questions

1. Explain a complete threat-modeling process for a web application.
2. Discuss how least privilege, defense in depth, and secure defaults work together.
3. Compare role-based and attribute-based access control, including suitable use cases.
4. Explain how vulnerability management should operate across the software life cycle.
5. Describe the relationship between privacy by design, data retention, and access control.

Analytical / Application Questions

1. A university portal allows students to view another student’s grades when they alter a URL identifier. Identify the vulnerability, explain the likely threat, and propose layered controls.
2. A service has an RTO of two hours but has never restored a backup. Analyze why the stated resilience requirement has not been demonstrated and design a suitable test.
3. A company wants to collect precise employee locations continuously to improve workplace planning. Evaluate the proposal using purpose limitation, data minimization, transparency, retention, security, and ethical proportionality.

Multiple Choice Questions with Answers

Question 1

Which activity is the primary purpose of threat modeling?

A. Selecting a programming language

B. Identifying threats, vulnerabilities, and suitable controls

C. Measuring employee productivity

D. Replacing all security testing

Correct Answer: B. Identifying threats, vulnerabilities, and suitable controls

Question 2

Which principle requires access to be denied unless permission is explicitly granted?

A. Fail-safe defaults

B. Psychological acceptability

C. Data portability

D. Redundancy

Correct Answer: A. Fail-safe defaults

Question 3

Which statement correctly distinguishes authentication and authorization?

A. Authentication assigns permissions, while authorization encrypts data

B. Authentication verifies identity, while authorization determines permitted actions

C. Authentication records events, while authorization creates backups

D. Authentication minimizes data, while authorization deletes it

Correct Answer: B. Authentication verifies identity, while authorization determines permitted actions

Question 4

What is the most appropriate protection for stored passwords?

A. Plaintext storage

B. Reversible encryption with a shared application key

C. Salted, adaptive password hashing

D. Encoding with Base64

Correct Answer: C. Salted, adaptive password hashing

Question 5

What does an RPO primarily describe?

A. The maximum acceptable restoration time

B. The maximum acceptable amount of data loss measured in time

C. The number of backup administrators

D. The encryption strength of a backup

Correct Answer: B. The maximum acceptable amount of data loss measured in time

Question 6

A service depends on two independent components, each with availability 0.99, and both are required. What is the approximate series availability?

A. 0.0198

B. 0.9801

C. 0.9900

D. 1.9800

Correct Answer: B. 0.9801

Question 7

Which practice best represents privacy by design?

A. Collecting all potentially useful data indefinitely

B. Collecting only data necessary for a defined purpose

C. Hiding the privacy notice from users

D. Allowing every employee to access personal data

Correct Answer: B. Collecting only data necessary for a defined purpose

Question 8

Which control directly helps prevent insecure direct object references?

A. Server-side authorization for each requested resource

B. Changing the user-interface color scheme

C. Increasing screen resolution

D. Removing all audit logs

Correct Answer: A. Server-side authorization for each requested resource

Question 9

Why must backups be tested through restoration exercises?

A. A backup file automatically proves that recovery will succeed

B. Testing verifies that data and procedures can actually restore operations

C. Testing eliminates the need for access controls

D. Restoration tests are only useful for public data

Correct Answer: B. Testing verifies that data and procedures can actually restore operations

Question 10

Which statement about AI-generated software is most accurate?

A. AI-generated code is automatically secure because it is machine-produced

B. AI removes the need for code review and testing

C. AI can assist engineering activities but its outputs require human review and security testing

D. AI systems cannot create privacy or security risks

Correct Answer: C. AI can assist engineering activities but its outputs require human review and security testing