Secure Systems and Application Practices

Introduction

Modern information systems are not secure merely because a firewall, antivirus product, or access-control list has been installed. Security depends on decisions made throughout the life of a system: what the system is intended to do, what could go wrong, what information it collects, how it is built, how changes are approved, and how weaknesses are discovered and corrected. Secure systems practice therefore combines engineering, governance, law, privacy, and professional ethics.

This chapter examines secure-by-design and privacy-by-design principles, security requirements, vulnerability management, the secure software development life cycle, testing, change control, common web application risks, and responsible vulnerability disclosure. The emphasis is practical: a cybersecurity professional should be able to recognize security expectations, participate in risk-based decisions, identify weaknesses, and support secure implementation without assuming that security is the responsibility of a single specialist team.

Learning Objectives

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

1. Explain secure-by-design and privacy-by-design principles.
2. Translate threats, legal duties, and business needs into security requirements.
3. Describe vulnerability management and risk-based remediation.
4. Explain the stages of a secure software development life cycle.
5. Distinguish security testing methods and explain the purpose of change control.
6. Recognize common web application risks and suitable controls.
7. Apply ethical and legally responsible vulnerability-disclosure practices.

1. Security as a Design Property

1.1 Secure-by-design

Secure-by-design means that security is treated as a fundamental system quality from the earliest planning stage rather than as a later addition. The approach asks questions such as:

• What assets require protection?
• Who are the legitimate users and administrators?
• What misuse or abuse could occur?
• What is the effect of a compromise?
• Which controls should be preventive, detective, and corrective?

Security is often described through the confidentiality, integrity, and availability (CIA) triad. Confidentiality limits information disclosure to authorized parties. Integrity protects information and system behavior from unauthorized or improper alteration. Availability supports timely and reliable access. Authenticity, accountability, and non-repudiation are also important properties in many systems.

Secure design uses several recurring principles:

No single principle is sufficient. For example, encryption may protect stored data, but it does not compensate for excessive administrator privileges or insecure recovery procedures.

1.2 Privacy-by-design

Privacy-by-design incorporates privacy protection into system architecture, processes, and default settings. Privacy is broader than secrecy. It includes appropriate collection, use, retention, sharing, accuracy, transparency, and individual control over personal information. A database can be strongly encrypted and still violate privacy if it collects unnecessary data or uses it for an undisclosed purpose.

Common privacy-by-design practices include:

• Data minimization: collect only data necessary for a specified purpose.
• Purpose limitation: do not silently reuse data for incompatible purposes.
• Privacy-protective defaults: require an affirmative choice before optional sharing.
• Retention limitation: define and enforce deletion or anonymization periods.
• Transparency: explain what is collected, why, with whom it is shared, and for how long.
• User participation: provide practical ways to access, correct, export, or delete information where applicable.
• Privacy risk assessment: examine possible effects on individuals before processing begins.
• Protection throughout the life cycle: secure collection, processing, storage, transfer, backup, and disposal.

Security and privacy overlap but are not identical. Security protects systems and information from unauthorized actions; privacy governs appropriate processing of information about people. A privacy program may require deletion, while an information-security program may require retaining audit records. Such conflicts must be resolved through documented legal, operational, and risk-based decisions.

2. From Business Needs to Security Requirements

A security requirement is a verifiable statement of what a system must do, or must not do, to protect assets and meet obligations. Requirements should be specific enough to test. “The system must be secure” is not testable; “After five failed logins within ten minutes, the account must be temporarily locked and the event logged” is more useful.

2.1 Sources of requirements

Security requirements may originate from:

• business objectives and risk appetite;
• threat modelling and abuse cases;
• contractual obligations;
• privacy and cybersecurity law;
• industry standards and internal policies;
• safety and continuity requirements;
• accessibility and human-factors considerations;
• findings from incidents, audits, and previous vulnerabilities.

A requirement should identify the protected asset, the required behavior, the responsible component, and the acceptance test. Requirements also need priorities. A payment application may rank transaction integrity above convenience, while an emergency medical system may give availability and safe degradation the highest priority.

