Secure Development (SDLC)

We build software so that security is an integral part of our information systems throughout every phase of acquisition, development, and maintenance. This page explains how we embed security into our development lifecycle.

Our approach

Security is considered at every stage of a system’s life cycle, including feasibility, planning, development, implementation, maintenance, retirement, and disposal, so that we:

• Conform with the appropriate security requirements.
• Protect enterprise data throughout the system development life cycle.
• Prevent the introduction of new risks when a system is modified.
• Ensure proper removal and disposal of data when a system is retired.

Security is built into all phases of the software development lifecycle, including requirement analysis, design, development, testing, implementation, operations, and maintenance.

Requirements

• Security and privacy requirements for a new product or application are defined at the requirements stage.
• We consider the legal and regulatory implications and security requirements related to the collection and use of confidential data.
• We consider requirements for the reliability and availability of information systems, and where availability cannot be guaranteed by the existing architecture, we consider redundant components or alternative architectures.

Design

• We identify threats and potential vulnerabilities early in the design phase, including areas of possible misuse and ways protective measures could be bypassed.
• We identify the operating environment, internal and external interfaces, data inputs and outputs, and how components work together.
• Software is designed to operate with the minimum privileges necessary.
• Application permissions, privileges, and access controls are designed to adhere strictly to defined user roles.

Development

• We maintain a separate development environment that is physically and logically isolated from production and appropriately protected.
• Developers are instructed to validate incoming and outgoing data, follow memory management best practices, apply secure authentication and session management, and use best practices for error and exception management.
• Source code is protected from unauthorized access, and source code versions are controlled using automated mechanisms.

Secure development principles

As part of our secure development principles, we:

• Use best practices and current libraries for each programming language.
• Maintain security in application version control and code repositories.
• Train developers on secure coding.
• Build developers’ ability to avoid, find, and fix vulnerabilities wherever possible.

Change control within development

Changes to systems within the development lifecycle are controlled through formal change control procedures. New systems and major changes follow a formal process of documentation, specification, testing, managed implementation, and quality control, which includes analyzing the impact of changes and specifying the security controls needed. During change control we:

• Ensure changes are submitted by authorized users and approved before implementation.
• Review controls and integrity procedures so they are not compromised by the changes.
• Identify all software, information, database entities, and hardware that require amendment.
• Identify and check critical code to minimize the likelihood of known security weaknesses.
• Update system documentation, standard operating procedures, and user manuals as needed.
• Maintain version control for all software updates and keep a record of all change requests.
• Schedule the implementation of changes so they do not disturb business processes.

New software is tested in an environment segregated from both production and development, including patches, service packs, and other updates. Automated updates are not used on critical systems by default, because some updates can cause critical systems to fail; where automatic updates are considered, we weigh the risk to system integrity and availability against the benefit of speedy deployment. When underlying operating platforms change, business-critical applications are reviewed and tested to confirm there is no adverse impact on operations or security.

As far as practicable, vendor-supplied software packages are used without modification. Where modification is necessary, we consider the risk to built-in controls, whether vendor consent is needed, whether the change can be obtained from the vendor as a standard update, the impact of becoming responsible for future maintenance, and compatibility with other software. When changes are necessary, the original software is retained and changes are applied to a designated copy. We also maintain a software update process so that approved patches and application updates are installed for authorized software.

Secure engineering

• We apply security engineering principles across all architecture layers (business, data, applications, and technology), balancing information security with accessibility.
• New technology is analyzed for security risks, and designs are reviewed against known attack patterns.
• Systems are reviewed regularly so they stay current, address new threats, and remain scalable.
• Security engineering principles are applied to outsourced information systems through contracts and other binding agreements.

Secure development environments

Our engineering team establishes and protects secure development environments that cover the entire system development life cycle, including the people, processes, and technology involved. When assessing the requirements for a secure development environment, we consider:

• The sensitivity of data to be processed, stored, and transmitted by the system.
• Applicable external and internal requirements, such as regulations or policies.
• Security controls already in place that support development.
• The trustworthiness of personnel working in the environment.
• The degree of outsourcing associated with development.
• The need for segregation between different development environments and control of access to them.
• Control over the movement of data to and from the environment.
• Storage of backups at secure off-site locations.

Testing

New and updated systems are thoroughly tested and verified during development, with a detailed schedule of activities and test inputs and expected outputs under a range of conditions.

• For in-house development, initial testing is performed by the engineering team, followed by independent acceptance testing (for both in-house and outsourced development) to confirm the system works as expected and only as expected, before the change is made in production.
• The extent of testing is determined by the engineering team in line with business requirements and the importance and nature of the system.
• Testing is also conducted on integrated systems, and we can use automated tools such as code analysis tools and vulnerability scanners, verifying that defects have been remediated.
• Testing is performed in a test environment so that it does not introduce vulnerabilities into our environment and so that results are reliable.

Test data

• We avoid using operational data that contains personally identifiable information or other confidential information for testing.
• Where such information is used for testing, sensitive details are protected by removal or modification.
• The access control procedures that apply to production systems also apply to test systems.
• Operational information is erased from the test environment immediately after testing.
• The copying and use of operational information is logged to provide an audit trail.

Questions

If you have any questions about this policy, contact us at [email protected].