Secure Configuration of Software

Intent of this Standard

Default configurations on software and applications can leave organisations insecure and vulnerable to exploitation by malicious actors. This Standard aims to focus efforts on the reviewing and updating of configurations for new and existing software, and to adopt secure implementation practices.

Implementation of this Standard will reduce security vulnerabilities in an organisation’s environment and introduce processes for the secure implementation of software. Some of the concerns this Standard aims to address include:

• Use of default credentials (admin) on software and applications.
• Use of default, insecure configuration settings.
• Use of insecure services and protocols.
• Lack of awareness of enabled services and interfaces.
• Lack of awareness in the changes in environment post-software changes/updates.

The guidance provided within this Standard proposes that organisations commit to adopting best practices and application-hardening recommendations during implementation, as well as conducting regular audits to confirm compliance. The degree of hardening will vary depending on the risk appetite acceptable to an organisation. This includes but is not limited to:

• Referring to vendor guidelines for software/application hardening.
• Following organisational processes and procedures for change management.
• Adhering to best practices for securing and updating software/applications.
• Undertaking periodic audits of compliance to the approved configuration.
• Undertaking periodic updates of the configuration guidelines.

Organisations with a software development function should adopt a Secure Software Development Life Cycle approach to integrating security practices and considerations at every phase of the Software Development Life Cycle (SDLC). This enables organisations to identify security issues early in the software development phase and address them.

Minimum capability maturity level

We have established criteria within a maturity model to provide clarity, including the expected minimum implementation level, which is CS-CMM 2.

Cyber Security Capability Maturity Model

The requirements are intended to meet and comply with each respective level of maturity. The levels provide a pathway that can be used by agencies to assess themselves against, with a view to improving maturity over time.

Each maturity level builds on the requirement from the preceding level.

Below are the requirements for each capability maturity level for this Standard.

Focus areas

Focus areas are applicable to the Standard and are provided as a guide and not an exhaustive list. Each agency is best placed to identify areas of relevance.

The focus areas for this Standard are:

• Corporate networks
• Cloud services
• Operating systems and deployed software
• Internally facing systems
• External/internet-facing systems
• System and software developers and application support teams
• Third-party vendors who provide and are responsible for software.

Suggested actions

The following list is not exhaustive. Organisations should identify which actions are appropriate to implement the Standard based on their current maturity level. However, the following actions follow good practice guidelines:

• Allocating business owners for business-critical systems, software, and applications.
• Developing a baseline requirement for secure software or application configuration from vendor recommendations and best practice. For example, disabling unnecessary services, insecure ports, and protocols. Enabling encryption for data at rest and in transit.
• Implementing a process to include a technical review of any security changes for software and applications.
• Implementing a process to audit configurations regularly, ensuring adherence to the agreed baseline.
• Implementing a process to regularly update the baselines to capture any configuration option changes through the life of the software or platform.
• Including vendor contract clauses, noting the requirements for maintaining secure development practices for services provided.

Key dependencies

To implement this Standard, there are likely to be requisite measures or technologies in place.

A number of dependencies apply to multiple standards. In general, these dependencies are less technology-specific and relate to business processes.

Key dependencies for this Standard include:

• Change-management process exists.
• Sufficient resourcing and capacity available to assess technical risks.
• A risk management strategy and defined acceptable risk level.
• Asset inventory that is regularly updated.
• Patch evaluation or testing process is in place.
• Patch compliance monitoring is undertaken.
• Understanding corporate data and corresponding information flows.

Measurable outcomes

To establish whether the Standard is being implemented, the outcomes are a tool an organisation may wish (or already have in place) to measure to help make this determination.

The outcomes have been designed to align with the requirements contained in the maturity level.

Outcomes for this Standard include:

• Organisations have identified business-critical systems and applications.
• Organisations embed security requirements, including secure-by-design/secure-by-default development practices, into their procurement or sourcing process.
• Organisations have change-management processes to review, test, and approve patches prior to being deployed into production.
• Organisations have a test environment for new software and updates.
• Organisations have contractual commitments from vendors, ensuring secure development practices including secure-by-default/secure-by-design practices are undertaken.
• Organisations adopt a secure-by-design policy and establish a baseline requirement for secure configuration.
• An ongoing programme of configuration review against approved configuration templates.
• An ongoing programme that reviews configuration templates to address changes over time of the configuration options available.