Technical Security Assurance and Digital Environments

Introduction

Technical security assurance is the disciplined process of obtaining and evaluating evidence that information systems, applications, infrastructure and digital services are designed, implemented and operated in accordance with defined security requirements. It is broader than vulnerability scanning and narrower than a general business audit: its concern is whether technical controls reduce cyber risk sufficiently, consistently and demonstrably.

Modern enterprises rarely have a single computing environment. They operate identity platforms, corporate networks, endpoints, databases, software pipelines, public clouds, containers, APIs, operational technology (OT) and Internet of Things (IoT) devices. These environments are interconnected, so a weakness in one domain can defeat controls in another. For example, strong database encryption does not compensate for excessive administrator privileges; a secure application can still be compromised through a vulnerable container image; and an isolated industrial network may become reachable through a poorly governed remote-maintenance account.

Security assurance therefore requires a systems view. It examines preventive, detective and corrective controls; technical configuration and operational practice; control design and operating effectiveness; and the relationship between security objectives, threats, assets and business consequences.

Learning Objectives

By the end of this chapter, the reader should be able to:

1. Assess identity and access management, networks, endpoints, cryptography, logging and databases.
2. Evaluate secure software development, DevSecOps, APIs, cloud services and containers.
3. Distinguish information-technology controls from OT and IoT security requirements.
4. Explain zero-trust architecture and its implications for assurance.
5. Design evidence-based assurance procedures and interpret their limitations.
6. Analyse governance, privacy, resilience, ethical and regulatory consequences of technical control decisions.

1. A Model for Technical Assurance

A useful assurance chain is:

Asset → Threat → Vulnerability → Control → Evidence → Residual risk

An asset may be a customer database, a production controller, an identity service or an API. A threat is a potentially harmful event or actor. A vulnerability is a condition that permits or increases the likelihood of exploitation. A control is a safeguard intended to prevent, detect or respond. Evidence is the observable information used to assess whether the control exists and operates effectively. Residual risk is the exposure remaining after controls are applied.

Assurance should test four questions:

• Design: Is the control logically capable of addressing the relevant risk?
• Implementation: Has it been deployed in the stated scope?
• Operation: Does it function consistently over time?
• Outcome: Does it produce the intended risk reduction?

A policy stating that privileged accounts must use multifactor authentication is evidence of design intent, not proof of implementation or operation. Stronger evidence includes identity-provider configuration, account inventories, authentication logs, exception records and sampled tests of actual administrative sessions.

The auditor should establish scope, identify system owners, understand data flows, define control criteria and assess evidence reliability. Evidence generated by the system under review can be valuable but may be incomplete or alterable. Independent corroboration, time-stamped exports, read-only access and reproducible tests improve confidence.

Control objectives and assurance criteria

A control objective describes the security result required. Examples include:

• Only authorised subjects can access regulated data.
• Network communications are restricted according to business need.
• Software changes are reviewed, tested and traceable.
• Security events are recorded, protected and investigated.
• Recovery mechanisms can restore critical services within approved tolerances.

Criteria may be derived from organisational policy, contractual obligations, regulatory requirements, recognised standards and system-specific threat models. No framework removes the need for professional judgement. A technically compliant environment may still be unsafe if the control is poorly scoped, bypassable or inconsistent with the organisation’s actual threat model.

2. Identity and Access Management

Identity and access management (IAM) governs digital identities, authentication, authorisation and accountability. It includes human users, service accounts, applications, devices and increasingly autonomous agents.

Core principles

Identification claims an identity; authentication verifies that claim; authorisation determines permitted actions; accountability links activity to a responsible identity. Authentication factors are commonly classified as knowledge, possession and inherence. Multifactor authentication (MFA) requires evidence from at least two independent factor categories; two passwords are not MFA.

Authorisation models include:

