Secure Configuration, Hardening and Patch Management

Introduction

Database security is influenced not only by authentication, authorisation, encryption, and monitoring, but also by the way a database platform is installed, configured, maintained, and changed. A database may have strong access controls and still be exposed because a default administrative account remains enabled, an unnecessary network listener is active, a management interface is reachable from the internet, or a critical security update has not been installed.

Secure configuration and hardening reduce the attack surface of a database system. Patch management reduces exposure to known vulnerabilities. Configuration management ensures that security settings remain consistent over time, while validation provides evidence that the intended controls are actually operating. These activities are therefore central to preventive database security and to compliance with organisational, contractual, and regulatory requirements.

This chapter presents a practical framework for hardening database platforms, reducing exposed services, establishing secure baselines, managing patches and secrets, controlling changes, and validating configurations against recognised benchmarks.

Learning Objectives

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

1. Explain the purpose and principles of database hardening.
2. Identify unnecessary services, interfaces, accounts, and privileges that increase database exposure.
3. Develop and maintain a secure database configuration baseline.
4. Describe a risk-based patch-management lifecycle.
5. Apply sound practices for database secrets and cryptographic keys.
6. Explain how change control, configuration drift detection, and validation support security.
7. Use recognised benchmarks and evidence to assess database configuration.
8. Evaluate the operational, governance, and ethical implications of hardening decisions.

1. Configuration as a Security Control

A configuration is the collection of settings that determines how a database server, database engine, operating system, network interface, account, or security tool behaves. Examples include the network addresses on which a database listens, authentication modes, password policies, audit settings, encryption options, backup destinations, logging levels, and enabled extensions.

A secure configuration aims to achieve three related outcomes:

• Reduction of attack surface: fewer reachable services, protocols, ports, accounts, and features are available to an attacker.
• Secure operation: enabled functions use appropriate authentication, authorisation, encryption, logging, and resource controls.
• Repeatability: systems can be built and maintained consistently rather than relying on undocumented manual actions.

Hardening is the deliberate process of reducing unnecessary functionality and configuring necessary functionality securely. It is not the same as disabling everything. A database must continue to support legitimate business processes, availability requirements, administration, recovery, and monitoring. Excessive hardening can cause outages, prevent forensic investigation, or encourage staff to bypass controls.

A useful security principle is least functionality: enable only the services and features required for an identified business or technical purpose. This complements least privilege, which limits what an authenticated identity may do.

2. The Database Attack Surface

The attack surface includes all points through which a database can be reached, influenced, or abused. It extends beyond the database listener itself.

2.1 Network exposure

A database should generally be reachable only from trusted application servers, administration networks, monitoring systems, backup infrastructure, and other explicitly authorised systems. Direct exposure to the public internet is normally inappropriate for an internal data store.

Important controls include:

• placing the database in a protected network segment;
• restricting inbound traffic with firewalls or security groups;
• allowing only required source addresses and destination ports;
• disabling unused listeners and protocols;
• encrypting connections using an appropriately configured transport protocol;
• separating administrative access from application traffic; and
• restricting management interfaces to a controlled administration network or jump host.

A port-filtering rule is not a complete security control. It should be combined with identity-based authentication, network monitoring, host protection, and database authorisation. Network location alone should not establish trust.

2.2 Services, extensions, and features

Database products commonly provide optional services such as job schedulers, web consoles, remote procedure interfaces, replication endpoints, external data connectors, sample databases, debugging interfaces, and legacy compatibility protocols. Each enabled feature may introduce code, permissions, network exposure, or a new patching requirement.

Administrators should maintain an inventory of enabled components and document the business owner and purpose of each one. A feature with no current owner should be treated as a candidate for removal or disablement. Extensions must be obtained from trusted sources, kept current, and reviewed for the privileges they require.

2.3 Accounts and identities

Default accounts are common targets because their names, permissions, or behaviours may be widely known. Secure deployment should involve:

• disabling or removing unused default accounts;
• renaming accounts only where this contributes to security, without treating renaming as a substitute for strong authentication;
• preventing shared administrative accounts;
• using individual, attributable administrator identities;
• integrating with a central identity provider where appropriate;
• requiring multi-factor authentication for privileged access; and
• reviewing service accounts and their permissions regularly.

Service accounts should be non-interactive where possible, have narrowly scoped privileges, and use managed credentials rather than manually copied passwords.

