Skip to content

Latest commit

 

History

History
161 lines (121 loc) · 3.32 KB

12-protecting_logs.md

File metadata and controls

161 lines (121 loc) · 3.32 KB
SPDX-FileCopyrightText SPDX-License-Identifier title author footer description keywords color class style
© 2023 Menacit AB <[email protected]>
CC-BY-SA-4.0
Logging course: Protecting logs
Joel Rangsmo <[email protected]>
© Course authors (CC BY-SA 4.0)
Introduction to protection of sensitive log data
logging
siem
course
#ffffff
invert
section.center { text-align: center; } table strong { color: #d63030; } table em { color: #2ce172; }

Protecting log data

CIA and privacy

bg right:30%


The basics

You're logs may contain juicy information that is of interest to adversaries.

Protection of their integrity is desirable and may be a (legal) requirement.

Besides regular system hardening, what else can we do?

bg right:30%


Data classification

Not all log events are created equal.

Proper tagging/classification of ingested sources aids enforcement of...

  • Access control
  • Retention policies
  • Backups

Preferably done by producer, if possible - make sure guidelines are available.

bg right:30%


Append-only / Write-once storage

Certain storage mediums, like tape, optical disks and special-purpose HDDs can prevent data manipulation after write.

"Write Once Read Many".

A resonable compromise could be to utilize external object storage like AWS S3 (with strict access permissions) or a hash-chain protected database such as immudb.

bg right:30%


Anonymization / Pseudonymization

The best way to handle storage of PII is to not.

Anonymization removes/replaces information that could be tied to an invidual/entity.

Pseudonymization works similarly, except that a "lookup table" exist to revert the process if needed.

Preferably done by producer, if possible.

bg right:30%


Data scrubbing

Logs may contain secrets like passwords, API keys/tokens and credit card numbers, especially from applications configured in "debugging" mode.

By configuring "search-and-replace" rules for known patterns, this sensitive information may be automatically removed.

As previously mentioned, preferably performed by the log producer.

(Reducing verbosity reduce retention cost)

bg right:30%


Availability

Can you access your logs during an attack or outage to investigate the incident?

What dependencies exist on networking infrastructure, centralized storage, authentication providers, etc?

May be a decent reason for outsourcing hosting to a third-party.

bg right:30%


Conclusions

bg right:30%