• Discretionary access control: resource owners grant permissions.
• Mandatory access control: centrally enforced classifications and clearances govern access.
• Role-based access control (RBAC): permissions are grouped into job roles.
• Attribute-based access control (ABAC): decisions use attributes such as user, resource, device posture, location and time.
• Policy-based access control: a policy engine evaluates contextual rules, often combining RBAC and ABAC.

Least privilege means granting only the access needed for an approved task, for the shortest reasonable duration. Separation of duties prevents one person from controlling incompatible stages, such as creating a supplier and approving payment. Just-in-time privilege, privileged access management, approval workflows and session recording reduce standing administrative exposure.

Assurance procedures for IAM

An assessor should reconcile the human-resources population, identity directory, application accounts and termination records. Useful tests include sampling joiner, mover and leaver events; reviewing dormant and shared accounts; examining privileged-role assignments; confirming MFA coverage; testing password-reset controls; and inspecting access recertification evidence.

Service accounts require particular attention. They should have named owners, limited permissions, managed credentials, rotation, monitoring and documented dependencies. Secrets embedded in source code or deployment files are a serious control failure. Federated identity reduces duplicated credentials but creates concentration risk: compromise of a central identity provider can affect many services.

3. Networks, Endpoints and Segmentation

Network assurance concerns architecture, traffic control, exposure and resilience. It includes firewalls, routing, wireless networks, remote access, DNS, proxies, network access control and segmentation.

A defensible design uses documented trust zones rather than assuming that internal traffic is safe. Typical zones include user endpoints, server networks, management interfaces, guest access, development environments, production systems and third parties. Segmentation is effective only when routing rules, administrative paths and monitoring enforce the intended boundaries.

Assessment should examine firewall rules for necessity, ownership, expiry and logging; verify that management interfaces are not exposed unnecessarily; test remote-access MFA and device posture; review wireless encryption and guest isolation; and compare approved network diagrams with observed traffic. Flat networks increase blast radius, while excessive micro-segmentation can create operational complexity and unreviewed exceptions.

Endpoint security combines secure configuration, patching, malware prevention, host firewalls, disk encryption, application control, vulnerability management and endpoint detection and response. Assurance should distinguish vulnerability presence from exploitability and business impact. A critical vulnerability on an isolated, unsupported device may demand urgent compensating controls, while a lower-rated weakness on an internet-facing identity service may be more consequential.

Patch metrics require careful interpretation. A high percentage of patched endpoints does not prove that critical assets are patched, that patches were effective or that vulnerable software was removed. Exceptions should have owners, deadlines, compensating controls and acceptance by an accountable risk owner.

4. Cryptography and Key Management

Cryptography supports confidentiality, integrity, authentication and non-repudiation, although no cryptographic mechanism alone proves the identity or trustworthiness of a business process.

Symmetric encryption uses one shared secret for encryption and decryption. It is efficient for bulk data. Asymmetric cryptography uses a key pair: a public key and a private key. It supports key exchange, digital signatures and identity mechanisms but is computationally more expensive. Hash functions map input to a fixed-length digest and are used for integrity checks and password-storage constructions; a hash is not encryption.

Assurance should evaluate:

• approved algorithms, modes and key lengths;
• authenticated encryption rather than unauthenticated confidentiality alone;
• certificate issuance, validation, renewal and revocation;
• protection of private keys and secrets;
• key generation, distribution, rotation, backup and destruction;
• encryption in transit, at rest and in backups;
• separation of duties for key administration;
• cryptographic agility for future algorithm changes.

Passwords should not be stored as reversible encryption or ordinary fast hashes. Password-verification systems should use a recognised password-hashing function with a unique salt and an appropriate work factor. Key management is often more important than selecting a nominally strong algorithm: a perfectly implemented algorithm is ineffective if keys are exposed, shared broadly or never rotated after compromise.

Cryptographic assurance must also consider availability. Loss of a decryption key can make business data unusable. Recovery keys and backup procedures therefore require controlled testing, not merely documentation. Organisations processing long-lived sensitive data should monitor developments in post-quantum cryptography and plan migration, especially where public-key algorithms protect information requiring confidentiality over many years.