2.4 Operating system and storage exposure

The database inherits risks from its host operating system, virtual machine, container, cloud service, storage platform, backup system, and orchestration tools. Hardening must therefore include file permissions, administrative interfaces, operating-system patching, endpoint protection, time synchronisation, disk encryption, and secure disposal of temporary files.

Database files, transaction logs, exports, diagnostic dumps, and backups can all contain sensitive information. Protecting only the live database is insufficient.

3. Establishing a Secure Baseline

A secure baseline is a documented, approved set of configuration requirements for a defined database platform and operating context. It provides a target state against which deployed systems can be assessed.

A baseline should identify:

A baseline must be specific enough to test. “Use secure authentication” is a principle, not a testable requirement. A better statement identifies the permitted authentication method, its scope, its exceptions, and the evidence required.

3.1 Baseline development process

A practical process is as follows:

1. Define scope. Identify database products, versions, operating systems, cloud services, environments, and data classifications.
2. Identify requirements. Consider business availability, application compatibility, privacy obligations, contractual controls, and internal policy.
3. Select authoritative guidance. Use vendor security guides, recognised benchmarks, industry standards, and organisational architecture requirements.
4. Assess applicability. Not every benchmark recommendation is suitable for every deployment. Record exceptions and compensating controls.
5. Test safely. Apply changes in a development or staging environment before production implementation.
6. Obtain approval. Security, operations, application, and data owners should review the proposed baseline.
7. Implement reproducibly. Use documented procedures, configuration management, or infrastructure-as-code where possible.
8. Validate and maintain. Reassess after upgrades, architectural changes, new threats, and benchmark revisions.

3.2 Secure baseline versus hardened image

A baseline specifies the required state. A hardened image is a prepared operating-system or database installation that implements much of that state. Images improve consistency, but they can become unsafe if they contain obsolete packages, embedded credentials, expired certificates, or undocumented assumptions. Images must therefore be versioned, scanned, approved, and rebuilt regularly.

3.3 Exceptions

A legitimate exception may be necessary because an older application depends on a protocol, a replication design requires a particular port, or a performance requirement conflicts with a logging recommendation. An exception should record:

• the affected asset and control;
• the business justification;
• the risk created;
• compensating controls;
• an owner and expiry or review date; and
• approval by an authorised risk owner.

Permanent, undocumented exceptions are effectively ungoverned configuration.

4. Database Hardening Controls

4.1 Authentication and authorisation

Authentication establishes identity; authorisation determines permitted actions. Hardening should separate these functions and avoid relying on implicit trust.

Recommended practices include using central identity management, enforcing MFA for privileged administration, restricting administrative roles, separating database administration from application ownership, and reviewing role membership. Application accounts should not normally be database superusers. They should have only the permissions necessary to execute required queries, procedures, or transactions.

Object ownership should be controlled because ownership may confer powerful rights. Ownership and administrative privileges should not be assigned casually to application accounts.

4.2 Secure defaults and dangerous functionality

Unused sample schemas, demonstration users, legacy protocols, unrestricted scripting features, external command execution, and broad administrative interfaces should be removed or disabled where they are not required. If a feature is required, it should be restricted, monitored, and included in patch and test processes.

4.3 Logging and auditing

A hardened database must provide sufficient audit information to detect misuse and support investigation. Depending on the environment, this may include successful and failed authentication, privilege changes, account changes, schema modifications, sensitive-data access, backup activity, and administrative commands.

Logging must be balanced. Excessive logging can affect performance, increase storage costs, and expose sensitive values. Audit records should be protected from ordinary administrators where feasible, forwarded to a separate security monitoring system, time-synchronised, and retained according to legal and business requirements.

Audit logs should not record plaintext passwords, private keys, or unnecessary sensitive data. Log access itself should be controlled and audited.

4.4 Encryption and certificate management

Connections containing credentials or sensitive data should use authenticated encryption through a supported transport protocol. Certificates must be issued by trusted authorities, have appropriate names and purposes, be protected from unauthorised use, and be renewed before expiry.

Encryption at rest should cover database files, temporary files where practical, transaction logs, exports, and backups. Encryption does not remove the need for access control: an attacker who obtains an active database key or authorised session may still access plaintext.

Keys should be stored separately from the data they protect, preferably in a managed key-management or hardware-security service. Key access, rotation, backup, recovery, and destruction must be governed. Loss of a key may make data unrecoverable; uncontrolled key access may make encryption ineffective.