2.2 Threat modelling

Threat modelling is a structured process for identifying how a system could be attacked or misused. A basic process is:

1. Define the system scope, trust boundaries, users, data flows, and valuable assets.
2. Identify threats, including malicious, accidental, environmental, and supply-chain events.
3. Estimate likely impact and plausibility.
4. Select controls and record residual risk.
5. Review the model when architecture or threats change.

Frameworks such as STRIDE can prompt consideration of spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. These categories are aids to reasoning, not substitutes for context. Threat modelling should include misuse by legitimate users, compromised accounts, vulnerable dependencies, and operational mistakes.

2.3 Quality characteristics of requirements

Good security requirements are:

• Unambiguous: different readers reach the same interpretation.
• Testable: evidence can show whether the requirement is met.
• Traceable: linked to a risk, obligation, asset, or design decision.
• Prioritized: critical requirements are distinguished from desirable ones.
• Feasible: achievable with available technology and resources.
• Maintained: updated when assumptions, threats, or regulations change.

Acceptance criteria might specify authentication methods, authorization rules, encryption conditions, logging fields, recovery objectives, rate limits, or maximum retention periods. A requirement for encryption should identify data in scope, protection during transmission or storage, key-management responsibilities, and how compliance will be tested.

3. Vulnerability Management

A vulnerability is a weakness that can be exploited to violate a security property. Vulnerability management is a continuing process, not a one-time scan. It includes asset discovery, weakness identification, validation, prioritization, remediation, verification, and reporting.

3.1 The management cycle

Asset and software inventory comes first. An organization cannot reliably protect unknown applications, cloud resources, libraries, or devices. Inventories should include ownership, business criticality, data handled, exposure, version, and support status.

Identification uses secure code review, dependency analysis, configuration assessment, penetration testing, vulnerability scanners, vendor notices, threat intelligence, incident reports, and researcher reports. Automated tools produce useful signals but also false positives and false negatives.

Validation and triage determine whether a finding is real, exploitable, relevant to the asset, and already mitigated by compensating controls. Findings should be assigned an owner and target date.

Prioritization should consider more than a severity score. Relevant factors include exploitability, internet exposure, asset criticality, sensitivity of data, evidence of active exploitation, availability of a fix, and operational constraints. A medium-severity flaw in an exposed authentication service may deserve faster treatment than a high-severity flaw in an isolated test system.

Treatment may involve patching, configuration changes, code correction, removal of a feature, network isolation, additional monitoring, or formal risk acceptance. Risk acceptance should be authorized, time-limited, and accompanied by compensating controls where possible.

Verification and closure require retesting, evidence, updated records, and checking that the fix did not create a new defect. Metrics should measure meaningful outcomes, such as the age of exploitable critical findings, remediation time by asset class, recurrence rate, and coverage of supported assets. A large number of closed tickets alone is not proof of improved security.

3.2 Severity and risk

A vulnerability score is not the same as organizational risk. Risk assessment commonly considers likelihood and impact, but there is no universally correct numerical equation for every organization. A simple qualitative matrix may classify risk using low, medium, high, and critical categories. If an organization uses a numerical model, it must define scales, assumptions, thresholds, and decision authority; otherwise apparent precision can mislead.

Common Vulnerabilities and Exposures (CVE) identifiers help name publicly known vulnerabilities. The Common Vulnerability Scoring System (CVSS) provides a standardized severity score, but the environmental context remains essential. CVSS should inform, not replace, asset-specific judgment.

4. The Secure Software Development Life Cycle

The secure software development life cycle (SSDLC) integrates security activities into requirements, design, implementation, testing, release, operation, and retirement. It is compatible with agile, DevOps, and iterative delivery; security activities should be continuous rather than postponed to a final gate.

4.1 Planning and requirements

Teams identify assets, trust boundaries, regulatory obligations, abuse cases, security requirements, privacy requirements, and security acceptance criteria. Security architects, developers, operations staff, privacy specialists, and business owners should contribute according to the system’s risk.

