Controlling Administrator Actions: SIEM, PAM, or Audit

What controlling administrator actions means in simple terms

An administrator is more than an employee with “system access.” They are a privileged user: a person (or service account) who can change settings, grant rights, view sensitive data, disable protections, and remove traces. Controlling administrator actions is not about distrust — it's because the cost of an error or abuse is highest here.

There are typically three types of situations: intentional abuse (accessing data without justification), accidental mistakes (applying a policy to the wrong target, deleting an account, breaking a service), and account compromise (when an attacker operates under an admin account). In all cases the question is the same: who did the action, when, from where, and was it authorized.

The problem is that "ordinary logs" often don't give a coherent picture. They can be scattered across servers and applications, retained for short periods, lack command or parameter details, or be disabled entirely. Worse, an admin might be able to edit or erase logs on the same systems where they work.

In practice the process most often fails in four places:

• missing data (audit not enabled or events not collected from critical systems)
• no accountability (shared accounts, no binding to a person)
• no integrity (logs can be changed or deleted)
• no context (you see an event but not what happened before and after)

A simple example: on Friday evening a company suddenly loses access to a file share. The logs only show “permissions changed.” Without administrator action controls, it's hard to quickly determine whether it was the on-call person's mistake, scheduled work under a ticket, or a login using their account from someone else's machine. The earlier you decide which actions to capture and how to protect records, the easier audits, internal reviews, and real incidents become.

What regulators and internal audit usually require

Regulators and internal audit usually want not a "pretty system" but the ability to quickly prove facts: who, when, and what exactly was done with privileged access, and why it was allowed. If this cannot be shown without lengthy manual collection, the control is considered formal.

Minimum expectations are commonly:

• action accounting: logins, privilege escalations, configuration changes, access to critical data, operations in AD, databases, network equipment, and hypervisors
• binding to a person: not a shared "admin" account, but a personal account with clear identification (preferably with MFA)
• log immutability: records cannot be quietly erased or rewritten by an admin on the same system
• retention periods: agreed retention for logs and session records, plus the ability to find them quickly
• completeness and integrity: clarity about which sources are logged and which are not, and how collection gaps are controlled

A separate block of requirements almost always concerns separation of duties. Someone who administers a system should not unilaterally grant themselves access and at the same time be the one who "accepts" the logs. Roles are usually separated: who requests access, who approves, who issues, who reviews logs, and who conducts investigations.

Internal reviews often ask not only "what did the admin do" but also "why." Therefore, it's important to show justification: a ticket or incident, approvals, the maintenance window, a list of systems, and confirmation that access was revoked in time. Example: an admin changed firewall rules at night. Audit expects to see an emergency ticket, on-call approval, a session recording, and a final change review.

To avoid surprises at handover, agree requirements in advance with a short document between InfoSec, IT, and compliance:

• list critical systems and admin-action types that must be tracked
• record retention periods and the format of evidence (logs, reports, session recordings)
• define roles and prohibitions (who cannot view or change logs)
• determine how access justification is verified (ticket, procedure, emergency process)
• agree on control metrics: e.g., the share of privileged actions with confirmed justification

What data is needed for investigations and reviews

To make investigations fast, you don't need "logs in general," but a clear set of data from the places where admins actually change the environment. Typically this is domain infrastructure (AD), virtualization, network equipment, databases, backup systems, mail and file services, and cloud consoles and management panels.

It's important to agree in advance what you consider an "audit trail." Reviews and investigations seek simple answers: who logged in, from where, what exactly was changed, and can you confirm that the action was performed by a specific person.

Events that are almost always critical

A few event groups nearly always matter:

• logins and failed login attempts (including RDP/SSH/consoles), password changes
• privilege escalation: addition to admin groups, role grants, use of sudo/runas
• policy and configuration changes: GPO, firewall rules, routes, hypervisor settings
• account operations: creation, deletion, unlocks, disabling MFA
• attempts to "blind" control: disabling audit, clearing logs, stopping agents

An event log is not the same as proof of action