4.5 Backups and recovery

Backups are security-sensitive copies. They should be encrypted, access-controlled, monitored, protected against unauthorised deletion, and tested through restoration exercises. The backup account should not automatically have unrestricted access to production data or administrative functions.

Hardening must consider recovery operations. A backup that cannot be restored securely, or a recovery environment that uses weak default credentials, can undermine the security of the production system.

5. Secrets Management

A secret is confidential authentication or cryptographic material, including passwords, API tokens, connection strings, private keys, certificates with private keys, and recovery codes.

Secrets should not be embedded in source code, database scripts, container images, spreadsheets, tickets, or unencrypted configuration files. A preferred design is:

1. an application authenticates to a secrets-management service using a workload identity;
2. the service authorises access to a narrowly scoped secret;
3. the application retrieves the secret securely at runtime; and
4. access is logged, rotated, and revoked when no longer required.

Secret rotation should be designed rather than improvised. Systems may require overlapping old and new credentials during a controlled transition. Rotation must account for connection pools, replicas, scheduled jobs, backup agents, monitoring tools, and emergency recovery procedures.

Password hashing is appropriate for passwords that must be verified, because a verifier can be stored instead of the password. Encryption is appropriate where a system must recover the original secret. These are different requirements and should not be confused. Database encryption keys should not be stored in the same unrestricted database tables as the encrypted data.

6. Patch and Vulnerability Management

A patch is a vendor-supplied update that may correct security vulnerabilities, defects, compatibility issues, or performance problems. Patch management is the controlled process of identifying relevant updates, assessing risk, testing, deploying, and verifying them.

A mature lifecycle includes:

1. Asset inventory: know which products, versions, editions, extensions, and operating systems exist.
2. Advisory monitoring: obtain information from vendors, security authorities, and vulnerability-management tools.
3. Applicability assessment: determine whether the vulnerability affects the deployed configuration and whether exploitation is plausible.
4. Risk prioritisation: consider severity, exploit availability, exposure, data sensitivity, business criticality, and existing mitigations.
5. Testing: assess application compatibility, performance, replication, backup, recovery, and failover.
6. Scheduling: define deployment windows and communicate possible impact.
7. Implementation: use approved procedures, staged rollout, and rollback or recovery plans.
8. Verification: confirm the installed version, service health, security settings, and application functionality.
9. Evidence and closure: update records, document exceptions, and rescan where appropriate.

Patch urgency should be risk-based rather than determined by severity alone. A critical vulnerability on an internet-reachable management service may require emergency action. A similarly rated issue on an isolated, unsupported test instance may require a different operational response, although it should not be ignored.

6.1 Testing and rollback

Testing should reflect realistic dependencies. A database patch can affect drivers, stored procedures, query plans, extensions, replication, backup agents, and high-availability mechanisms. A rollback plan may involve uninstalling a patch, restoring a snapshot, failing over to a patched replica, or restoring from backup. The safe method depends on the product and deployment architecture and must be tested before an emergency occurs.

A rollback plan is not a substitute for backups. Backups and recovery procedures should be available independently of the component being patched.

6.2 Unsupported software

An end-of-support database may no longer receive security fixes. Options include upgrading, migrating, isolating, replacing, or obtaining a formally governed extended-support arrangement. Network isolation reduces exposure but does not remove vulnerabilities or insider risk. Unsupported software should have an owner, a replacement plan, and documented interim controls.

7. Change Control and Configuration Drift

A secure setting can become insecure through an emergency fix, vendor installer, troubleshooting action, cloud-console change, or unauthorised modification. Configuration drift is the divergence of a system from its approved baseline.

Change control should classify changes according to risk. Normal changes require assessment, testing, approval, implementation, and review. Emergency changes may be implemented rapidly to reduce immediate danger but must still be recorded and reviewed afterwards. Standard, repeatable low-risk changes may be pre-approved if their scope and procedure are clearly defined.

Useful controls include:

• version-controlled configuration files;
• peer review of infrastructure and database scripts;
• separation of development, testing, and production permissions;
• automated deployment pipelines with approval gates;
• immutable or reproducible infrastructure where practical;
• scheduled configuration scans; and
• alerts for unauthorised changes.