5. Logging, Monitoring and Incident Evidence

Logging produces records; monitoring interprets records; detection engineering turns relevant events into alerts; incident response uses evidence to contain and recover. These are related but distinct functions.

A useful security event record normally includes time, source, subject, action, target, result and correlation information. Time synchronisation is essential for reconstructing events across systems. Logs should be protected against unauthorised alteration, access and premature deletion. Retention should reflect legal, investigative and operational needs rather than an arbitrary duration.

Assurance evaluates coverage, content, integrity, centralisation, alert quality and response. Important sources may include identity providers, endpoints, firewalls, cloud control planes, databases, applications, APIs and industrial systems. A logging control that records successful logins but not failed attempts, privilege changes or administrative actions may provide a misleading sense of visibility.

Security information and event management (SIEM) platforms aggregate and correlate events. They do not automatically create understanding. Excessive collection can increase cost and analyst fatigue; insufficient collection creates blind spots. Detection rules should have owners, severity logic, tuning records, escalation paths and periodic tests. Tabletop exercises and controlled simulations help determine whether alerts result in timely action.

Logs may contain personal data, credentials, health information or commercially sensitive content. Data minimisation, access control, masking and retention governance are therefore privacy and compliance requirements as well as security practices.

6. Database Security

Database assurance covers architecture, identities, query interfaces, configuration, data protection, resilience and monitoring. Controls include separate application and administrative accounts, least-privilege schemas, parameterised queries, strong authentication, network restriction, encryption, backup protection and tested recovery.

Injection risk arises when untrusted input changes the meaning of a query or command. Parameterised statements, safe APIs, input validation and appropriate output encoding reduce this risk. Input validation is not a substitute for safe query construction.

Assessors should review privileged database roles, dormant accounts, direct production access, sensitive-data discovery, row- or column-level controls, audit trails, backup locations and restoration tests. Database activity monitoring can identify unusual extraction or privilege escalation, but monitoring should be proportionate and integrated with response procedures.

Data masking and tokenisation reduce exposure in development and analytics environments. Replicated and cached copies are often forgotten in data inventories. Assurance must follow the data lifecycle: creation, use, sharing, retention, archival and destruction.

7. Secure Software Development, DevSecOps and APIs

Secure software development integrates security throughout requirements, design, coding, testing, deployment and maintenance. Threat modelling identifies assets, trust boundaries, abuse cases and security requirements before implementation. Secure design principles include least privilege, fail-safe defaults, complete mediation, defence in depth and secure failure handling.

A mature software assurance programme includes secure coding standards, peer review, software composition analysis, static and dynamic testing, secret detection, dependency management, infrastructure-as-code scanning and defect remediation. Automated tools are valuable but produce false positives and false negatives. Critical findings require human analysis and risk-based disposition.

DevSecOps embeds security controls into continuous integration and continuous delivery. A pipeline may verify signed commits, build provenance, dependency versions, test results, image vulnerabilities and deployment approvals. Pipeline credentials and runners are high-value targets; a compromised build system can distribute malicious software that appears legitimate.

Software bills of materials (SBOMs) improve component visibility but do not by themselves prove that components are safe, current or correctly used. Supply-chain assurance also requires trusted sources, reproducible or verifiable builds, vendor governance, vulnerability response and the ability to revoke or replace compromised components.

API assurance

APIs expose business functions and data directly. Assessment should cover authentication, authorisation at object and function levels, rate limiting, input validation, schema enforcement, error handling, transport security, inventory, versioning and abuse monitoring. A valid token does not imply permission to access every object. Broken object-level authorisation is therefore a common and serious failure.

API gateways can centralise policy, but controls must also exist in the service. Excessive data returned by an endpoint increases privacy and breach impact. Deprecated versions should be removed or isolated, and machine-to-machine credentials should be scoped, rotated and monitored.

8. Cloud Services and Containers

Cloud assurance is based on shared responsibility. The provider secures facilities and underlying services according to the service model, while the customer remains responsible for some combination of identities, configurations, data, workloads and applications. Responsibility varies among infrastructure, platform and software services and must be documented rather than assumed.

