Skip to content

SC.05 — System Hardening and Configuration#

System: AI Connectors Platform Last updated: 2026-04-29

This document describes how the AI Connectors platform fulfils the SC.05 control category.

Control Attestation Table#

Control Description Status Evidence
CTRL0537508 — SC.05.01 Disable or remove unnecessary services and features Compliant Container images use minimal python:3.13-slim base; no unnecessary software installed; ECS Fargate has no shell access; network isolation via security groups; default credentials not applicable (Azure AD OAuth). See operation-maintenance.md § 4.6.
CTRL0537517 — SC.05.02 Use a Novo Nordisk hardening guideline Compliant Development follows Novo Nordisk coding standards (SOP Computer Systems Coding Standard) and OWASP secure MCP development guide. See operation-maintenance.md § 4.4 and security review processes.
CTRL0537495 — SC.05.03 Continuous system hardening — regular vulnerability scans and risk-based penetration testing Compliant Snyk SCA runs on every CI build scanning all Python dependencies and Terraform IaC for known CVEs. OS-level scanning is not applicable (ECS Fargate — no OS to manage). DAST and pen testing assessed as low priority due to stateless proxy architecture and Azure AD-delegated authentication. See vulnerability-patch-management.md.
CTRL0537532 — SC.05.04 Configure inactive sessions to time out Compliant OAuth token cache TTL follows Azure AD token expiry (1 hour access tokens, 24 hour refresh tokens); DynamoDB cache implements automatic expiration; no custom session management. See operation-maintenance.md § 4.6.
CTRL0537521 — SC.05.06 Ensure that time is synchronised Compliant ECS Fargate tasks automatically sync time with AWS infrastructure NTP; CloudWatch Logs use server-side timestamps (UTC); audit logs include ISO-8601 timestamps. See operation-maintenance.md § 4.6.

Security Controls Reference#

CTRL0537508 — SC.05.01: Disable or remove unnecessary services and features#

Control Text: Disable or remove unnecessary security risks by: (i) changing, deleting or disabling default credentials/passwords; (ii) removing unnecessary software and functionality; (iii) removing unnecessary usernames/logins; (iv) disabling or removing unnecessary services (such as Java and web services); (v) disabling network access to all unnecessary network resources, including the Internet.

Applicability: Basic IT security requirement.

Additional Description

These system hardening actions reduce the attack surface and minimise unnecessary security risks. If it is not possible to mitigate risks by performing the actions described above, implement compensating controls such as physical entry controls and/or network isolation.

It is recommended to implement acknowledged best-practice secure configuration as maintained by the software vendor, IT service provider, or other credible domain expert.

Detailed Description

The platform minimises attack surface through minimal container images, network isolation, and Azure AD OAuth. All containers use multi-stage Docker builds from python:3.13-slim base images with no package managers, compilers, or SSH access in production. Network security groups restrict inbound traffic to port 80 from the ALB only, and outbound connectivity is limited to Azure AD, Microsoft Graph, and AWS services. Authentication is handled exclusively via Azure AD OAuth 2.0 with no default credentials or hardcoded secrets — all secrets are injected at runtime from SSM Parameter Store.

Implementation Considerations

CTRL0537517 — SC.05.02: Use a Novo Nordisk hardening guideline#

Control Text: Use a Novo Nordisk guideline for secure development or configuration of the specific IT Solution or component if such a guideline exists, or use a vendor or industry best practice.

Applicability: Basic IT security requirement.

Additional Description

For guidelines on managing IT solution development, see "Manage design and development of IT systems - Guideline" on the Development section of the IT&Q Portal. For Novo Nordisk coding best practices, see "SOP Computer Systems Coding Standard" on ITQ.

Additionally, refer to OWASP resources for best practices on various IT components.

Detailed Description

The platform follows OWASP best practices including the OWASP Secure MCP Development Guide, which is reviewed periodically via automated security review skills. Static security controls are enforced in CI/CD pipelines through automated linting (ruff and black), Snyk Code SAST scanning for vulnerabilities, and Snyk IaC scanning for Terraform misconfigurations. All pull requests require code review covering authentication flows, input validation, error handling, and IAM permissions before merging.

Implementation Considerations

CTRL0537495 — SC.05.03: Continuous system hardening through vulnerability scanning#