A record like "successful login" shows a session started, but doesn't prove what was done inside. For evidentiary value, time bindings and identifiers are important (account, host, source), and sometimes a session recording (commands, screen) or detailed configuration change logs are needed.

If some systems log poorly, don't try to extract perfect detail from them. Instead choose compensations: enable the maximum available audit, add an intermediate control point (for example, admin access only through a jump host), and ensure centralized log storage with immutability and sufficient retention.

SIEM: advantages and limitations for controlling admin actions

SIEM is useful for controlling admin actions, but it's important to understand its boundary: SIEM shows what happened by events, but it doesn't always show "what a person did inside a session."

SIEM's strength is investigation by time and correlations. When suspecting privilege changes, log disabling, or non-compliant logins, SIEM helps quickly collect event chains from different sources: AD, servers, network devices, and applications. It's convenient for regulator and audit reporting because it provides a single repository, search, and alerting rules.

Typically SIEM covers well:

• correlation of events across systems (who, where, when logged in and what was touched)
• fast search by time range and account
• alerts on anomalous activity (night logins, mass changes, log disabling)
• basic access and incident reporting

Limitations start where "action meaning" is required. For example, an interactive SSH or RDP session: SIEM sees the login and sometimes process launches, but not always the commands and actual configuration changes. Another weak spot is context: why the action was performed and under which approval. Without that, control becomes a stream of signals that is hard to interpret conclusively.

SIEM also depends on source quality. If audit is not enabled on some servers, node times drift, or events are not normalized (different formats, different "user" fields), the investigation can lead to false conclusions.

Example: logs show permissions disappeared on a file server. SIEM will quickly show which account logged in and when changes began, but answering "what commands were run and who was at the keyboard" often requires PAM or session recording plus logging rules on the systems themselves.

PAM: where it is indispensable and what it may not cover

PAM (Privileged Access Management) is needed where it's important not only to collect logs but to control the very fact of granting privileges. It answers the practical question: who got admin access, for how long, for what reason, and what did they do during the session. For controlling admin actions this is often the most auditable layer.

What PAM covers best

PAM usually includes a secure credential store, access-on-request with approvals, and recording of admin sessions (screen, commands, metadata). As a result, even if a team knows a password, it's not used directly: access is made through PAM and a trace remains.

PAM is especially useful when:

• admins work with critical systems (AD, databases, virtualization, network equipment)
• contractors and temporary staff need time-limited access
• emergency (break-glass) access is required with strengthened controls and post-event review
• centralized privileged management across segments is needed

Example: a contractor is given server access for 2 hours to perform an update. Through PAM they receive temporary credentials, the session is recorded, and after the window the rights are revoked. If later an auditor asks, you can show who requested, who approved, when they logged in, and what they did.

What PAM may not cover

PAM does not remove organizational challenges. Implementation affects processes and admin habits: who approves requests, how emergency access is documented, and what counts as a "critical system."

There are technical limits. Not all protocols and legacy systems support proxying and recording well; some actions may bypass PAM (local consoles, rare management interfaces, "shadow" accounts). Therefore PAM is almost always complemented by system-level logging and SIEM collection so the investigation picture is complete.

Separate auditing without PAM: when reasonable and what the risks are

Sometimes admin action control is built without PAM, relying on OS audit, network control points, and evidence storage. This can be a conscious choice if you need to quickly meet a specific requirement or aren't ready to change access processes.

In practice this usually includes:

• a bastion host with session recording (RDP/SSH) and command logging
• extended OS and application auditing (Windows/Linux), including rights, services, registry, and scheduler changes
• EDR on servers and admin workstations to capture tool launches, scripts, and suspicious chains
• centralized logging with long retention
• WORM storage (or immutable mode) so records cannot be silently altered

This approach is sensible when the perimeter is small (a few critical servers and a limited number of admins), requirements are targeted, or you're running a pilot to understand what data is truly needed for reviews.

Risks of "audit without PAM" are notable. Data is scattered: some in OS logs, some in EDR, some in session recordings, and all must be correlated by time and accounts. Investigations take longer because there is no single answer to "who got access, who approved it, and what did they do in-session." There's also a human factor: controls get bypassed (connecting outside the bastion, using shared accounts, disabling auditing on a host).

