Accountability¶

When an authenticated user exercises their authorised rights in an information system, it is important for security that they are accountable for their actions. Although there are psychological or “soft” aspects—such as what makes a deterrent effective or what evidence would be required in court—this module focuses on the technical viewpoint: how evidence is collected, protected and analysed.

Accountability

A security objective requiring that the actions of an entity (e.g. user, system, device) are individually traceable to that entity. This functions as a deterrent and supports non-repudiation, fault isolation, intrusion detection and prevention, post-incident recovery and legal actions when necessary.

Non-repudiation

means the existence of non-forgeable evidence that a certain action has occurred.

Services related to accountability rely on tamper‑resistant event records—that is, evidence. (For various degrees of security against tampering; see hardware matters). Collected evidence can be used as input in technical investigations attempting to determine how an attack was carried out and to identify its effects. Evidence may also support disciplinary actions in situations where individuals have violated rules. Privacy laws may impose restrictions on recorded events, and recorded events may reduce privacy in unexpected ways.

Technical aspects (advanced)¶

Accountability supports audit processes on various levels. Administrative auditing checks whether an organisation’s operations comply with existing rules. Technical auditing scans logs for signs of attacks. A process may also be triggered by a security event or a full‑scale incident. Investigation seeks to identify the exploited vulnerabilities and/or responsible parties.

Practices for collecting evidence (advanced)¶

Audits and investigations use event logs (or just ’logs’, or audit logs). A log is a systematically maintained journal in which entries of specific types of events are added in chronological order. Logs may be produced by the operating system, network devices and applications. Logs are important for understanding how an unusual situation arose—even if it was not a malicious security incident. Logged events depend on the activity being monitored.

Accountability is only as strong as the quality of evidence collected during operation. System administrators can set audit policies defining which events are logged. Examples include successful and failed authentication attempts and decisions related to sensitive access requests. Both operating systems and dedicated auditing tools help administrators configure log collection. Access-control policies may mandate logging for certain types of access requests.

Preserving evidence (advanced)¶

Attackers may attempt to hide their tracks by deleting log entries after gaining sufficient privileges. They may then alter audit policies so their future actions are not recorded. Evidence already collected must be resistant to tampering.

Tamper resistance can be achieved through physical means such as printing logs onto a continuous paper roll or writing logs to WORM (Write-Once, Read-Many) media such as optical discs. Cryptography can reinforce tamper resistance. If logs are stored in a hash chain, any deletion is detected immediately—but the hash chain itself cannot prevent deletion.

Audit policies must account for situations where logging is disrupted, e.g. when log storage becomes full. Should old entries be overwritten, or should the system halt until proper auditing can continue? These trade-offs between availability and accountability should be addressed when policies are defined.

Analysing evidence (advanced)¶

Audit logs generate large amounts of data. Many entries are irrelevant for security, so automated processing is needed. Known attack patterns can be detected by their signatures—fingerprint-like behavioural traces, such as specific procedure calls or network packets in particular sequences (these signatures are unrelated to cryptographic signatures). Machine‑learning techniques may help detect anomalies. Visualisation helps administrators focus on the most important events.

Assessing evidence (advanced)¶

For legal or disciplinary actions, accountability is only as strong as user authentication. This concerns not only technical aspects of authentication but also users’ ability to resist phishing and manipulation attacks. Telling users not to fall for obvious phishing attempts is easy—but well‑crafted targeted phishing is not obvious.

Ensuring accountability requires strong organisational policies forbidding the connection of external devices (e.g. USB tokens) to internal systems and limiting access to external websites. Accountability can also be weakened by poor defence against software vulnerabilities that allow attackers to run code under a user’s credentials without the user’s knowledge—for example, drive‑by download attacks.

Privacy and accountability (advanced)¶

Privacy rules can affect which events may be recorded. Law may restrict how precisely an employer may monitor employees, potentially making it harder to hold individuals accountable when rules are violated. In addition to the General Data Protection Regulation, employee monitoring is governed in Finland by the Act on the Protection of Privacy in Working Life (759/2014 in Finnish/Swedish only).

Sometimes technical solutions can reconcile conflicting objectives. For example: employers often are not allowed to log the external websites employees visit. However, if such a site is attacked from inside the organisation, the perpetrator must be identifiable. One solution is that the gateway logs only the internal IP address and port visible externally—without recording the website visited. If an attack occurs, the target site can provide the source port, linking it to the internal IP.

Logging can also have unintended privacy impacts. An example is Certificate Transparency [RFC 9162], a log service for TLS certificate authorities. Participating CAs log issued certificates. Domain owners can detect mis‑issued certificates. The system was introduced (2013) in response to attacks leveraging mis‑issued certificates and increases CA accountability. However, private subdomains created for internal use may also be logged, unintentionally revealing their existence.

Distributed logs (advanced)¶

Logs may be used to hold both users and system owners accountable. For the latter, auditors may require the logging device to be sealed. Instead of tying trust in log integrity to a physical root of trust, logs may be distributed. If logs are written and stored on independent nodes of a distributed system, tampering requires controlling a large coalition of nodes—typically infeasible.

Log-maintaining nodes must synchronise their log versions. Synchronisation depends on node and network fault models and membership rules. Systems may be open to all or controlled via a membership service. Recent interest in blockchains extends to this type of log solution.