Power BI for Cyber Security: Build Your First SIEM Dashboard

Two kinds of security data

Before touching Power BI, you need one distinction that underpins the whole course.

The SOC dataset is alert data: each row is a thing an analyst is handling. It is the refined output of a security pipeline; triaged, assigned, tracked to resolution.

The Windows dataset is raw event data: each row is a single thing a machine recorded. Logons, logoffs, processes starting and stopping, files touched. Windows does not log "attacks"; it logs everything, and detection means finding malicious needles in that haystack. Thousands of these events occur before any human looks at one.

Column guide: the SOC alert data

Read these before loading anything; every column earns its place on a real SOC queue.

EventID

Unique ticket number per alert. The primary key.

Timestamp

When the event was detected. Time is central to security analysis; clusters of events in short windows, and activity outside business hours, are both classic signals.

SourceIP and DestinationIP

Where activity came from and what it targeted. Addresses starting 10. and 192.168. are private internal ranges; a port scan's SourceIP is the scanner, its DestinationIP the machine being probed.

EventType

The category of suspicious activity. The reference sheet defines each; they map to real attack stages, from reconnaissance (Port Scan) through to data exfiltration (Unusual Data Transfer), plus modern cloud-era types such as Unauthorised OAuth Grant and Unsanctioned AI Domain Access.

Severity

Low, Medium, High, Critical. Drives triage order.

Department

Business context; the same alert matters more in Finance than in most teams.

Status

The alert lifecycle; Open, Investigating, Resolved, False Positive. False positive rates are a standard SOC metric.

ResolvedDate

Blank until an alert closes. The blanks are meaningful, not missing data. ResolvedDate minus Timestamp gives time-to-resolution, a headline SOC measure.

AnalystAssigned

Who owns the ticket; enables workload views.

Loading data the right way

Open Power BI Desktop, then Get Data > Excel workbook, and select soc_dataset1.xlsx.

Always transform before loading

Click Transform Data rather than Load, even on clean data; the habit pays off on messy files. In Power Query, check three things: Timestamp and ResolvedDate show the date/time data type (fix via the icon in the column header if they read as text); ResolvedDate contains nulls and should keep them; each query has a sensible name. Then Close and Apply.

The star schema, as a senior analyst would explain it

Every row in NetworkEvents is a thing that happened; an event, at a time, from an IP, to an IP. It happened once and will never happen again, and tomorrow there will be a thousand more rows like it. That table only ever grows. That is what makes it the fact table: it records occurrences.

EventTypeReference has seven rows. It records nothing that happened; it records what things mean. Port Scan is reconnaissance, typically Medium. Unusual Data Transfer is exfiltration, typically High. That is institutional knowledge, not activity, and it changes only when the security team decides to change it. That is the lookup table (also called a dimension table): it describes rather than records.

Why keep them separate? Suppose the full description lived on every event row. You would store the same sentence a thousand times over; wasteful but survivable. The real problem: the day Port Scan gets reclassified into a new category, you would have to update every historical row, and any you missed would make your reports silently disagree with themselves. With a lookup table you change one row and every event, past and future, picks up the new meaning instantly. One source of truth for definitions; an untouched, ever-growing record of facts.

In Power BI: open Model view (the linked-tables icon on the left rail) and confirm a one-to-many relationship on EventType, with the 1 on EventTypeReference and the asterisk on NetworkEvents. Power BI usually auto-detects it; if not, drag one EventType field onto the other.

Verification exercise: build a table visual using Category from the lookup and a count of EventID from the fact table. If counts split by category rather than repeating one number, the relationship works.

The first chart, and the traps inside it

Build a stacked column chart: alerts per day, coloured by severity. Three stumbling blocks arrive at once; treat each as part of the lesson, because every Power BI beginner meets all three.

Raw Windows event logs

