Foundations for modern defensible architecture

Zero trust pillar: All

Organisations need to reduce the number of authoritative sources for enterprise identities in their information environments by using centrally managed solutions. This approach provides organisations with a more holistic view of their users, including their roles and responsibilities, which assists in making risk-based decisions on user access requests and permissions. It additionally gives a greater ability to track users through organisational changes, including when staff change responsibilities or depart from their roles.

The following outline recommendations for implementing the centrally managed enterprise identities Foundation:

• Non-user identities should be captured and managed within centrally managed solutions, including service identities and device identities, such as those used by Internet-of-Things (IoT) devices and software.
• All user and non-user identities should be granted the minimum privileges required to perform their functions correctly.
• Centrally managed identity solutions should share data about identities with other enterprise systems, including authentication, authorisation and security monitoring software.
• Identity information should be sourced from external systems, such as those used by personnel security, human resources and contract management teams.
• Identity information, both sourced and centrally managed, should maintain its accuracy through change and release management processes.
• When procuring new hardware, software and services, the requirement for compatibility with an organisation’s identity management system should be a high priority.
• A centrally managed solution should facilitate integration with external organisations and cloud services, especially when the organisation provides access to external or guest users.

Zero trust pillar: Identity, Devices, Networks and Application & Workloads

Organisations require a trusted and strong authentication model, to protect user and device credentials from compromise by common attacks.

The following outline recommendations for implementing the high assurance authentication Foundation:

• Authentication requirements should be integrated at the application layer, rather than the network layer, to provide visibility and assurances of a user’s particular activities.
• Organisations should align the choice of approved authentication solutions to the potential business impact of compromise, and to provide the necessary assurances that the claimant controls the authentication factors.
• The level of assurance can change between systems and roles based on what activities a user is able to perform. Organisations should standardise the level of assurance across the workforce to the most secure option that suits the organisation’s requirements.
• Organisations must prioritise technology solutions that support cryptographically secure, phishing resistant multi-factor authentication, such as passkeys and smartcards.
• For non-user identities, authentication should be achieved through factors that are tightly bound to the service or hardware, such as trusted digital certificates.
• Device identities should be required to authenticate to the network before they are allowed to communicate with other resources.
• Mutual Authentication should be used to communicate between services to provide confidence that both services are genuine.
• Organisations should prioritise investment in technologies that support cryptographic credential binding to the device and the service being used. Cryptographic credential binding enhances the authenticated session security for unmanaged endpoints, such as bring-your-own-device (BYOD).

Zero trust pillars: All

Organisations need to ensure that access to enterprise resources is initially, and continuously, authorised based on defined levels of trust, using the context of the sessions and resources to gain confidence in the access request.

The following outline recommendations for implementing the contextual authorisation Foundation:

• To evaluate the level of trust, session context should be available to the authorisation model as signals and confidence indicators. This includes attributes such as time of request, location of endpoints, network source, user roles, credential type and endpoint health. Resource attributes, such as sensitivity labels and data type, are required to determine which access policies should be used by the authorisation model.
• The authorisation model should assume that no session has inherited trust, and that a minimum set of confidence indicators are essential to attain and retain the required level of trust for access.
• The authorisation model should be capable of managing sessions based on an organisation’s access policies, including the use of multiple confidence indicators to evaluate whether the access remains in a trusted state.
• Access policies should identify the expected values of session attributes to provide indicators of confidence to the authorisation model.
• The policies that define the attributes and their expected values should be developed in a secure way, ensuring they maintain a high level of integrity and availability during storage and communication.
• To keep an ongoing session secure, user access needs to be continuously evaluated based on the activities taking place within a session, as well as other information that may indicate a drop in confidence, including changes in software state, security posture or behavioural analysis.
• Organisations should prioritise technology solutions that support dynamic authorisation policies, which can adjust the level of confidence required for access based on broader organisational context, such as an ongoing incident or known exploitable vulnerabilities being identified.
• Organisations should design and develop their information environments and software to be integrated with their chosen identity management solutions, and authorisation and access model. This includes defining system boundaries where authorisation model decisions can be enforced.
• Authorisation decision enforcement points should have the ability to generate and communicate ongoing environmental and session context for the continuous access evaluation.