To make logs and recordings evidentiary, consider integrity and availability in advance:

• separate rights: admins should not administer the logging system and evidence storage
• enable immutable storage (WORM/immutable) and integrity checks
• set precise time (NTP) and unified user identifiers to correlate events
• implement redundancy, clear retention periods, and fast incident search
• regularly verify auditing is not disabled and that data is actually arriving

Example: an admin changes a group on a file server at night and deletes traces. Without PAM you'll have to manually gather a chain from OS events, EDR telemetry, and remote access recordings. If one piece is missing (e.g., the session wasn't recorded), the picture may remain incomplete.

How to choose an architecture: a step-by-step algorithm

Architecture depends not on the fashion for SIEM or PAM but on how you will prove facts: to a regulator, internal audit, or during an incident review. First decide what you must be able to prove, then choose where to record it.

A practical order of actions:

• define measurable goals: what questions you answer (who logged in, what changed, by whose request, over which period) and required retention periods
• build a privileges matrix: which admin accounts exist, what systems they can access, and where critical data lives (AD, virtualization, databases, financial systems, network equipment)
• determine what to record: login facts, actions (commands, configuration changes, account operations), and for the highest-risk areas — full session recordings
• choose control points: on target systems (OS and application logs), on privileged access gateways, and, if needed, on the network
• plan storage and investigation workflows: who can view recordings, how integrity is protected, how an investigation starts, and how approval chains look

A sanity check: imagine an admin changed a group in AD at night and opened access to a folder with personal data. A good scheme will let you quickly answer which device was used to log in, what justified the work, what changes were made, and who reviewed them.

Typical architectures and when to pick which

The choice usually comes down to two questions: do you want only facts (who did what) or also evidence (how it was done in-session)? And second — how many admins do you have and how critical are the systems?

Four practical options

Common patterns in the field:

• Option A: SIEM as the monitoring center. Suitable if quality logging is already enabled on OS, DBMS, AD, network devices, and applications and logs flow well into SIEM. Good for event-based investigations but weaker for answering "what was done in the console."
• Option B: PAM for access + SIEM for correlation and reporting. Privileges are issued through PAM with approvals and limits, while SIEM collects events and helps visualize action chains. Often the best choice for regulators and internal audits.
• Option C: bastion (jump host) with session recording + SIEM for events. Handy when you need a quick way to secure access to critical segments and obtain screen/command recordings. Decide in advance where and how long to store recordings.
• Option D: hybrid. Deploy PAM and/or session recording for the most critical systems (finance, government data, clinical systems), and use enhanced auditing and SIEM for the rest. This reduces cost and operational load.

Choosing by team size and number of admins

If you have 2–5 admins and a small infrastructure, Option A or C for key servers is often enough. With 10+ admins or many contractors, chaos with accounts and exceptions usually grows without PAM.

Check yourself against a few criteria:

• is there a single list of privileged accounts and their owners?
• do you need proof at the level of “video/commands” not just events?
• how many systems are truly critical for business and regulators?
• who will review alerts and reports daily?
• what retention is required for logs and recordings?

Organizations with stricter requirements (government, finance, healthcare in Kazakhstan) often benefit most from a hybrid: PAM and session recording for key contours, and SIEM for the overall picture and investigations.

Example: how an investigation of suspicious admin actions goes

A simple and unpleasant scenario: someone in Active Directory suddenly gets elevated rights (for example, added to Domain Admins), and logging on a key server is almost simultaneously disabled. InfoSec or internal audit notices this in the morning and asks for an explanation.

The investigation starts with questions, not tools. Quickly collect facts:

• who actually logged in under the privileged account (personal or shared)?
• from which device or server were actions performed (host name, IP, VPN, jump server)?
• by what method did they connect (RDP, PowerShell, console, remote admin tool)?
• what was the justification (ticket, emergency, scheduled work) and who approved it?
• what exactly changed: group membership, GPO, local policies, audit settings?