High-value cloud controls include central identity federation, strong MFA, separation of accounts or subscriptions, preventive policy-as-code, encryption and key governance, private connectivity where justified, secure storage permissions, immutable logging, backup isolation and continuous configuration assessment. Public exposure should be intentional, documented and periodically verified.

Cloud risks include excessive privileges, exposed storage, insecure security groups, unmanaged keys, opaque provider dependencies, weak tenant configuration and concentration risk. Assurance evidence may include provider attestations, customer configuration exports, control-plane logs, architecture diagrams and independent tests. A provider certificate does not prove that the customer configured its environment correctly.

Containers package applications and dependencies, but they do not create a security boundary equivalent to a virtual machine in every context. Risks include vulnerable base images, excessive runtime privileges, exposed container sockets, insecure orchestration configurations, image tampering and secrets in images. Controls include minimal trusted images, signed artifacts, non-root execution, read-only filesystems where feasible, restricted capabilities, network policies, admission controls, runtime monitoring and rapid image replacement.

Kubernetes and similar platforms require assurance of control-plane access, workload identity, namespace boundaries, admission policies, secrets handling, audit logs and upgrade processes. Ephemeral infrastructure makes traditional asset inventories insufficient; assurance must combine desired-state definitions with runtime observation.

9. Operational Technology and IoT

OT systems control or monitor physical processes. Their priorities often place safety, availability and deterministic operation ahead of confidentiality. Examples include industrial control systems, supervisory control and data acquisition systems, building controls and medical or laboratory devices. IT security practices cannot simply be copied into OT: aggressive scanning or untested patches can cause unsafe states or production interruption.

OT assurance should map process consequences, safety functions, communication paths, engineering workstations, remote access and vendor dependencies. Segmentation, unidirectional gateways where appropriate, allowlisting, controlled maintenance windows, offline recovery and carefully tested compensating controls are important. Legacy protocols may lack authentication or encryption, making architectural controls essential.

IoT environments add scale, constrained devices, heterogeneous vendors and long lifecycles. Baseline requirements include unique credentials, secure boot where feasible, signed updates, protected management interfaces, data minimisation, inventory, vulnerability disclosure channels and end-of-life planning. A device that cannot be patched should not be accepted without a documented risk treatment.

Ethically, safety-related systems demand a higher duty of care. Security testing must consider physical consequences, worker safety, public safety and environmental harm, not merely data loss.

10. Zero-Trust Architectures

Zero trust is an architectural approach, not a product and not the claim that trust is impossible. Its central idea is that access should not be granted merely because a subject is on a presumed trusted network. Decisions should be explicit, contextual, least-privileged and continuously evaluated.

A zero-trust policy decision commonly considers identity, device health, resource sensitivity, requested action, environmental context and threat signals. Policy enforcement points mediate access, while policy engines and administrators define and evaluate rules. Strong implementation requires reliable asset inventories, identity assurance, segmentation, telemetry and governance.

Zero trust improves containment and visibility but has limits. It cannot compensate for inaccurate inventories, compromised identity providers, poor application authorisation or unsafe endpoints. Continuous verification also raises privacy, availability and usability questions. Excessive friction may encourage workarounds, while automated denial can interrupt safety-critical operations. Architecture should therefore be risk-based and tested against failure modes.

Figure: A simplified assurance view of identity, policy, enforcement, resources and evidence in a zero-trust environment.

11. An Integrated Assurance Method

A postgraduate assurance engagement should combine architecture review, configuration assessment, interviews, observation, technical testing and evidence analysis.