Zero trust pillars: All

Organisations need to have complete and comprehensive knowledge of all endpoints, networks, applications, identities and data stores that contain organisational information, including in services and environments not directly managed by the organisation. This is achieved through an accurate and reliable inventory solution which continuously identifies and records information on an organisation’s assets and resources.

The following outline recommendations for implementing the reliable asset inventory Foundation:

• Information from the asset inventory should be accessible by security software for analysis, and authorisation solutions for evaluating and assessing access requests.
• The inventory should record information about the relationships between assets. This includes what endpoints, networks and applications interact with data and workloads, including whether they have the requirement to access, transmit, store or process sensitive data.
• The automatic discovery of assets should be supported to streamline the detection of components that exist in highly dynamic or short-lived environments, such as in systems that are designed to scale based on processing needs.
• Software that can automate the discovery of assets should be configured to detect and analyse the removal of assets from the environment and provide that information to the relevant teams and monitoring solutions.
• An asset’s lifecycle changes should be recorded and analysed by the solution, ensuring that only approved assets are added, changed or removed, and unauthorised operations are blocked and reported.
• Organisations should prioritise technology solutions that support security alerting, to prevent unauthorised assets being connected to the organisation’s information environment.

Zero trust pillars: Devices and Applications & Workloads

Organisations need to harden and configure all endpoints to provide protection against cyber threats and mitigate weaknesses in software and hardware.

The following outline recommendations for implementing the secure endpoints Foundation:

• Information on an endpoint’s current state of health should be continuously consumable by the authorisation model as an input to evaluate trust.
• Priority should be given to real-time attestations of an endpoint’s conformance with a security baseline, with stored historical data being treated as lower confidence.
• All organisationally managed endpoints and endpoint software (including operating systems) should be hardened with ASD and vendor hardening guidance where possible.
• All hardened configuration baselines should be recorded in a secure way, ensuring they maintain a high level of integrity.
• Endpoints and software should be monitored for changes to configuration, or operational settings, and alerts should be generated when these drift from the recorded baselines.
• Endpoints and software that have drifted from recorded baselines should provide low confidence indicators to the authorisation model and have access to resources limited accordingly.
• Endpoints not owned or managed directly by an organisation, such as bring-your-own-devices (BYOD), should provide low confidence indicators to the authorisation model. Systems that are commonly accessed by these endpoints should be architected to mitigate attacks that are likely to come from compromised systems.
• Highly sensitive and privileged activities should require endpoints that are managed by the organisation, with continuously verified and high confidence indicators of the endpoint’s security baseline.
• A comprehensive endpoint solution will include technologies that can respond to deviations by automatically restoring software back to the required secure configuration baseline.
• The systems that evaluate security baselines should communicate back to a centralised repository where endpoint status can be used by the authorisation model.

For more information on ASD hardening guidance, please visit Guidelines for system hardening.

Zero trust pillars: Devices, Networks, Applications & Workloads, and Data

Organisations need to minimise exposure of their attack surface to cyber threats and malicious actors. This can be achieved by reducing the number of services that communicate with networks of lower trust, as well as limiting the exposure of resources to networks where there is no logical requirement or a significant security risk.

The following outline recommendations for implementing the reduced attack surface Foundation:

• Organisations should consider the exposure of systems they do not own or operate that contain organisational data, including cloud services and externally hosted source code repositories.
• Organisations should restrict access to unauthorised external services, specifically cloud applications, email services and file sharing applications.
• All applications and networks should be designed and configured to only be visible to networks and resources that are required for them to perform their operations.
• Organisations should have a capability to verify that applications and networks are not exposed to untrusted environments.
• Internally managed applications that are required to be accessed remotely should do so in a way consistent with the organisation’s authorisation model and without relying solely on protections at the network layer.
• Organisation endpoints should have the minimum set of applications installed to meet business requirements and should be managed securely, including through the deployment of security patches and the removal of unnecessary features and functions.
• Organisations should develop a capability with vulnerability and attack surface management tools, to quickly and accurately respond to new potential cyber threats to reduce the attack surface of vulnerable systems.
• Endpoints that have vulnerable business-critical software that cannot be updated, patched or upgraded should be isolated from other resources when not being utilised, with the intent to replace the software as soon as possible.

Zero trust pillars: Devices and Networks

Organisations need to build resilient networks derived from an organisation’s business requirements, noting these evolve organically over time. Organisations can take proactive steps to reduce the business impact of system testing and maintenance to improve network resiliency, and to identify architectural and operational flaws. Organisations need to ensure data being communicated over their network is safe from tampering, interception and exfiltration, while protecting service and system availability from impacts, such as network failures, system compromises and denial-of-service attacks. Networks should be designed to allow for only secure and authenticated identities to communicate with other resources, using the context of the request to dynamically determine confidence in the validity of the communication.

The following outline recommendations for implementing the resilient networks Foundation:

• Organisations should prioritise technologies that support high availability and automated failover in the event of a device or service failure.
• Organisations should test their networks through table-top exercises, penetration tests, threat modelling, redundant network path failure testing, load testing, and simulated device failure testing.
• Organisations should periodically evaluate network architecture to identify opportunities to improve network resiliency
• Organisational networks should be configured with secure protocols using ASD-approved cryptographic protocols and leveraging secure and verifiable technologies.
• All data that is communicated over enterprise networks should be encrypted and configured to meet contemporary security standards and established better practices.
• Organisations should actively deprecate weak or vulnerable network protocols as hardened and encrypted versions are standardised.
• Monitoring of network device configurations should be implemented to ensure that security policies are being enforced across segments and environments.
• Organisations should evaluate the threat of compromise in traffic capture and monitoring solutions, including the threat of data collection from capture devices that decrypt traffic for inspection.
• Organisations should design and define logical network boundaries that restrict lateral connections between resources based on the context of a request, to prevent compromised endpoints impacting other endpoints in the environment. Networks can be segmented in accordance with these boundaries.
• All network technologies that are introduced into an organisation’s environment should be designed with modern approaches to security and privacy, including the customisation of chosen protocols and ciphers.
• Organisations should invest in secure networking technology solutions that support their users’ operational behaviours, such as remote working and bring–your–own–device (BYOD), while considering how these behaviours may impact the security of software and data.

For more information on ASD-approved cryptographic protocols, please visit Guidelines for Cryptography.

Zero trust pillars: Applications & workloads

Organisations need to procure and develop software that is built with a security-first approach. Secure-by-design principles and tactics should be applied to all software that is used by the organisation. Software that is built with secure-by-design principles and practices is less likely to have exploitable weaknesses, which can reduce the likelihood of incidents occurring.

The following outline recommendations for implementing the secure-by-design software Foundation:

• Software that enables an organisation to analyse and implement technical policies should be secure and verified before use. This includes the software used to develop, store and implement access policies, as well as any software that provides information as an input to the authorisation model.
• Organisations should prioritise software that is compatible with their identity management solutions and authorisation model.
• Procurement teams should work closely with technical teams to determine the technical features and business requirements for new software. Software needs to be evaluated to ensure it can operate within an organisation’s environment, including automatic measurement against known secure baselines and security event logging to support incident response.
• Software that is used to deploy infrastructure and applications should be developed with the principles of immutability and idempotence. These characteristics will assist organisations in preventing weaknesses from being introduced to a system outside of approved change management decisions. The use of these principles will also assist in the recovery of systems after an incident has been recognised, by having the ability to quickly redeploy or reconfigure systems.
• Organisations should confirm that threat models are leveraged by manufacturers and have been utilised to mitigate the most likely cyber threats and weaknesses.
• Each application introduced into the organisation should be assessed prior to deployment to ensure it has been designed and built to be protected ‘out of the box’ against known prevalent cyber threats.
• Before procuring software, organisations should evaluate the manufacturer and/or vendor for risk associated with their security practices, their reputation and their ability to quickly and effectively secure their products.
• SecDevOps practices should be embedded in organisational processes. This includes ongoing training and upskilling of development and operations teams to keep up to date with software advancements and prevalent cyber threats.
• Development teams should be aware of risks within their software supply chains, including the generation and consumption of a software bill of materials (SBOM) to ensure third-party components have no known vulnerabilities.