Now the main event. Load synthetic-windows-event-data.xlsx the same way. The Navigator shows about twenty items this time: ten worksheets plus ten Table objects. Tick only the Table versions of NetworkEvents and EventTypeReference; the eight Cat_ tables are per-category documentation subsets, useful to read in Excel but redundant in the model. The Table-versus-sheet distinction matters more here, because the category sheets have title text above their data; a sheet version would arrive with junk rows and Column1-style headers.

In Power Query: _time should be Date/Time; EventCode arrives as a whole number, which is fine, but remember it is a label, never a quantity to sum; and expect large numbers of nulls in IpAddress, ProcessName, ObjectName and similar. Each event type populates only its own fields, so the blanks are correct behaviour, not dirty data.

Relate EventCode to EventCode in Model view; same star, bigger and rawer fact table.

Column guide: reading a Windows Security log

Work through a few real rows with this guide beside you. The key columns:

_time, index, sourcetype, host

Splunk's plumbing; the timestamp, storage bucket, data type and reporting machine. The underscore prefix marks Splunk internal fields.

LogName

Which Windows log; Security for audit events, System for operating system events.

EventCode

The single most important column. Every Windows event kind has a fixed numeric ID, and analysts memorise the common ones; see the table below.

ComputerName

Where the event occurred. Naming conventions encode machine type: WKS workstation, LAP laptop, SRV server, DC domain controller; the domain controller handles all domain logins and is the crown jewels.

Subject versus Target accounts

The beginner trap. Subject is who performed the action; Target is who it was done to. For a self-logon they match. For "an account was created", Subject is the admin, Target the new account. Unexpected mismatches deserve attention. SIDs are the accounts' permanent internal identifiers; usernames can change, SIDs cannot. Accounts prefixed adm. are separate administrator accounts, mirroring real practice.

LogonType

How a logon happened, as a code; see the table below.

ProcessName

Full path of a program for process events. Paths matter: C:\Windows\System32 is normal territory; executables running from a Public user folder with names like stage_2.exe are textbook malware staging.

ObjectName and ObjectType

Files and registry keys touched. The registry is Windows' settings database; attackers modify it to survive reboots.

PrivilegeList

Specific admin rights invoked, such as SeDebugPrivilege, abused by credential-theft tools.

ServiceName

For Kerberos events, which service a ticket was requested for; krbtgt is the ticket-granting service itself, central to attacks such as Kerberoasting, so analysts watch it.

Status and Message

Success or Failure, and the full human-readable event text. Every other column is a parsed field from Message; that parsing is much of what a SIEM does.

Event codes worth memorising

Logon type codes

Your first measure

Reach for a Y-axis field and you will discover this table has no EventID. That absence is deliberate: Power BI has no built-in "number of rows" field, so the count must be created.

The quick way: drag any column with no blanks (host works) into the Y axis; text columns default to Count. But beware the trap: Count skips blanks, so Count of IpAddress silently counts only events that have an IP; a wrong total that looks right. (Used knowingly, that same behaviour is legitimate; Count of ProcessName counts only process events.)

The proper way, and your first line of DAX: Modeling ribbon > New measure, then

Total Events = COUNTROWS(NetworkEvents)

The measure appears in the Data pane with a calculator icon; use it as the Y axis everywhere from now. It has no null trap, is reusable in every visual, and reads properly in tooltips. Real SOC dashboards are stacks of measures like this filtered different ways: failed logons, events per host, after-hours activity.

The interactive page

An honest admission: everything so far could be done in Excel. The difference arrives only when several visuals share a page, so build four on one page over the Windows data:

• The stacked column chart: events by day (_time drilled to Day), Category as legend, Total Events on Y
• A bar chart: TargetUserName on the axis, Total Events as values
• A table: EventCode and EventName (from the lookup, exercising the relationship) with Total Events
• A slicer holding Status

Then click things, in this order, and notice what each click asks:

1. Click Failure in the slicer: every visual re-filters at once; the timeline shows when failures cluster, the bar chart shows which accounts they hammer, the table shows they are mostly 4625s and 4771s.
2. Click the 4625 row in the table: the bar chart now answers "who is being brute-forced?"
3. Click one suspicious day in the timeline: everything narrows to that day.
4. Ctrl-click stacks filters.