4.2 Secure design

Design reviews examine authentication, authorization, session handling, cryptographic use, error handling, secrets, logging, resilience, backup, recovery, and third-party integrations. Threat modelling is especially valuable before implementation because architectural weaknesses are often expensive to correct later.

4.3 Secure implementation

Developers use approved libraries and patterns, validate input on the server, encode output for its context, handle errors without exposing sensitive details, protect secrets, and keep dependencies supported. Code review should consider both functional correctness and abuse resistance. Secrets should not be embedded in source code or committed to public repositories; managed secret stores and controlled rotation are preferable.

4.4 Verification and release

Security testing is performed throughout development. Builds should be reproducible where feasible, dependencies should be inventoried, and release decisions should record unresolved risks. A software bill of materials (SBOM) can support dependency visibility and response to supply-chain vulnerabilities.

4.5 Operations and retirement

Production security includes logging, monitoring, alert response, patching, backup testing, capacity management, access review, and incident response. At retirement, data and credentials must be handled safely, integrations removed, and records retained or deleted according to policy and law.

5. Security Testing

Different testing methods discover different classes of weakness.

Testing must be authorized, scoped, and conducted in a way that protects production availability and personal data. Test data should be synthetic or minimized. Findings should be reproducible, risk-ranked, assigned, and retested.

A clean test result does not prove that a system is secure. It means only that the selected tests did not reveal a problem under their conditions. Security assurance is therefore based on layered evidence: requirements, design review, code review, automated tests, independent assessment, operational monitoring, and incident learning.

6. Change Control and Configuration Security

Change control is the disciplined management of modifications to code, infrastructure, data structures, configurations, and access rights. Its purpose is not to prevent change; it is to make change understandable, authorized, tested, traceable, and reversible.

A normal change record usually identifies the reason, scope, risk, affected services, implementation plan, test evidence, approval, deployment window, communication plan, rollback method, and post-implementation review. Emergency changes may follow an expedited path, but they still require retrospective documentation and review.

Version control provides history and supports peer review. Separation between development, test, and production environments reduces accidental impact. Infrastructure as code and configuration baselines can make approved states reproducible. Continuous integration and continuous delivery pipelines should include access controls, protected branches, dependency checks, secret scanning, tests, and approval gates appropriate to risk.

Configuration drift occurs when deployed settings diverge from the approved baseline. Drift can reintroduce disabled services, weak permissions, or unmonitored changes. Regular comparison, controlled administrative access, and automated enforcement reduce this risk.

7. Common Web Application Risks

7.1 Broken access control

Access control failures occur when users can perform actions or access objects beyond their authorization. Examples include changing an identifier in a URL to view another customer’s record, invoking an administrative API directly, or relying on hidden interface elements rather than server-side authorization. Controls include deny-by-default policies, centralized authorization logic, object-level checks, role and attribute testing, and tests for horizontal and vertical privilege escalation.

7.2 Injection

Injection occurs when untrusted data is interpreted as commands or queries. SQL injection, command injection, and expression-language injection are examples. Parameterized queries, safe APIs, contextual output encoding, input constraints, least-privileged service accounts, and careful separation of data from instructions are central defenses. Input validation is valuable but should not be the sole defense.

7.3 Cross-site scripting (XSS)

XSS allows attacker-controlled script content to execute in a victim’s browser in the security context of a site. Stored, reflected, and DOM-based forms are commonly distinguished. Context-appropriate output encoding, safe templating, input handling, Content Security Policy, secure cookie attributes, and avoiding unsafe browser APIs reduce risk. XSS is not solved by indiscriminately stripping characters because valid data and different output contexts require different treatment.

7.4 Cross-site request forgery (CSRF)

CSRF abuses a victim’s authenticated browser session to cause an unwanted state-changing request. Anti-CSRF tokens, SameSite cookie settings, origin checks, and reauthentication for sensitive actions can help. CSRF analysis must account for the application’s authentication mechanism and browser behavior.

7.5 Authentication and session weaknesses