If SIEM is set up, the investigation often begins with a timeline. The analyst finds the AD event for group addition, then looks at neighboring events: successful authentication, Kerberos ticket issuance, admin tool launches, RDP connection, audit setting changes. This yields a chain: "login -> privilege escalation -> server access -> log disabling." That helps assess sequence and scope, but SIEM usually shows facts from logs, not in-session actions.

PAM provides a different view. If privileged access passed through PAM, you can retrieve whether a request existed, who approved it, what credentials were issued (or proxied), the session recording, and the commands entered. A claim of "I didn't do it" becomes a verifiable set of artifacts: request, time, purpose, and session actions.

To make investigations take hours instead of weeks, prepare in advance:

• separate personal and privileged accounts and forbid shared admin logins
• centralize log collection and protect it from deletion (separate rights, immutable storage per policy)
• require admins to access systems through a controlled point (jump server or PAM) rather than directly
• synchronize time across servers and security systems, or the timeline collapses
• formalize the justification process: tickets, emergency procedures, who can approve and how

Common mistakes and pitfalls when implementing control

The most common mistake is starting with buying a tool rather than answering: what do you need to prove in an audit and how will you investigate incidents? As a result, controls exist on paper but don't help in practice.

Mistake 1: SIEM is in place, but data is missing

SIEM is useless if events arrive incomplete, with different times, or without necessary fields. For example, you may see a login event but no binding to a specific admin account or no way to tell what changed.

Minimum checks:

• unified time (NTP) on systems and log sources
• a list of critical systems and events that must be collected
• clear normalization rules (who, where, what did)
• test cases: can you find an action chain within 10 minutes?

Mistake 2: PAM bought but processes unchanged

PAM won't save you if permanent admin rights are still issued, passwords are known by multiple people, and access requests are bypassed by informal agreements. PAM must be part of the process: request, approval, duration, reason, and revocation.

A typical failure: an admin logs in through PAM, then uses an old local account on the server. Some actions are not recorded and the investigation breaks.

Mistake 3: logs are stored but not protected

Logging and storing logs matters, but without integrity controls it's weak. If an admin can delete or tamper with records, this looks worse than lacking logs at all. Also, retention periods are often inconsistent: today 7 days, tomorrow 30, while auditors expect predictability.

Mistake 4: too wide access to logs and recordings

Access to SIEM and session recordings is often granted too broadly: IT, security, contractors. That increases leak risk, pressure on investigations, and the chance of "cleanup."

Mistake 5: the team isn't trained on real cases

Scenario: suspicion of a database dump. If the team hasn't practiced such investigations, they lose hours locating sources, argue about dump formats, and fail to preserve evidence. It's more practical to run short exercises quarterly with real systems and a clear role distribution: who pulls logs, who confirms accesses, and who prepares the report.

Quick readiness checklist and next steps

If the goal is not just "collect logs" but to actually run investigations and pass audits, check the basics:

• there is a complete list of privileged accounts (including service accounts), system owners, and access custodians
• data sources and a minimal event set are defined: logins and login attempts, privilege escalations, policy changes, access to critical data, and journal operations
• roles and responsibilities are separated: who issues access, who administers, who investigates, who approves exceptions
• retention and location of logs and session recordings are clear: where the "truth" is stored, who has access, and how deletion or tampering is prevented
• a pilot is planned for 1–2 critical contours (for example domain/AD and a key business system) with success criteria: which cases should be resolved in 1 day and which reports auditors need

Then act step by step. Pick 3–5 typical scenarios that truly worry you: "an admin created a hidden account," "bypassed MFA," "exported a database," "cleaned logs." For each scenario define in advance which evidence is needed: events, correlations, session recordings, commands.

After the pilot, record what works and what doesn't: where context is missing, which sources are noisy, who delays approvals, and how quickly you can build an action chain.

If you need help designing and implementing, consider engaging an integrator to take on architecture and process integration. For example, GSE.kz as a systems integrator can help assemble a target SIEM and PAM contour, design immutable evidence storage, and separate roles to meet regulator and internal audit requirements.