Automation reduces manual inconsistency but can amplify mistakes. Scripts should be tested, protected from unauthorised modification, and designed to avoid exposing secrets in output or logs.

8. Validation Against Recognised Benchmarks

Validation compares an observed configuration with an approved requirement or benchmark. Recognised sources may include vendor security guides, the CIS Benchmarks, NIST guidance, ISO/IEC 27001-aligned organisational controls, and applicable sector requirements. These sources should be used intelligently: a benchmark is a valuable starting point, not an automatic substitute for risk assessment.

A validation test should specify:

• the control statement;
• the asset and version in scope;
• the expected setting;
• the evidence source and collection method;
• the result: pass, fail, not applicable, or exception;
• the risk and remediation owner; and
• the date and assessor.

For example, “the database must not listen on an unapproved network interface” can be tested by examining listener configuration, active sockets, firewall rules, and network paths. A configuration-file value alone may be insufficient because an inherited setting, runtime override, or external proxy could change actual exposure.

Validation should include both automated and manual assessment. Automated tools provide scale and repeatability, while manual review is necessary for context, compensating controls, business justification, and evidence quality.

False positives and false negatives are possible. A scanner may report a secure setting as non-compliant because it cannot interpret an exception, or it may miss a risky external dependency. Findings should therefore be investigated rather than accepted blindly.

9. Measuring Security and Operational Performance

Metrics support decision-making but can be misleading if treated as objectives without context. Useful measures include:

• percentage of database assets with an identified owner;
• percentage meeting the approved baseline;
• number and age of critical configuration findings;
• percentage of critical patches deployed within the required period;
• time from vulnerability identification to remediation;
• number of unauthorised configuration changes;
• percentage of backups successfully restored in tests; and
• number of expired or unmanaged certificates and secrets.

A high compliance percentage may conceal a small number of highly critical failures. Metrics should therefore be segmented by risk, exposure, data sensitivity, and business criticality.

10. Applied Case: Hardening a Retail Payment Database

The following is an illustrative case.

Background

A medium-sized retailer operates a customer-order database and a payment-authorisation database. A review finds that the payment database is reachable from several office subnets, uses a shared administrator account, stores a connection password in an application configuration file, and has not been patched for eight months. Audit logging is enabled locally but is not forwarded to the security monitoring platform.

Problem

The organisation faces unnecessary network exposure, poor accountability, credential disclosure risk, delayed vulnerability remediation, and limited ability to investigate suspicious activity. Immediate changes could also affect payment processing, so careless hardening might create an outage.

Analysis

The security team classifies the payment database as high criticality and identifies its dependencies: two application clusters, a reporting service, a backup agent, a replication partner, and a managed payment gateway. The team confirms that office users do not require direct database access. A vendor advisory also identifies a vulnerability in the installed database version that may allow privilege escalation after authentication.

Approach and solution

The organisation first establishes a protected administration path through a jump host and restricts database traffic to the application clusters, backup system, monitoring platform, replication partner, and administration network. Office-subnet access is removed after testing.

Individual administrator identities are created and linked to MFA. The shared administrator account is disabled after confirming that no service depends on it. The application account is reduced from a broad administrative role to permissions on specific stored procedures and required tables.

The connection password is moved to a secrets-management service. A controlled rotation procedure is tested against application connection pools and the backup agent. Transport encryption is enforced, and certificates are placed under an expiry-monitoring process.

The database patch is tested in a staging environment with representative transactions, replication, backup, and failover. It is then deployed first to a replica, followed by controlled failover and patching of the former primary. Audit records are forwarded to the security monitoring platform, with sensitive values excluded from logs.

Finally, the team creates a baseline containing approved listeners, authentication requirements, role memberships, encryption settings, patch level, audit destinations, and exception procedures. A monthly automated scan and quarterly manual review are scheduled.

Outcome

The database no longer accepts unnecessary office traffic, administrative actions become attributable, the application secret is no longer stored in a configuration file, and the identified vulnerability is remediated. The organisation also gains evidence for compliance and a repeatable process for future changes. The case demonstrates that hardening is a coordinated operational programme rather than a single configuration edit.

Learning points

1. Network restriction should be based on actual dependency analysis.
2. Shared privileged accounts weaken accountability and incident response.
3. Secrets management must include rotation and dependency testing.
4. Patch deployment requires application and recovery testing.
5. Baselines and continuous validation prevent security improvements from silently degrading.