Weak passwords, credential stuffing, insecure recovery, missing multi-factor authentication, predictable session identifiers, sessions that do not expire, and failure to invalidate sessions after logout can enable account takeover. Controls include strong authentication, rate limiting, secure session generation, protection of cookies, reauthentication for high-risk actions, monitoring, and recovery procedures that are no weaker than normal login.

7.6 Cryptographic and data-protection failures

Common failures include transmitting sensitive information without appropriate protection, using obsolete algorithms, hard-coding keys, poor random-number generation, and failing to protect backups. Organizations should use well-maintained cryptographic libraries, documented algorithms and key lifecycles, authenticated encryption where appropriate, certificate management, and carefully defined data-classification rules. Encryption does not fix excessive collection or weak authorization.

7.7 Security misconfiguration and vulnerable components

Default accounts, verbose errors, exposed administration interfaces, unnecessary services, permissive cloud storage, missing security headers, and unpatched frameworks are frequent sources of compromise. Secure baselines, automated configuration checks, patch management, dependency inventories, and removal of unused functionality are practical defenses.

7.8 Insecure design and server-side request forgery

Insecure design is a weakness in architecture or business logic rather than a single coding error. Examples include unlimited password-reset attempts or a workflow that permits approval by the requester. Server-side request forgery (SSRF) occurs when an application retrieves attacker-influenced destinations and can thereby reach internal services. Controls include explicit trust-boundary analysis, allowlists, network egress restrictions, safe URL parsing, blocking access to sensitive metadata services, and monitoring outbound requests.

8. Responsible Vulnerability Disclosure

Vulnerability research can improve public safety, but unauthorized access, data theft, service disruption, persistence, or public release of exploitable details may violate law, contracts, and professional ethics. Authorization is the central boundary. A researcher should test only systems and methods within clearly permitted scope.

A responsible process generally includes:

1. Read the organization’s security contact or vulnerability-disclosure policy.
2. Minimize access, data collection, and operational impact.
3. Stop when sufficient evidence establishes the weakness.
4. Preserve only necessary evidence and protect any personal data.
5. Report privately through the specified channel with affected assets, steps to reproduce, impact, timestamps, and suggested mitigation.
6. Allow reasonable coordination for validation and remediation.
7. Escalate carefully if no response occurs, using a recognized coordinator or relevant authority where appropriate.
8. Avoid publishing secrets, personal data, weaponized exploit code, or details that create disproportionate danger.

Organizations should make reporting easier by publishing a security contact, supported encryption method where needed, scope, safe-harbor language, response expectations, and coordinated disclosure practices. A report should be assessed objectively rather than punished when it follows the stated rules. Legal protection varies by jurisdiction; a “good intention” is not a substitute for authorization.

9. Applied Case: An Online Student-Services Portal

The following is an illustrative case, not a report of a real organization.

Background

A college plans a portal through which students can view grades, update contact details, submit appeals, and pay fees. The portal will process identity information, academic records, and payment-related data. The project team initially schedules a penetration test immediately before launch.

Problem

During requirements review, the cybersecurity analyst observes that the design uses predictable student identifiers in URLs, collects unnecessary demographic information, permits support staff broad database access, and sends detailed error messages to browsers. A third-party analytics package is also proposed without a data-flow assessment.

Analysis

Threat modelling identifies unauthorized record access, account takeover, privacy over-collection, information disclosure, and supply-chain exposure. The risks are architectural and cannot be reliably corrected by a final penetration test alone. Legal and institutional duties require appropriate protection of student records and transparent handling of personal information.

Approach and solution

The team introduces object-level authorization checks on every request, role-based permissions for staff, multi-factor authentication for administrators, rate limiting and secure recovery, generic user-facing errors with detailed protected logs, and an approved payment integration that minimizes the portal’s handling of payment data. Optional demographic fields are removed unless a documented purpose exists. Retention and deletion rules are added to the design. The analytics component is replaced with a privacy-reviewed alternative, and dependencies are recorded in an SBOM.