Two quieter points to bank: scale (Excel struggles beyond a million rows; Power BI models handle tens of millions, and SIEM exports get there fast) and refresh (save new data over the old file, click Refresh once, and every visual, measure and relationship rebuilds; the report is a machine built once, not a document redone monthly).

From clumsy to CISO-ready; layout, formatting and page behaviour

Every first four-visual page works and looks terrible: a giant slicer eating a quarter of the canvas, visuals of random sizes, nothing aligned. That is fine; function first. This part turns it into something you would put in front of a CISO, and demystifies how pages behave along the way.

Tame the giant slicer

Select the slicer, open Format visual, and under Slicer settings change Style from Vertical list to Dropdown; it collapses to a single neat row that expands on click. (Tile style suits touch screens and short lists like Severity; the vertical list only earns its space when the list is short and constantly used.) Under Selection you can enable Show "Select all" and multi-select behaviour. Then resize it to a slim strip. The convention on operations dashboards: slicers live in a consistent strip across the top or down the left edge, never floating mid-canvas.

Set the scene: theme and background

Do the big moves before fiddling with individual visuals. On the View ribbon, open the Themes gallery and try a few; one click restyles every visual on every page, which is the point: colour decisions belong to the theme, not to twenty separate format panes. Choose Customise current theme to set your own palette and default font.

SOC dashboards are traditionally dark (screens in a dim room, red alerts that glow), so try it: click empty canvas > Format page > Canvas background, set a dark navy, and pull transparency to zero. If you go dark, check every visual's text is still readable; the built-in Dark theme handles most of it for you. There is no shame in staying light; NT audiences reading in bright rooms may prefer it. Pick one and be consistent.

Titles, borders and breathing room

For each visual, under Format visual > General: give it a short title written as the question it answers ("Failed logons by account", not "Bar chart"). Turn off clutter that repeats what the title says; axis titles and legends earn their place or go. Under Effects, a subtle background, rounded corners on the visual border, and a faint shadow lift each visual into a card; apply identical settings to all visuals so they read as a set. This is exactly the tile look every commercial SOC product uses.

Alignment: the difference between amateur and professional

Ctrl-click to select several visuals, then use the Format ribbon (the one that appears when visuals are selected) > Align, and Distribute horizontally or vertically. Nothing signals "clumsy" faster than near-aligned edges; nothing fixes it faster than these two menus. Turn on View ribbon > Gridlines and Snap to grid before moving anything else.

A layout that reliably works, top to bottom: a slim KPI card row across the top (built in Part J), the timeline chart full width beneath it, the detail visuals (bar chart, table, matrix) in a row below, slicers top-right. Executives read in an F pattern; put the headline numbers where the eyes land first.

Control what clicks do

By default every visual cross-filters or cross-highlights every other. You can direct this: select a visual > Format ribbon > Edit interactions, and every other visual sprouts small icons letting you choose filter (the clicked selection removes everything else), highlight (dims the rest, keeping context) or none. Highlight is the default for column charts and often the better story-teller; filter is cleaner for tables. Knowing this menu exists also cures the occasional "why did that chart not change?" mystery: someone turned an interaction off.

The CISO heatmap

Executives do not read walls of numbers; they scan for red cells and ask why. This part builds that view, and teaches the design rule underneath it: colour gradients are for quantities (how many events); fixed colours are for categories (Critical is always red). Mixing them up produces confusing dashboards.

Build: host into Rows, Category into Columns, Total Events into Values.

Paint: with the matrix selected, Format visual (paintbrush) > Cell elements, confirm the series is Total Events, switch Background colour on, click the fx button. Format style Gradient, turn on Add a middle colour, set minimum green, middle orange, maximum red. (Alternative route: dropdown arrow on Total Events in the Values well > Conditional formatting > Background colour.)

The result reads instantly: most cells green, a few burning orange to red. The domain controller glows under Account Logon because all Kerberos authentication flows through it; that is expected. Any workstation glowing in unexpected columns is a question.