Control Text: Ensure continuous system hardening by conducting regular vulnerability scans and assess the need for supplementary penetration testing based on a risk-based approach.

Applicability: The IT solution is not on PSNet TierX or PSNet DMZ Tier1 or PS Tier1.

Additional Description

Vulnerability scanning should cover all applicable layers:

  • OS-level scans — target the underlying OS for missing patches, outdated software, and configuration weaknesses
  • Application scans (SAST/SCA/DAST) — Static Application Security Testing, Software Composition Analysis, and Dynamic Application Security Testing for application-layer vulnerabilities such as SQL injection and XSS
  • Network scans — assess firewalls, routers, open ports, and unsecured network services

In addition to routine scans, perform a risk assessment to determine the necessity and frequency of penetration testing. Penetration testing should be considered for systems with high criticality, significant potential impact of a breach, or elevated exposure to threat actors.

Detailed Description

Snyk SCA runs on every CI/CD build scanning all Python dependencies and Terraform IaC configurations for known CVEs and misconfigurations, with critical/high findings blocking deployment. OS-level scanning is not applicable — the platform runs exclusively on AWS ECS Fargate, where AWS owns the host OS under the Shared Responsibility Model. DAST and penetration testing are assessed as low priority given the stateless proxy architecture, delegated authentication via Azure AD, and absence of internet-exposed databases or custom session management. A penetration test is recommended as the platform matures or if write operations are introduced.

Implementation Considerations

CTRL0537532 — SC.05.04: Configure inactive sessions to time out#

Control Text: Configure inactive sessions to time out after a given time period.

Applicability: Basic IT security requirement.

Additional Description

IT solutions should enforce time-out functionality that balances the risks of unauthorized usage with the required operational flexibility. When determining the appropriate time-out period, consider:

  • User role and permissions: An end-user on a website poses less risk than an administrator on the same website.
  • Physical access controls: A computer in a production facility with strict access controls is less likely to be misused than a laptop used in a public location.
  • Operational flexibility: A device used in a sterile room where frequent re-authentication impairs operations warrants a longer time-out.

Novo Nordisk generally adopts a 15-minute time-out as a standard configuration.

Detailed Description

Session timeout is enforced through Azure AD token expiry with no custom session cookies or application-level state. Every API request must include a valid Azure AD Bearer token with a typical 1-hour TTL, validated by the OBOAuthenticator on every request. Resource-specific access tokens obtained via the OAuth 2.0 On-Behalf-Of flow are cached in DynamoDB with TTL attributes matching token expiry, and DynamoDB automatically deletes expired entries. Platform operator access sessions are time-bound via AWS SSO (12-hour max) and Azure AD PIM (8-hour activations).

Implementation Considerations

CTRL0537521 — SC.05.06: Ensure that time is synchronised#

Control Text: Ensure that time is synchronised with a consistent and accurate time source, such as using the Novo Nordisk NTP standard.

Applicability: Basic IT security requirement.

Additional Description

Accurate timekeeping is important for both GxP-critical business processes and IT security forensics, which rely on accurate log timestamps to react to security events. Novo Nordisk requires use of a centrally managed time source for network-connected equipment.

Two primary synchronisation methods:

  • Windows Time Service: Used when a Microsoft server or workstation is joined to the domain. Time is updated automatically — no additional configuration needed.
  • NTP: Used for Linux, network devices (firewalls, routers, switches), and servers not joined to a domain. Must be configured manually. Contact the helpdesk of the infrastructure operator for the IP address and FQDN of the authorised NTP server.

For additional information, see "Time Keeping at Novo Nordisk - Guideline" on the Manage IT Risks section of the IT&Q Portal.

Detailed Description

Time synchronisation is achieved automatically through AWS Fargate's built-in integration with the Amazon Time Sync Service, which synchronises all ECS Fargate task clocks with AWS NTP infrastructure to within milliseconds of UTC. CloudWatch Logs applies server-side UTC timestamps to all log events, and application audit logs use ISO-8601 UTC timestamps derived from the Fargate task's synchronised system clock. This accurate timekeeping is critical for JWT token validation, where the OBOAuthenticator validates Azure AD token expiry claims against the current system time, preventing authentication bypass due to clock drift.

Implementation Considerations