1. Define scope and critical services. Identify business processes, systems, data, dependencies and safety implications.
2. Map trust boundaries and data flows. Include cloud services, APIs, third parties, administrators, backups and operational networks.
3. Create a control-risk matrix. Link each material risk to preventive, detective and corrective controls.
4. Assess design and implementation. Compare requirements with architecture and deployed configuration.
5. Test operation. Sample transactions, access events, changes, incidents, backups and exceptions over a defined period.
6. Evaluate evidence quality. Consider completeness, accuracy, authenticity, timeliness and independence.
7. Estimate residual risk. Consider likelihood, impact, exposure, control reliability and uncertainty.
8. Report actionable findings. State condition, criterion, cause, consequence, evidence and risk treatment.
9. Verify remediation. Retest the control and confirm that the underlying cause, not merely the symptom, was addressed.

Risk ratings should not be treated as mathematically precise unless the organisation has a validated quantitative model. Qualitative ratings are useful when definitions are consistent and assumptions are disclosed. Where quantitative analysis is used, expected loss is commonly represented as:

Probability is dimensionless; impact must use a defined unit such as currency, hours of outage or safety consequence. The expression is a simplified decision aid and assumes the probability and impact estimates are meaningful for the stated period and scenario. It does not capture interdependent events, uncertainty or nonlinear consequences by itself.

Illustrative Case: Meridian Health Services

Background

Meridian Health Services operates outpatient clinics, a cloud-hosted patient portal, diagnostic devices and a central electronic health-record database. Its security programme had recently adopted MFA and a zero-trust roadmap.

Problem

An assurance review found that MFA covered employees but not several vendor-maintained service accounts. The patient portal used an older API version, cloud storage permissions were managed separately by application teams, and diagnostic devices operated on a largely flat network. Logs existed but were retained inconsistently, and database restoration had not been tested for eighteen months.

Analysis

The control problem was not simply “missing MFA.” Identity weaknesses enabled vendor access; API weaknesses could expose patient objects; cloud misconfiguration could disclose backups; network flatness increased the effect of a compromised diagnostic device; and untested recovery created availability risk. These weaknesses were connected through shared dependencies and therefore had greater combined significance than isolated findings suggested.

Approach and solution

Meridian established named ownership for all service accounts, introduced short-lived vendor access with MFA and session logging, and placed privileged credentials in a managed vault. It retired the old API version, added object-level authorisation tests to the delivery pipeline and applied central cloud policies to storage resources. Diagnostic devices were segmented behind controlled gateways, with vendor maintenance restricted to approved windows. The organisation centralised security logs, defined alert ownership and performed a witnessed database restoration.

Outcome

The review did not conclude that risk had been eliminated. Instead, Meridian could demonstrate reduced standing privilege, improved traceability, narrower network exposure, stronger API assurance and verified recovery capability. Remaining risks were documented for unsupported devices and accepted temporarily by accountable clinical and technology leaders.

Learning points

1. Controls must be assessed across dependencies, not as isolated checklist items.
2. Identity governance is central to cloud, API, vendor and zero-trust security.
3. Recovery capability requires practical testing.
4. OT and medical-device controls must preserve safety and availability.
5. Assurance should communicate uncertainty and residual risk rather than claim absolute security.

Challenges, Ethics and Governance

Technical assurance is constrained by incomplete inventories, rapidly changing cloud resources, proprietary vendor systems, alert overload and limited specialist skills. Testing can itself create risk, particularly in OT, medical and safety-related environments. Written authorisation, rules of engagement, test windows, rollback plans and emergency contacts are essential.

Privacy must be integrated into monitoring and identity design. Collecting every possible event can create surveillance risks and breach consequences. Access reviews and behavioural analytics should be proportionate, transparent where legally required and governed by retention and purpose limitations.

Artificial intelligence can assist anomaly detection, code review, malware analysis and prioritisation. It can also amplify bias, produce opaque decisions, generate insecure code and create false confidence. AI-generated recommendations require human validation, protected training data, model access controls, provenance and testing against adversarial inputs. An automated risk score is not a substitute for accountable judgement.

Regulatory obligations differ by sector and jurisdiction, but common expectations include access control, auditability, privacy protection, incident reporting, resilience, supplier oversight and evidence of governance. Organisations should map obligations to controls and owners, while avoiding the assumption that compliance equals security.