Visuals that make it remarkable

With layout under control, four additions turn a competent report into a memorable one. All use only built-in visuals; no marketplace downloads needed.

The KPI card row

Real SOC dashboards lead with headline numbers. Build three more measures (Modeling ribbon > New measure):

Failed Logons = CALCULATE([Total Events], NetworkEvents[EventCode] = 4625)
Hosts Reporting = DISTINCTCOUNT(NetworkEvents[host])
Log Clears = CALCULATE([Total Events], NetworkEvents[EventCode] = 1102)

CALCULATE is the workhorse of DAX: it takes a measure and applies a filter to it, and those three lines are the template for almost every security metric you will ever write. Drop each measure into a Card visual and line the cards across the top of the page.

The Log Clears card is the teaching moment: it should read zero on a healthy network, so apply conditional formatting to its text colour (the fx route, Rules style: grey at zero, red above zero) and it becomes a silent alarm that lights up only when someone has been covering their tracks. Cards respond to slicers and cross-filtering like everything else, so clicking a host in the heatmap re-computes the headline numbers for that machine alone.

The Smart Narrative

In the visual gallery, the icon that looks like a text block with a lightning bolt is Smart narrative. Click empty canvas, add it, and Power BI writes a plain-language summary of what is on the page: totals, trends, largest categories. The magic is that the text is live: cross-filter to Failures, or click one account, and the paragraph rewrites itself to describe the filtered picture. You can edit the text freely and insert your own dynamic values (the +Value button accepts natural-language questions or measures), so a practical pattern is an auto-updating shift summary in a corner of the CISO page: "There were [Total Events] events across [Hosts Reporting] hosts, including [Failed Logons] failed logons."

Set expectations: the generated prose is statistical boilerplate ("Total Events trended up"), not analysis, and it will happily narrate the unremarkable. Treat it as a draft narrator that never sleeps; the analyst still decides what matters. Its real value is proving that the page is one live model, not a collage of pictures.

The decomposition tree

If one visual earns the word remarkable for security work, it is this. Add a Decomposition tree from the gallery: put Total Events in Analyze, then load Explain by with Category, EventName (from the lookup table), host, TargetUserName and Status. Click the plus beside the total and choose a dimension to split by, then keep clicking plus on any branch to split again, in any order: Category, then which event, then which machine, then which account. This is precisely the drill-down an analyst performs during an investigation, made physical. The AI options in the plus menu (High value, Low value) let Power BI choose the most interesting branch for you. Free-explore here; you may find threads of the planted attack story without being told where to look.

Anomaly detection on the timeline

Swap a copy of the events-per-day chart to a line chart, open the Analytics pane (the magnifying-glass icon beside Format), and under Find anomalies click Add. Power BI marks the days that deviate from the expected range and, when you click an anomaly marker, offers possible explanations drawn from the other fields (feature behaviour varies a little by version). On this dataset the attack days should surface as marked anomalies, which lands a serious point: this is exactly what a SIEM's detection layer does at industrial scale; flag the abnormal, then let a human ask why.

Hunt the intruder

The Windows dataset contains a planted attack story. Using only the dashboard built today, hunt it. Here is the method, not the answers:

1. Filter to Failures and find the account being hammered with 4625 failed logons; note the day and source.
2. Clear the filter and click that account: did a success follow the failures? The failure-run-then-success pattern is the classic brute-force breakthrough.
3. Check what that account did next: look for process events, and specifically for executables running from C:\Users\Public\Transfer (stage_2.exe, stage_3.exe); staging behaviour.
4. Sweep for the cover-up: any 1102 audit-log-cleared events?
5. Check account lockouts (4740) and account creations (4720) around the same window.
6. Use the heatmap to spot which machines ran hot, and the timeline to order the story.

Deliverable: write a five-sentence incident summary: what happened, which account, which machines, in what order, and what you would check next. Writing the narrative from clicks is the skill; the dashboard is just how you got there.