11. Governance, Ethics, and Professional Practice

Hardening decisions affect availability, privacy, accountability, and the rights of system users. Security professionals should not disable services without understanding their operational purpose, and they should not collect more audit data than is necessary and lawful.

Monitoring and audit records may contain personal information. Access to them should be restricted, retention should be justified, and use should comply with applicable privacy and employment requirements. Administrators must protect credentials and avoid using production data in testing unless it has been appropriately masked or otherwise authorised.

Changes should be transparent to affected stakeholders. Concealing known weaknesses, bypassing approval for convenience, or treating compliance evidence as more important than actual protection are professionally irresponsible practices. Risk acceptance should be made by an authorised owner with sufficient information, not silently transferred to users or technical staff.

12. Contemporary Developments and Limitations

Cloud database services increasingly provide managed patching, automated backups, identity integration, and policy enforcement. These capabilities reduce some operational burden but do not eliminate shared-responsibility obligations. Customers remain responsible for identities, data classification, network policies, application permissions, secrets, and configuration choices.

Infrastructure-as-code and policy-as-code can make baseline requirements testable before deployment. Continuous compliance platforms can detect drift quickly, while machine-learning systems may help prioritise vulnerabilities by correlating asset exposure, exploit intelligence, and business criticality. Such tools require human oversight because inaccurate asset inventories, poor training data, and automated remediation errors can create outages or conceal risk.

Hardening also has limitations. It cannot compensate for compromised administrator identities, insecure application code, malicious insiders, or a lack of recovery capability. Patching may introduce defects, benchmarks may not reflect local requirements, and encryption may be ineffective when keys are poorly governed. Defence in depth remains necessary.

Best-Practice Checklist

Before placing a database into production, verify that:

• the product and version are supported;
• an owner, data classification, and dependency inventory exist;
• unnecessary services, interfaces, accounts, extensions, and sample data are disabled or removed;
• network access is restricted to documented sources;
• privileged access uses individual identities and MFA where appropriate;
• application and service accounts have least privilege;
• secrets and keys are managed, rotated, and monitored;
• transport, storage, and backup protection meet policy requirements;
• audit events are defined, protected, and reviewed;
• backups and restoration procedures have been tested;
• patches have been assessed, tested, and verified;
• changes are approved and recorded; and
• the configuration has been validated against an applicable baseline or benchmark.

Chapter Summary

Secure configuration and hardening reduce the database attack surface by removing unnecessary functionality, restricting network exposure, controlling identities, protecting secrets, and configuring required services securely. A secure baseline converts broad security principles into specific, testable requirements and should be approved, versioned, reviewed, and adapted to the deployment context.

Patch management is a lifecycle involving inventory, advisory monitoring, risk assessment, testing, deployment, verification, and evidence. Patch urgency depends on exposure, exploitability, data sensitivity, and business impact, not severity alone. Secrets require controlled storage, access, rotation, and revocation. Backups, logs, certificates, and recovery environments must be hardened because they may contain or provide access to sensitive data.

Change control and drift detection preserve the approved security state. Validation against vendor guidance, recognised benchmarks, and organisational requirements provides evidence of compliance and reveals deterioration. Automated tools improve scale, but professional judgement is required to interpret exceptions, false results, operational dependencies, and ethical implications. Effective hardening is therefore a continuous, risk-based discipline integrated with architecture, operations, governance, and incident readiness.

Key Terms

Attack surface: The collection of points through which a system may be reached, influenced, or attacked.

Baseline: An approved and documented set of expected configuration requirements.

Benchmark: Published technical guidance used to assess or improve security configuration.

Change control: A governed process for assessing, approving, implementing, and reviewing changes.

Configuration drift: Divergence between an actual system configuration and its approved baseline.

Encryption at rest: Protection of stored data using cryptographic methods.

Hardening: Reducing unnecessary functionality and configuring required functionality securely.

Least functionality: Enabling only the features and services required for an identified purpose.

Least privilege: Granting an identity only the permissions necessary for its duties.

MFA: Multi-factor authentication using two or more independent authentication factors.

Patch: A vendor update that corrects vulnerabilities, defects, or other software problems.

Patch management: The lifecycle for identifying, assessing, testing, deploying, and verifying updates.

Privileged account: An account with elevated administrative or security-sensitive permissions.

Secure configuration: A configuration designed to minimise risk while supporting required operation.