Security requirements are converted into acceptance tests. SAST, dependency analysis, authenticated DAST, manual business-logic review, and an independent penetration test are performed. A controlled release uses peer review, rollback procedures, monitoring, and a post-deployment access review.

Outcome

Testing confirms that changing a record identifier does not disclose another student’s data, staff accounts cannot perform administrative functions, and sensitive events are logged without exposing unnecessary personal information. One medium-risk dependency issue remains temporarily, with a documented owner, compensating network restriction, and target remediation date.

Learning points

The case demonstrates that secure design begins before code, privacy decisions affect architecture, automated tools are complementary rather than complete, and risk acceptance must be explicit. It also illustrates that a final penetration test is valuable but cannot replace requirements, design review, secure development, and operational controls.

10. Challenges, Governance, and Contemporary Practice

Security controls can reduce convenience, increase cost, or create accessibility problems if poorly designed. Excessive authentication prompts may encourage unsafe workarounds; aggressive blocking may deny legitimate users; extensive logging may create a privacy risk. Controls should be proportionate, usable, accessible, and reviewed for unintended effects.

Governance should define accountability. Product owners accept business risk; developers implement and correct; security professionals advise and assess; privacy specialists evaluate personal-data processing; operations teams protect production; internal audit provides independent assurance. These roles may be combined in a small organization, but conflicts should be recognized.

Artificial intelligence can assist code review, vulnerability triage, test generation, and detection of anomalous behavior. However, AI-generated code may contain insecure patterns, reproduce vulnerable dependencies, mishandle confidential prompts, or create false confidence. Human review, approved tools, data-protection controls, provenance, testing, and accountability remain necessary.

Contemporary practice increasingly emphasizes software supply-chain security, memory-safe languages where suitable, zero-trust assumptions, secure cloud configuration, SBOMs, automated policy checks, identity-centered controls, and resilience against ransomware and destructive attacks. These developments reinforce rather than replace the foundational practices in this chapter: understand assets, define requirements, minimize exposure, verify controls, manage change, and learn continuously.

Chapter Summary

Secure systems are created through deliberate decisions across the full life cycle. Secure-by-design applies confidentiality, integrity, availability, least privilege, fail-safe behavior, defence in depth, and attack-surface reduction from planning onward. Privacy-by-design adds minimization, purpose limitation, transparency, retention control, user participation, and protection of personal information throughout processing.

Security requirements should be traceable, testable, prioritized, and linked to risks or obligations. Threat modelling helps identify abuse paths and supports appropriate controls. Vulnerability management requires accurate inventories, validated findings, risk-based prioritization, remediation, verification, and meaningful metrics. The SSDLC integrates security into requirements, design, implementation, testing, release, operation, and retirement.

SAST, DAST, SCA, fuzzing, code review, and penetration testing provide different evidence and have different limitations. Change control makes modifications authorized, tested, traceable, and reversible. Web applications commonly fail through broken access control, injection, XSS, CSRF, weak authentication, cryptographic errors, misconfiguration, vulnerable components, insecure design, and SSRF. Finally, vulnerability disclosure must be authorized, minimally harmful, private during coordination, and respectful of legal and ethical boundaries.

Key Terms

Secure-by-design: Treating security as a fundamental property planned into a system from its beginning.

Privacy-by-design: Integrating privacy protection into architecture, processes, and default settings.

CIA triad: Confidentiality, integrity, and availability.

Least privilege: Granting only the access necessary for an authorized task.

Defence in depth: Using multiple independent protective layers.

Threat modelling: Structured analysis of assets, threats, trust boundaries, and controls.

Security requirement: A testable statement of required protective behavior or constraint.

Vulnerability: A weakness that may be exploited to violate a security property.

Vulnerability management: The continuing process of discovering, prioritizing, treating, and verifying weaknesses.

CVSS: A standardized framework for communicating vulnerability severity.

SSDLC: Secure software development life cycle.

SAST: Analysis of source or compiled code for security weaknesses.

DAST: Testing a running application from an external perspective.