Contemporary Directions and Best Practices

Current practice is moving toward continuous control monitoring, identity-centric architectures, software supply-chain provenance, confidential computing, passwordless authentication, infrastructure policy-as-code and post-quantum migration planning. These developments can improve assurance but introduce new dependencies and skills requirements.

Effective practice includes:

• maintain authoritative inventories of identities, assets, data and dependencies;
• make security requirements testable and linked to business risk;
• combine preventive controls with detection, response and recovery;
• use automation with human review and documented exceptions;
• protect logs, keys, pipelines and identity providers as crown-jewel services;
• test access revocation, incident response and restoration, not only normal operation;
• integrate security into procurement and supplier lifecycle management;
• design for safe failure in critical and physical environments;
• report residual risk in language decision-makers can act upon.

Chapter Summary

Technical security assurance evaluates whether controls are appropriately designed, implemented, operated and effective within interconnected digital environments. IAM establishes identity, authentication, authorisation and accountability; least privilege, separation of duties and just-in-time access reduce exposure. Network and endpoint assurance address segmentation, secure configuration, patching and detection. Cryptography depends not only on sound algorithms but also on disciplined key management and recoverability.

Logging and monitoring provide evidence and support detection, while database assurance protects data throughout its lifecycle. Secure software development and DevSecOps integrate threat modelling, code analysis, dependency governance, secrets protection and deployment controls. APIs require explicit object-level authorisation and lifecycle management. Cloud and container assurance must address shared responsibility, configuration drift, workload identity, image integrity and orchestration security.

OT and IoT require safety-aware, lifecycle-based controls suited to constrained or legacy environments. Zero trust replaces implicit network trust with explicit, contextual and continuously evaluated access decisions. Across all domains, credible assurance depends on evidence quality, risk-based testing, independent judgement, privacy protection, governance and verified recovery. The objective is not to claim perfect security but to make risk visible, manageable and demonstrably reduced.

Key Terms

Identity and access management: Governance of digital identities, authentication, authorisation and accountability.

Multifactor authentication: Authentication using evidence from at least two independent factor categories.

Least privilege: Restricting access to the minimum necessary for an approved task.

Separation of duties: Dividing incompatible responsibilities to reduce fraud and error.

Role-based access control: Assigning permissions through organisational roles.

Attribute-based access control: Making access decisions using subject, resource and contextual attributes.

Network segmentation: Dividing a network into controlled zones with restricted communication paths.

Endpoint detection and response: Monitoring and responding to suspicious endpoint activity.

Authenticated encryption: Encryption that provides confidentiality and an integrity/authenticity check.

Key management: Generation, protection, distribution, rotation, recovery and destruction of cryptographic keys.

Security information and event management: Aggregation and correlation of security events for monitoring and response.

Threat modelling: Structured identification of assets, threats, trust boundaries and security requirements.

DevSecOps: Integration of security practices into development and operations workflows.

Software bill of materials: An inventory of components and dependencies in a software product.

API: An interface through which software systems request functions or data.

Shared responsibility: Division of security duties between a cloud provider and its customer.

Container: A packaged application execution unit sharing an operating-system kernel with other workloads.

Operational technology: Systems that monitor or control physical processes.

Zero-trust architecture: An approach requiring explicit, contextual and least-privileged access rather than implicit network trust.

Residual risk: Risk remaining after controls are applied.

Review Questions

Short Answer Questions

1. Distinguish authentication from authorisation.
2. Why is key management as important as algorithm selection?
3. What is the purpose of network segmentation?
4. Why should an SBOM not be treated as proof that software is secure?
5. State two reasons why OT security cannot simply copy conventional IT patching practices.

Long Answer Questions

1. Explain how an auditor can assess the design and operating effectiveness of an IAM programme.
2. Compare RBAC and ABAC, including situations in which each may be appropriate.
3. Discuss the shared-responsibility model in cloud assurance and identify common customer-side failures.
4. Explain how DevSecOps changes security assurance compared with a traditional release process.
5. Analyse the benefits and limitations of zero-trust architecture for a geographically distributed enterprise.