Secret: Confidential authentication or cryptographic material such as a password, token, or private key.

Secrets management: Controlled storage, access, rotation, monitoring, and revocation of secrets.

Service account: A non-human identity used by an application, service, or scheduled process.

Configuration validation: Comparing observed settings and evidence with defined requirements.

Review Questions

Short Answer Questions

1. What is the difference between hardening and least privilege?
2. Why should a database baseline contain testable requirements rather than general statements?
3. Identify three types of database secrets that require protection.
4. Why is a patch rollback plan not a substitute for a tested backup and restoration process?
5. What is configuration drift?

Long Answer Questions

1. Explain how network segmentation, firewall rules, encrypted connections, and identity controls work together to protect a database.
2. Describe a complete risk-based patch-management lifecycle for a production database.
3. Discuss the advantages and limitations of using recognised database security benchmarks.
4. Explain how database administrators should manage service accounts, privileged accounts, and application accounts.
5. Describe how logging, auditing, backups, certificates, and secrets should be included in a database hardening programme.

Analytical / Application Questions

1. A database is reachable from an entire corporate network, although only two application servers use it. Analyse the risks and propose a staged remediation plan that minimises outage risk.
2. A critical patch is available, but testing reveals that an older reporting extension may fail after installation. Decide how the organisation should respond, including risk assessment, compensating controls, approval, and follow-up.
3. A compliance scanner reports that a database fails a benchmark because a required replication port is open. Explain how you would investigate whether the finding is valid, document the business need, and determine appropriate compensating controls.

Multiple Choice Questions with Answers

Question 1

What is the primary purpose of database hardening?

A. To enable every available database feature

B. To reduce unnecessary functionality and exposure while preserving required operation

C. To eliminate the need for authentication

D. To replace all database backups

Correct Answer: B. To reduce unnecessary functionality and exposure while preserving required operation

Question 2

Which practice best supports accountability for privileged database activity?

A. Using one shared administrator account

B. Allowing anonymous administration from the internal network

C. Using individual administrator identities with appropriate MFA

D. Storing administrator passwords in application source code

Correct Answer: C. Using individual administrator identities with appropriate MFA

Question 3

What should a secure configuration baseline provide?

A. A general statement that the system should be secure

B. An approved, documented, and testable expected configuration

C. A list of all possible database features

D. A guarantee that vulnerabilities can never occur

Correct Answer: B. An approved, documented, and testable expected configuration

Question 4

Which item is most appropriate for a secrets-management service?

A. A database connection password

B. A public product brochure

C. A non-sensitive database table name

D. A published software version

Correct Answer: A. A database connection password

Question 5

Which activity should occur before deploying a major database patch to production?

A. Delete all backups to prevent rollback confusion

B. Test application compatibility, recovery, and operational dependencies

C. Disable all monitoring permanently

D. Publish the administrative password

Correct Answer: B. Test application compatibility, recovery, and operational dependencies

Question 6

What is configuration drift?

A. The normal growth of a database table

B. The divergence of an actual configuration from its approved baseline

C. The encryption of a backup file

D. The replacement of a database administrator

Correct Answer: B. The divergence of an actual configuration from its approved baseline

Question 7

Why should database backups be treated as security-sensitive?

A. They never contain production information

B. They may contain recoverable copies of sensitive data

C. They cannot be accessed by administrators

D. They are automatically immune to ransomware

Correct Answer: B. They may contain recoverable copies of sensitive data

Question 8

Which statement about security benchmarks is most accurate?

A. Every recommendation must be applied without considering context

B. Benchmarks are useful guidance that must be assessed for applicability and exceptions

C. Benchmarks remove the need for testing

D. Benchmarks apply only to application source code

Correct Answer: B. Benchmarks are useful guidance that must be assessed for applicability and exceptions

Question 9

Which is the best description of least functionality?

A. Granting every user administrator privileges

B. Enabling only services and features required for an identified purpose

C. Installing every available extension

D. Allowing all network sources to connect

Correct Answer: B. Enabling only services and features required for an identified purpose

Question 10

Why should audit records usually be forwarded to a separate monitoring system?

A. To make logs easier for attackers to delete

B. To provide protected, centralised monitoring and investigation evidence

C. To prevent time synchronisation

D. To store plaintext passwords in a second location

Correct Answer: B. To provide protected, centralised monitoring and investigation evidence