SBOM: A structured inventory of software components and dependencies.

Change control: Governance of authorized, tested, documented, and reversible modifications.

Broken access control: Failure to enforce permitted actions or object access.

Injection: Untrusted data being interpreted as commands or queries.

Cross-site scripting: Execution of attacker-controlled script in a user’s browser context.

SSRF: Manipulation of a server into making unintended requests to other resources.

Responsible disclosure: Authorized, coordinated reporting of vulnerabilities with minimized harm.

Review Questions

Short Answer Questions

1. What is the difference between secure-by-design and adding security after deployment?
2. Name four privacy-by-design practices.
3. Why is an asset inventory important to vulnerability management?
4. What is the purpose of change control?
5. Why can a penetration test not prove that an application is secure?

Long Answer Questions

1. Explain how least privilege, fail-safe defaults, defence in depth, and separation of duties can work together in an online payment system.
2. Describe the stages of a secure software development life cycle and identify security activities appropriate to each stage.
3. Compare SAST, DAST, software composition analysis, fuzz testing, and penetration testing.
4. Explain how a vulnerability should be prioritized and treated after it has been discovered.
5. Discuss the relationship and difference between information security and privacy-by-design.

Analytical / Application Questions

1. An application allows a logged-in user to change an account number in a URL and view another user’s profile. Identify the vulnerability, explain the likely impact, and propose layered controls and tests.
2. A critical internet-facing service has an unpatched high-severity dependency, while a low-severity issue exists on an isolated laboratory server. Develop a reasoned remediation order and state what additional facts you would seek.
3. You discover a vulnerability in a college portal but have no written permission to test it. Explain the ethical and legal steps you should take before further testing or disclosure.

Multiple Choice Questions with Answers

Question 1

Which principle requires a system to deny access when an authorization check fails?

A. Fail securely

B. Data minimization

C. Separation of duties

D. Purpose limitation

Correct Answer: A. Fail securely

Question 2

Which activity is most directly associated with privacy-by-design?

A. Increasing log retention indefinitely

B. Collecting every available user attribute

C. Collecting only information necessary for a stated purpose

D. Disabling access reviews

Correct Answer: C. Collecting only information necessary for a stated purpose

Question 3

What should normally occur first in a vulnerability-management process?

A. Public disclosure

B. Asset and software inventory

C. Deleting all logs

D. Accepting every finding as critical

Correct Answer: B. Asset and software inventory

Question 4

Which testing method analyzes source or compiled code without requiring the application to run?

A. DAST

B. SAST

C. Penetration testing

D. Fuzz testing

Correct Answer: B. SAST

Question 5

What is the primary purpose of change control?

A. To prevent all system changes

B. To make changes authorized, tested, documented, and reversible

C. To eliminate the need for backups

D. To replace security testing

Correct Answer: B. To make changes authorized, tested, documented, and reversible

Question 6

A user changes an object identifier and views another customer’s record. What is the most likely vulnerability?

A. Broken access control

B. Cross-site request forgery

C. Denial of service

D. Data minimization failure

Correct Answer: A. Broken access control

Question 7

Which control is most directly designed to reduce SQL injection?

A. Parameterized queries

B. Longer session timeouts

C. Public error messages

D. Disabling backups

Correct Answer: A. Parameterized queries

Question 8

What is the central ethical boundary for vulnerability research?

A. Using the newest scanning tool

B. Authorization to test the system and methods used

C. Finding a vulnerability quickly

D. Publishing technical details immediately

Correct Answer: B. Authorization to test the system and methods used

Question 9

Why is CVSS alone insufficient for deciding remediation priority?

A. It never describes technical severity

B. It cannot be used for public vulnerabilities

C. It does not fully represent an organization’s asset context and exposure

D. It replaces all risk judgment

Correct Answer: C. It does not fully represent an organization’s asset context and exposure

Question 10

Which artifact helps an organization identify software components and dependencies in a product?

A. SBOM

B. CSRF token

C. Firewall rule

D. Session cookie

Correct Answer: A. SBOM