Analytical / Application Questions

1. A company has MFA for employees but not for vendor service accounts, centralised logs with inconsistent time settings, and an untested database backup. Construct a risk-based assurance plan, prioritising evidence and tests.
2. A hospital connects diagnostic IoT devices to a production network because segmentation is considered too expensive. Analyse the security, safety and availability implications and propose compensating controls.
3. An organisation claims that its cloud provider’s compliance certificate proves that its cloud-hosted application is secure. Critically evaluate the claim and identify the additional evidence required.

Multiple Choice Questions with Answers

Question 1

Which activity provides the strongest evidence that an IAM control operates effectively?

A. Reviewing the organisation’s access-control policy

B. Confirming that a role is defined in the design document

C. Testing sampled joiner, mover and leaver events against actual directory changes

D. Interviewing a manager about the importance of access reviews

Correct Answer: C. Testing sampled joiner, mover and leaver events against actual directory changes

Question 2

Which statement correctly distinguishes a hash function from encryption?

A. A hash is normally designed as a one-way digest, whereas encryption is designed for reversible confidentiality

B. A hash always provides user authentication, whereas encryption never does

C. Encryption requires no keys, whereas a hash always requires two keys

D. A hash is used only for network segmentation

Correct Answer: A. A hash is normally designed as a one-way digest, whereas encryption is designed for reversible confidentiality

Question 3

What is the principal assurance concern with a flat network containing user endpoints and critical servers?

A. It prevents all logging from occurring

B. It increases the potential blast radius of a compromise

C. It guarantees that privileged access is separated

D. It makes encryption mathematically impossible

Correct Answer: B. It increases the potential blast radius of a compromise

Question 4

Which practice best supports secure software supply-chain assurance?

A. Disabling dependency updates permanently

B. Using unsigned third-party components from unknown sources

C. Maintaining component visibility and verifying artifact provenance

D. Allowing build pipelines to share administrator passwords

Correct Answer: C. Maintaining component visibility and verifying artifact provenance

Question 5

Under a shared-responsibility cloud model, which responsibility normally remains with the customer?

A. Physical security of the provider’s data centre

B. Maintenance of the provider’s power infrastructure

C. Configuration of the customer’s identities and storage permissions

D. Manufacture of the provider’s servers

Correct Answer: C. Configuration of the customer’s identities and storage permissions

Question 6

Which control most directly addresses broken object-level authorisation in an API?

A. Returning more fields in every response

B. Checking that the authenticated caller is authorised for the requested object

C. Removing all audit logs

D. Using a longer API URL

Correct Answer: B. Checking that the authenticated caller is authorised for the requested object

Question 7

Why do OT environments require special care when applying security patches?

A. OT systems never contain vulnerabilities

B. Patches can affect deterministic operation, safety or production availability

C. OT networks cannot contain any authentication mechanism

D. Patching automatically removes the need for segmentation

Correct Answer: B. Patches can affect deterministic operation, safety or production availability

Question 8

What is the central access principle of zero-trust architecture?

A. All internal network traffic is trusted by default

B. Access is granted permanently after the first successful login

C. Access is explicitly evaluated using identity, context and least privilege

D. Only perimeter firewalls are needed

Correct Answer: C. Access is explicitly evaluated using identity, context and least privilege

Question 9

If a loss scenario has an estimated probability of 0.02 and an impact of $500,000, what is its simplified expected loss?

A. $1,000

B. $10,000

C. $25,000

D. $500,002

Correct Answer: B. $10,000

Question 10

Which statement about logging is most accurate?

A. Collecting more logs automatically guarantees effective detection

B. Logs are useful only during compliance audits

C. Logs require appropriate coverage, time synchronisation, protection and response processes

D. Logs should always contain unrestricted personal information

Correct Answer: C. Logs require appropriate coverage, time synchronisation, protection and response processes