System in use
Running a SOC and SIEM in line with data protection law
A system for evaluating security events processes large volumes of data about the conduct of staff, as a side effect of its purpose. Two interests therefore meet, namely the security of operations and protection against monitoring of conduct. Both can be reconciled where evaluation is tied to a defined procedure.
What the system processes
A SIEM collects events from servers, network components, applications and endpoints. The great majority of those events relate to a person, because they hang on an account.
Typical sources and their personal reference
Liste zu erledigender Punkte
- Sign-ins and failed sign-in attempts, with account, time and location
- Access to files and databases, with account and object
- Network connections from endpoints, with destination and duration
- Events from endpoint protection, including programs executed
- Events from applications, often carrying business content
The last line is the one most often underestimated. Events from business applications can contain content, which brings data into the system that are not needed there.
The points it turns on
Co-determination
A SIEM can capture conduct and therefore falls under sec. 87(1) no. 6 BetrVG. Involvement belongs at the beginning, because governing evaluation is at the same time governing lawfulness.
Retention
Short periods lower the risk of conduct monitoring and make investigating an incident harder. A staged solution resolves that tension better than a compromise in the middle.
Who evaluates
Routine evaluation is machine-driven. A targeted evaluation concerning a person should be tied to a procedure that involves a second person and is documented.
External operation
Where a SOC is bought as a service, location, access and powers have to be settled. Access from a third country would have to be assessed as a transfer.
What could be adjusted
The most effective step is choosing the sources. What never enters the system needs neither retention nor protection nor deletion, and the choice can be made before roll-out.
The hardest point is the retention period, because two requirements pull in different directions.
Short, staged or long retention
| Merkmal | Short, two weeks | Staged | Long, six months |
|---|---|---|---|
| Detecting an attack | usually enough | spricht in dieser Zeile dafürenough | enough |
| Investigating an attack | often too shortAn attack frequently goes undetected for weeks. Anyone keeping only two weeks can no longer reconstruct the attacker path and cannot close the report on the incident. | spricht in dieser Zeile dafürenough | enough |
| Risk of conduct monitoring | spricht in dieser Zeile dafürlow | low for the long-kept setOnly a reduced set is kept long, for instance sign-ins and security events without content data. That keeps the evaluable part small. | high |
| Effort | spricht in dieser Zeile dafürlow | rules per source | storage |
| Towards the works council | easy to defend | explainable | hard |
The staged period resolves the tension better than a compromise in the middle, because it limits the volume and not only the duration. It does cost rules per data source, and those do not arise on their own.
Two further settings follow. A procedure for targeted evaluation under four eyes and with a log, and an express exclusion of performance monitoring. Both belong in the same document as the periods, because together they form the basis for operation.
Frequently asked questions
Which legal basis fits?
For operation, Art. 6(1)(f) GDPR in conjunction with Art. 32 GDPR comes into question, because security of processing is a statutory task. For evaluation on suspicion, sec. 26(1) sentence 2 BDSG comes into question alongside it, and for the lasting arrangement a works agreement.
How long may logs be kept?
There is no fixed period. Detection often needs weeks, while investigating an incident can need months. A staged period appears defensible, with short retention for routine operation and longer retention of a reduced data set.
What applies with an external SOC?
The provider is usually a processor, and a contract under Art. 28 GDPR is needed. What would additionally have to be settled is where the evaluation takes place, whether content data are accessible and what powers the provider has in an emergency.
More questions from this area
Technical and organisational measures
Art. 32 GDPR requires a level of security appropriate to the risk and names criteria rather than a list.
Implementing NIS2
The ten subjects in section 30(2) BSIG are the minimum scope, and their depth is measured by the five factors in section 30(1) sentence 2 BSIG.
Get in touch!
Have we sparked your interest? Do you have questions? Would you like a quote without obligation? We look forward to hearing from you!
Contact usAlternatively you can request a call back.