Introduction: Secure Engineering & Service Assurance

1. A Proactive Approach to Security

In today's digital landscape, security is not a feature; it is a fundamental prerequisite for building trusted, high-quality software. Our commitment to protecting our customers' data, complying with regulations like GDPR and BIO, and safeguarding our company's reputation requires a shift in how we approach security.

Secure Software Development is the practice of building security into our software from the ground up. It moves security from being a final, often rushed, "gate" before release to a shared responsibility that is integrated into every stage of our development process. This proactive approach is significantly more effective and cost-efficient than reacting to vulnerabilities found in production. It transforms security from a source of friction into a catalyst for building better, more resilient products.

To achieve this, we are formally adopting the Secure Software Development Lifecycle (SSDLC) as our core framework.

2. The Secure Software Development Lifecycle (SSDLC)

The SSDLC is a systematic framework that integrates security activities and best practices into every phase of our existing Agile development process. This framework helps us incorporate security into each step of our development cycles, ensuring that requirements, design, coding, testing, and deployment have security considerations represented and actioned.

In practice, this means:

By making security a visible and integral part of our daily work in Azure DevOps, the SSDLC empowers our teams to build secure software efficiently and effectively.

3. The Eight Immutable Principles of Secure Design

While the SSDLC provides the process (the "when"), we also require a set of engineering principles (the "how") to guide our architectural decisions. We adhere to eight foundational principles derived from Saltzer and Schroeder’s seminal work, adapted for our modern SaaS environment.

I. The Principle of Least Privilege
Every program and every user of the system should operate using the least set of privileges necessary to complete the job. This limits the damage that can result from an accident or error. In our HR context, a "Payroll Viewer" service should not have "Write" access to salary tables. If an attacker compromises that service, their lateral movement is mathematically restricted.

II. Defense in Depth (Layered Security)
We do not rely on a single defensive mechanism. If the perimeter firewall is breached, internal authentication must hold. If authentication is bypassed, database encryption must prevent data theft. Defense in Depth acknowledges that controls will fail; therefore, we build redundant layers of protection to ensure that the failure of one control does not result in total system compromise.

III. Fail-Safe Defaults
Access decisions should be based on permission rather than exclusion. The default state of any system must be "Access Denied." If a security mechanism fails or crashes, it must fail into a locked state, not an open one. When a user’s session state is ambiguous, the system must reject the request rather than guessing it is safe.

IV. Economy of Mechanism
Complexity is the enemy of security. The design of security mechanisms should be as simple and small as possible. Complex code paths hide vulnerabilities and are difficult to test. By keeping our security logic—such as authentication flows—simple and auditable, we reduce the "attack surface" where bugs can hide.

V. Complete Mediation
Every access to every object must be checked for authority. We do not cache access decisions. Just because a user was authorized to view a record ten minutes ago does not mean they are authorized now. The system must mediate every request against the current security policy, ensuring that permissions are revoked instantly when roles change.

VI. Open Design
The security of our architecture must not depend on the secrecy of its implementation. We reject "Security by Obscurity." Our cryptographic algorithms and security protocols should be robust enough that they remain secure even if the source code is public. We rely on the secrecy of keys and passwords, not the secrecy of our logic.

VII. Separation of Duties (Least Common Mechanism)
Critical functions should be divided to ensure that no single mechanism or person has total control. In software terms, this means minimizing the amount of code shared between different users or processes to prevent information leakage. A failure in the "Candidate Portal" should not be able to crash or access memory in the "Payroll Engine."

VIII. Psychological Acceptability
Security mechanisms must not overly interfere with the work of users, or they will be bypassed. If our security controls are too draconian or complex, users will find unsafe workarounds (e.g., writing passwords on sticky notes). Effective security is usable security; it protects the user without obstructing their workflow.

4. Operational Assurance: The ISAE 3402 Standard

While the principles above guide how we build software, we must also prove to our clients—particularly those in finance and healthcare—that we are operating securely. As a Service Organization, we provide this assurance through ISAE 3402 (International Standard on Assurance Engagements).

ISAE 3402 Type I: The Design of Controls
This report is a snapshot in time. It confirms that BCS has designed a control framework that, if followed, would achieve our security objectives. It serves as our "Blueprint Verification," demonstrating to auditors that we have a valid plan.

ISAE 3402 Type II: The Operating Effectiveness
This report covers a specific period (typically 12 months) and is the gold standard of assurance. The auditor tests the evidence: Did a peer review actually happen? Was the penetration test actually conducted? The Type II report confirms that our controls were not just designed, but were operating effectively throughout the year.

Policy as Evidence
There is a symbiotic relationship between this Policy and ISAE 3402. When we mandate "Sprint 0 Risk Assessments" or "Level 4 TLPT Testing" in this document, we are generating the audit trail required for ISAE 3402. Every ticket in Azure DevOps and every Pull Request approval serves as evidentiary matter for our Type II report.

5. Governance Hierarchy: Policy vs. Standards vs. Procedures

To implement the SSDLC and ISAE controls effectively, we structure our documentation as a pyramid. This structure ensures clarity on what is a rule, what is a tool, and what is a step.