For more information on choosing secure and verifiable technologies, please visit Choosing secure and verifiable technologies.

Zero trust pillars: All

Organisations need to perform assurance activities that enable decision makers in the governance structure to be able to make decisions on security actions and priorities.

The following outline recommendations for implementing the comprehensive assurance and governance Foundation:

• Organisational assurance activities should be developed and delivered in accordance with relevant industry and government regulations and standards, and the outcomes regularly reported to the appropriate level of senior management.
• Organisations should dedicate appropriately skilled resources and time to the initial and ongoing assurance and verification of the security and resilience of their systems.
• Systems should be regularly assessed for their resilience against current and emerging cyber threats and to quickly detect changes that impact the security posture of the organisation. Regular assessments include vulnerability scanning, penetration testing, control validation and user access reviews.
• Technical policies for access authorisation and security baseline requirements should be developed and stored on systems that are considered privileged, highly sensitive and hardened accordingly.
• Reviews and updates to policies based on cyber threat intelligence or changes in the environment should be regularly performed.
• Policies should be protected throughout their lifecycle, with monitoring applied to identify unauthorised changes, modifications or deletion actions.
• All new software and hardware should be assessed against approved and trusted assurance frameworks, including necessary technical governance and assurance testing.
• Assurance testing processes should be developed to be repeatable and automatable, to enable them to be run regularly with minimal human intervention.
• Outputs of assurance tests should be stored and protected from compromise and be consumable by an organisation’s authentication and authorisation models.

Zero trust pillars: All

Organisations need to monitor and respond to all identified and suspected security incidents in a timely and efficient manner, including through the automation of time-critical response actions.

The following outline recommendations for implementing the continuous and actionable monitoring Foundation:

• Monitoring systems should be configured with organisational knowledge to recognise behaviours and indicators that identify potential compromise, or likelihood that compromise could occur. The data sources used must have a high assurance of integrity to reliably inform both alerting and monitoring activities.
• The organisation should ensure that the development and configuration of automated response actions are done in accordance with the organisational risk appetite and tolerances. All actions that are triggered by automated response systems should be monitored for further impacts, and reverted if unforeseen outcomes are detected.
• Monitoring activities should be informed by up-to-date and trusted threat intelligence sources, including from services that automatically deliver new data.
• Threat intelligence data that includes indicators of compromise should be analysed against existing systems as soon as practical.
• Systems where an indicator of compromise is detected should be automatically managed according to organisational risk tolerances, including removing the system from the network or restricting user access until the incident can be investigated and remediated.
• When an incident is discovered, the response activities should be automated where possible to reduce the impact, such as the spread of malicious code, lateral movement of malicious actors, and the misuse of access privileges. By quickly responding through automation, an organisation can increase the chances of a quick recovery and return to normal operations.
• All endpoints and software in an organisation should have the capability to generate and communicate quality and high-fidelity signals about security events, including in logs, state, and system telemetry and behaviour.
• Organisations should seek out vendor and manufacturer advice on events and patterns of behaviour in their software and services that could be an indicator of compromise. This information should be implemented in the organisation’s security monitoring solutions and alerted on when detected.

For more information on monitoring and detection, please visit Guidelines for System Monitoring and Identifying and Mitigating Living Off the Land Techniques.