← All coursesBack to the simulator →

Monitoring, logging and detection

How you find out what is really happening in your network: why nothing can be traced without logs, the log server as one place for the whole network, severity levels and alert fatigue, lost logs and blind spots (syslog rides on UDP 514 and a firewall can close it), flows, baselines and anomalies, correlating fragments into a single incident, SIEM in concept, and device monitoring including a decoy and a checklist.

This is a text preview of the lessons for reading. The full version – an interactive simulator with animations, exercises and quizzes – runs in the app.

▶ Launch the interactive version

Lesson 1: Why logs

What happens when you have no logs

PCPC2SWFWLOGIDSNETsomething happened – yet no record of it exists

Before you start: this course builds on basics from the beginner courses (addresses and mask, gateway, VLANs, ports, DNS, firewall) – if any feels unfamiliar, check those first. Picture an ordinary Monday morning: accounting cannot reach the shared drive, one server has been off since Friday, and on Tuesday an email arrives saying someone sent fraudulent messages from the company address. Three questions follow immediately: when did it start, who caused it and what happened before. Without logs you have an answer to not a single one. You hold no record of what happened in the network – the network is a device without memory, and asking it about the past is pointless. All that remains is what people recall, which is very weak ground both for troubleshooting and for an investigation. A log is a timestamped record of one event: “at 9:14 the firewall blocked traffic from PC2 to the server”, “at 9:20 the device powered off”. On its own it is boring. Its value comes from there being many of them, lined up side by side – only then does a timeline emerge. A practical consequence people meet only in a crisis: you must collect logs in advance. When something happens and you have no logs, you cannot fill them in – an event that was never written down happened once and is gone for good. So log collection is switched on in calm times, not after an incident. In the simulator you have the Syslog (event collection) panel for this – in this lesson we will look at what flows into it and from where.

Step by step

  1. On Friday something happened: traffic from PC2 ended at the firewall. Without a log no record of it exists.
  2. On Monday three questions land: when did it start, who caused it, what happened before. Human memory is not enough.
  3. With log collection each event has a time and an author. Individual lines assemble into a timeline.
  4. But logs must be collected in advance. An event never written down is gone for good – collection starts in calm times, not after an incident.

Log server: one place for the whole network

PCPC2SWFWLOGIDSNETlocal logs: little space, scattered, lost with the machine

Devices can keep their own records locally – but a local log has three flaws. First, it has little space: older lines get overwritten by newer ones, so when you reach it a week later the event you want is gone. Second, it is scattered: during an investigation you would have to visit the firewall, the switch, the router and every computer and align the times by hand. Third – and this is worst – it sits on the same device as the problem. When an attacker takes a machine, the first thing they do is erase the traces; and when a device breaks or powers off, it takes its records along. The answer is simple and decades old: a log server, one place where all devices send their events. In the simulator it is an ordinary host running Log collection (Syslog) on port 514 – no special box, just a common server with one extra service. When there is none in the network, the Syslog panel tells you straight away: events are collected nowhere. Three things you gain are worth remembering: one timeline across the whole network (you see the IDS alert arrived two seconds after a connection attempt), a record beyond the reach of a captured machine, and a place to search without walking around devices. The log server is therefore the first step of monitoring – ahead of any clever tool.

Step by step

  1. A local log has three flaws: little space, it is scattered across devices and it disappears with whatever broke.
  2. A log server is an ordinary host running Log collection (Syslog) on port 514. No special box.
  3. Devices send their events to one place. That creates one timeline across the whole network.
  4. Active devices – firewall, router, switch, IDS – log from the management interface. The record is then beyond a captured machine’s reach.

What to log and what not to

PCPC2SWFWLOGIDSNETrecording everything: a heap where nothing can be found

Once you collect logs, a question arrives that decides whether they will be any use: what to record. The answer “everything” is tempting and almost always wrong. Record every packet and every successful access and after a week you have a heap in which nothing can be found, the disk fills up and older records get overwritten – exactly the ones an investigation would need. The opposite holds too: record too little and you learn about the incident but not about its cause. A sensible guide: record decisions and state changes, not ordinary operation. What belongs in the log: a denied access (the firewall blocked something), an alert from the IDS, a state change of a device or link (powered off, powered on, link down), logins and their failures, a configuration change and a service starting or stopping. What does not pay off: every successful packet, every DNS answer served or periodic reachability checks – that is noise that only dilutes the signal. The difference between noise and signal can be tested with a simple question: when this line appears, does anything I do change? If not, it does not belong among collected logs. And one more rule that regulations also watch: passwords have no place in a log, nor do message contents or sensitive personal data. A log is a trace of an event, not a copy of the data – otherwise you turn it into another target that needs protecting.

Step by step

  1. Recording everything is tempting and almost always wrong: the disk fills and older records get overwritten.
  2. A log holds decisions: the firewall blocked something. Such a line still has value a month later.
  3. And state changes and alerts belong there: a device off or on, the IDS reporting suspicious traffic, a failed login.
  4. The noise test: does that line change anything I do? And passwords, message contents and sensitive data do not belong in a log.

▶ Open in the simulator

Lesson 2: Severity and what to do with it

Severity levels

PCPC2SWFWLOGIDSNETinfo: routine operation, power-on, service start

Your log server brings hundreds of lines a day and you have no time to read them all. So every record carries a severity – a simple mark saying how much you should care. The detailed syslog scale has eight levels, but in practice three are enough, the ones the simulator panel uses too. Info: normal operation you merely record – a device powered on, a service started. No hurry, but during an investigation this line gives you time and context. Warning: something did not succeed, yet the network runs on – the firewall blocked traffic, a login failed, a link is congested. One such line means nothing, repetition does. Critical: something stopped working or someone attacked something – a device is down, the IDS reports suspicious traffic. This you want to know at once. Two mistakes are made over and over. First: everything critical. When every line shouts, you stop distinguishing and behave as if none of them did. Second: nothing critical, a uniform grey in which real trouble is lost among routine. Severity is not a property of the event itself but of your decision about what to do with it. A good test: critical is what should wake someone by phone. Everything else can wait until you look in the morning.

Step by step

  1. Info: routine operation – a device powered on, a service started. No hurry, but you get time and context.
  2. Warning: something failed, yet the network runs on. One line means nothing – repetition does.
  3. Critical: a device is down or the IDS reports suspicious traffic. This you want to know at once.
  4. Severity is not a property of the event but of your decision. Critical is what should wake someone by phone.

Critical events you must not miss

PCPC2SWFWLOGIDSNEToutage: the switch fell and takes everything behind it

Which lines then deserve the critical level? It pays to keep a short, finite list, because everything not on it can wait until morning. First, an outage: a device is down, a link dropped, a service stopped. A powered-off switch is not just one dark icon – it takes with it everything hanging behind it, and in the Syslog panel you notice because records from the devices behind it stop arriving too. Second, an IDS alert: the one event where someone directly claims “this looks like an attack”. Third, repeated login failures on device management – one failure is a typo, thirty a minute is password guessing. Fourth, a configuration change outside working hours that nobody announced; an attacker hides best as an administrator. And fifth – a little surprisingly – silence: when a device that has been sending records all week suddenly goes quiet, that is as strong a signal as an alert. Either it fell over, or someone turned its sending off. Notice the list is short and fits on half a page. That is deliberate: a critical-event list with twenty items cannot be honored in practice and within half a year people start skipping it. Add one more practical rule: for every critical item have a written procedure ready in advance. A critical alert without a procedure is merely louder noise.

Step by step

  1. Outage: the switch is down. It takes along everything hanging behind it – their records stop arriving too.
  2. An IDS alert is the one event where someone directly claims: this looks like an attack.
  3. Repeated login failures on management mean password guessing. And an unannounced config change at night is suspicious.
  4. And silence: a device that sent records all week suddenly goes quiet. Either it fell over, or someone turned sending off.

Alert fatigue

PCPC2SWFWLOGIDSNETfifty alerts a day, most of them false

There is a monitoring failure caused by no fault and no attacker – it is caused by the volume of alerts. It is called alert fatigue and it always runs the same way. Monitoring is deployed, thresholds are set sensitive so nothing escapes, and the first week brings fifty alerts a day. Most are false – a backup job that runs at night, a test machine that reboots regularly, a colleague who mistyped a password twice. A person dismisses them faster and faster, then builds a filter into a folder, and finally stops reading them at all. At that moment you have the worst possible state: you pay for monitoring, you have a full disk of records, but nobody looks – while everyone believes someone does. A real alert then passes unnoticed in the heap of false ones. The cure is not to switch monitoring off but to narrow it. First: raise thresholds where an alert is regularly false, and name and exclude the false sources outright (the known backup agent, the test machine). Second: report repetition and deviation, not every single occurrence – thirty denials a minute is an alert, one denial is a line in the log. Third: every alert nobody ever resolved should be fixed or retired. A useful measure you can track: what percentage of alerts led to an action. When it is a few percent or less, you are not tuning detection – you are manufacturing noise.

Step by step

  1. Sensitive thresholds bring fifty alerts a day and most are false: a nightly backup, a test machine, a mistyped password.
  2. A human dismisses them faster, then filters them away, then stops reading. Nobody looks – and everyone believes someone does.
  3. A real alert then passes unnoticed in the heap of false ones. That is the worst possible state of monitoring.
  4. The cure is to narrow: report repetition and deviation, name and exclude false sources, and fix or retire what nobody ever resolved.

▶ Open in the simulator

Lesson 3: When logs do not arrive

The log path is traffic too

PCPC2SWFWLOGIDSNETa log is an ordinary packet: switch, firewall, link

Here comes an idea that often catches beginners out: a log is no magic, it is network traffic. When a device sends a record to the log server, an ordinary packet arises that must travel exactly the same path as anything else – through the switch, through the firewall, over a link that may be congested or cut. Syslog traditionally rides on UDP port 514, and that has two consequences worth understanding. UDP is unreliable: the sender releases the packet and gets no confirmation that it arrived. So the device does not know its report was lost – it happily keeps sending into the void and acts as if all were well. At the same time UDP is cheap: it sets up no connection and even a congested router does not hold the sending back, which is a practical advantage at thousands of records a minute. That is why syslog keeps it to this day. But an important design conclusion follows: between every device that logs and the log server there must be a usable path – routing that leads there and a firewall permission that does not stop it. Remember it as a rule: the log path is part of the design, not a given. In the simulator you can verify it directly – disconnect the log server, move it behind a closed firewall or power it off, and the Syslog panel counts how many events were not delivered.

Step by step

  1. A record to the log server is an ordinary packet. It goes through the switch, the firewall and the link like anything else.
  2. Syslog rides on UDP port 514. No connection setup, so it is cheap even at thousands of records a minute.
  3. UDP confirms no delivery. So the device never learns its report was lost – it keeps sending into the void.
  4. Hence the rule: between every source and the log server a usable path must lead. The log path is part of the design, not a given.

The firewall blocks port 514

PCPC2SWFWLOGIDSNETwhile port 514 is permitted, records arrive

The most common way to break log collection is quite innocent: the firewall closes port 514. It happens entirely naturally. You set a default deny between segments – users must not reach servers, cameras must not go anywhere – you permit what people need for work, and you are done. But log collection is not a user’s work: it is device traffic that nobody thinks about while writing rules. The result is insidious because it looks fine. The firewall does exactly what you told it, the network works, users do not complain and nothing glows red. Only records from one segment stop arriving at the log server. And since UDP confirms no delivery, the sending device does not know either – it keeps dutifully releasing reports that nobody will ever see. The Syslog panel in the simulator shows you this situation: an event is lost and the panel counts how many times it happened. Three other things produce the same state: the log server is not running (powered off), a path is missing between segments (no route or a cut cable), or the server sits in the wrong segment that others cannot reach. Practical guidance: when writing rules, permit syslog first, together with DNS and time – these are the three services the network itself needs to be operable. And after every rule change, look at the panel: a silent segment is suspicious sooner than a loud one.

Step by step

  1. While port 514 is permitted, records arrive and lines pile up in the Syslog panel. So far all is well.
  2. You set a default deny between segments and permit what people need. But log collection is not a user’s work – it stays closed.
  3. The state looks fine: the network runs, nobody complains, nothing glows red. Records from one segment simply stop arriving.
  4. Permit syslog first, together with DNS and time. A powered-off server or a missing path produce the same state.

Lost logs = a blind spot

PCPC2SWFWLOGIDSNETthe report is lost and no error message appears

Let us pause on what a lost log actually means, because it is graver than it looks. When a report is not delivered, no error message and no gap with a question mark appears anywhere. What appears is silence that passes for calm. Then you look at the log server, you see records from the rest of the network, the panel looks inhabited and you naturally conclude that nothing is happening in the quiet segment. That is a blind spot: a part of the network you cannot see but believe to be fine. Ignorance is unpleasant, mistaken certainty is dangerous. And there is one more layer to admit: it suits an attacker when you cannot see. Turning off log sending or dropping the collector is a common step in covering tracks, and when it succeeds no record of it remains, precisely because the records disappeared. So log collection itself is watched too. Three simple checks cover most cases. First, the lost-event counter – the Syslog panel in the simulator shows it, and any number above zero is a fault, not cosmetics. Second, a list of sources: you know which devices should log and you regularly check that something arrived from each. Third, silence as an alert: a source that stopped sending deserves a notification as much as an IDS alert does. A blind spot never announces itself – you find it only by actively looking for it.

Step by step

  1. The report is lost. No error message and no gap appear – only silence that passes for calm.
  2. The rest of the network keeps logging and the panel looks inhabited. You naturally conclude nothing happens in the quiet segment.
  3. That is a blind spot: a part of the network you cannot see but consider fine. Mistaken certainty is worse than ignorance.
  4. Watch three things: the lost-event counter, the list of sources that should log, and treat silence as an alert.

▶ Open in the simulator

Lesson 4: Who talks to whom

Traffic as a flow

PCPC2SWFWLOGIDSNETflow: source, destination, port, protocol, volume, time

Logs say what a device did. The other half of monitoring looks at what flows across the network – and you need not read packet contents for that. A flow is enough: a terse record of one connection holding five items – source address, destination address, port, protocol and volume of data transferred, plus a start and end time. Nothing more. It is like a call record: you do not know what was said, but you see who with whom, when and for how long. For monitoring this is surprisingly powerful, for three reasons. First it is small – hours of traffic become kilobytes of records instead of gigabytes, so they can be kept long and reviewed retrospectively. Second it works on encrypted traffic too: HTTPS hides the content from you, but not the fact that your computer talks to an unknown address every thirty seconds. Third it holds no sensitive data, so it raises no problem you would call a privacy issue. In the simulator you watch this through the Traffic & logs → Live traffic panel: you see individual flows, their source, destination, port and whether they passed or someone stopped them. The key idea for the rest of the lesson: a flow on its own means nothing. It gains meaning only by comparison with what is usual in this network.

Step by step

  1. A flow is a terse record of one connection: source, destination, port, protocol, volume and time. Nothing more.
  2. It is like a call record: you do not know what was said, but you see who with whom, when and how long.
  3. A flow works on encrypted traffic too: HTTPS hides the content, not who is talked to and how often.
  4. One flow on its own means nothing. It gains meaning only by comparison with what is usual in this network.

Baseline: what is normal

PCPC2SWFWLOGIDSNETnormal: who talks to whom, on which ports and when

To be able to ask “is this odd?”, you must first know what is normal. That description of the usual state is called a baseline, and it is the most underrated part of monitoring – boring, laborious, and nothing else works without it. A baseline arises by just observing the network for a while and writing down what you saw: which machines talk to each other, on which ports, at which times of day, how large the volumes are and what is visible on the network even when nobody is working. That last item is the most interesting. In the simulator you can watch it directly: ARP, DHCP and broadcast run all the time in advanced mode (see the Traffic & logs panel → Live traffic) – even an “empty” network talks without pause. Stations ask by ARP for the MAC belonging to an IP, clients renew their address leases over DHCP, switches and other devices send their own messages. This chatter belongs to normal and needs to be known – otherwise you will see it one day, take fright and hunt an attack where there is none. Three practical rules. Measure the baseline in a calm period, not mid-migration; gather it over at least a whole week, because Monday morning and Sunday night look entirely different; and write it down, because what lives only in someone’s head cannot be defended a year later. And expect the baseline to age: every new server, new application or process change shifts it. An un-updated baseline manufactures false alarms just as reliably as over-sensitive thresholds.

Step by step

  1. A baseline describes normal: which machines talk, on which ports, at which times and in what volumes.
  2. Even an ‘empty’ network talks constantly: ARP, DHCP and broadcast. This background traffic is normal – you must know it.
  3. Measure in a calm period, gather across a whole week and write it down – Monday and Sunday look different.
  4. A baseline ages: every new server or application shifts it. An un-updated one manufactures false alarms.

Anomalies: what stands out

PCPC2SWFWLOGIDSNETnew partner: a machine talks to an unknown address

With a baseline in hand you can finally ask the essential question: what stands out? An anomaly is not “something bad”, it is a deviation from the usual – and only a human decides whether an attack, a fault or merely a new application lies behind it. A few typical shapes are worth knowing. A new partner: a machine that talked to three servers suddenly converses with an address nobody knows. A new port: between two machines that exchanged only HTTPS all year, a connection to a management port appears. An unusual time: ten gigabytes transferred at three in the morning on a Sunday. An unusual volume: an ordinary flow that is suddenly a hundred times larger, or that dried up entirely. Regularity: a connection that speaks up exactly every 60 seconds – people are not that precise, machines are, and this is exactly how a compromised machine reporting to its control server looks. And a flood: a sharp rise of broadcasts or ARP requests that fills the link – there the cause is usually a loop in the topology rather than an attacker, but it downs the network all the same. Take two things from this. First: an anomaly is a question, not a verdict. The right reaction is “why is this happening?”, not “switch it off”. Second: most anomalies have a boring explanation – a new colleague, a new tool, a new backup – and that is fine. Detection that never finds anything is as suspicious as detection that reports everything.

Step by step

  1. A new partner: a machine that talked to three servers suddenly converses with an address nobody knows.
  2. Regularity: a connection exactly every 60 seconds. People are not that precise – a compromised machine reporting to its control server is.
  3. A flood: a sharp rise of broadcasts or ARP requests. Usually a topology loop, yet it downs the network all the same.
  4. An anomaly is a question, not a verdict. Most have a boring explanation – a new colleague, a new tool, a new backup.

▶ Open in the simulator

Lesson 5: Correlation: a story from fragments

One event is not enough

PCPC2SWFWLOGIDSNETone line: a mistake, an application, or an attacker?

Take a single line from the log server: “the firewall blocked traffic from PC2 to the server”. What do you know? Almost nothing. It may be a colleague who mistyped the shared drive address. It may be an application that, after an update, attempts a connection it never made before. And it may be an attacker feeling out where they can reach from a captured machine. The event itself is identical in all three cases – and that is the core of the problem this whole lesson addresses. A single line has no context, so no decision can be built from it. The answer is called correlation: assembling several records from different sources until a story emerges. You ask three things. When: what happened just before and just after? Who: does that machine appear elsewhere, in other records? How many times: was it once, or fifty times a minute? One denial is a mistake. Fifty denials a minute to fifty different targets is looking around the network. For correlation to be possible at all you need two things arranged in advance. The first is a common time: when every device keeps its clock somewhere else, the timeline falls apart and the story cannot be assembled – which is why time synchronization is deployed in a network. The second is one place where the records sit together, that is the log server from the first lesson. Without those two you are left with single lines that say nothing.

Step by step

  1. “The firewall blocked traffic from PC2.” A colleague’s slip, a new app, or an attacker? The event is identical in all three.
  2. Correlation asks three things: when (what came before and after), who (where else the machine appears) and how many times.
  3. One denial is a mistake. Fifty denials a minute to fifty targets is looking around the network.
  4. Correlation rests on two things arranged in advance: a common time on all devices and one place holding the records.

Three lines, one incident

PCPC2SWFWLOGIDSNET9:14 – the IDS reports suspicious traffic from PC2

Let us see what correlation looks like on a concrete case. Within a few minutes three different lines appear in the panel and each looks unremarkable on its own. 9:14 – the IDS reports suspicious traffic from PC2 (you know how such an alert arises from the Advanced security (DPI, IDS/IPS) course). On its own it is one alert among many, and anyone who knows alert fatigue skips it. 9:15 – the firewall blocked traffic from PC2 to the server. On its own it is one denial, and those arrive daily. 9:17 – the server is down. On its own it is an outage, a technician is called and writes “probably power”. Three different sources, three different severities, three different people looking at it – and none of them sees the whole. But the moment you place those lines on one timeline and notice that the same machine recurs in two of them, it stops being three trifles: within three minutes suspicious traffic appeared from a specific station, that station attempted a connection it was denied, and right after that the server fell over. That is no longer noise, that is an incident, and it deserves a procedure, not the closing of three separate tickets. Remember two guides. Closeness in time and a recurring actor are the two cheapest and strongest correlation guides – and both are visible to the naked eye if your logs sit in one place. And one more rule: a connection in time is not proof of cause. Correlation tells you what to look at; whether the server fell because of the attack or by coincidence is settled only by investigation.

Step by step

  1. 9:14 – the IDS reports suspicious traffic from PC2. On its own one alert among many; anyone tired of alerts skips it.
  2. 9:15 – the firewall blocked traffic from PC2 to the server. On its own one denial, and those arrive daily.
  3. 9:17 – the server is down. On its own an outage; a technician is called and writes “probably power”.
  4. On one timeline the same machine recurs in two lines. Three trifles become an incident – yet a connection is no proof of cause.

SIEM: correlation at scale

PCPC2SWFWLOGIDSNETSIEM collects from all sources and unifies their shape

You can correlate three lines by eye. Three million lines a day from fifty devices you cannot, and that is where SIEM comes from – a tool that collects and evaluates records for you. The abbreviation stands for security information and event management, and in practice it does four things. It collects records from all sources, so it is the log server from the first lesson. It normalizes them: every vendor writes logs differently and SIEM converts them into a common shape, so you can search for “all denials” across devices from different vendors. It correlates by rules you write: “an IDS alert and an outage on the same machine within five minutes” or “thirty failed logins a minute”. And it notifies when a rule matches. None of that is magic – it is exactly what you did by hand in the previous two modules, only at scale and fast. Which is precisely why three limits are worth knowing. First: SIEM sees only what you send it. A source that does not log, or whose records the firewall blocks, is missing from it and nobody notices. Second: SIEM correlates by rules a human wrote – it cannot find what nobody thought of. Third: SIEM solves nothing; it produces alerts, and without people and procedures for them you have bought a costlier way to grow tired of alerts. So the order of steps stays the same: first collect into one place, then introduce severity and a baseline, and only then consider a tool.

Step by step

  1. SIEM collects records from all sources and normalizes them – every vendor writes them differently.
  2. Then it correlates by rules (“an alert and an outage on the same machine within five minutes”) and notifies on a match.
  3. Limit one: SIEM sees only what you send it. A source whose records the firewall stops is simply missing.
  4. Limits two and three: it correlates only by human-written rules and solves nothing itself – without people it is costlier noise.

▶ Open in the simulator

Lesson 6: Monitoring in practice

What to watch on devices

PCPC2SWFWLOGIDSNETinterface state: is the port up or down?

Logs and flows say what happens in the network. A third view remains: how the devices themselves are doing. This is not about security but about operation – and yet a good share of incidents shows up here before anywhere else. Four things are worth watching and they are always the same. Interface state: is the port up or down? A link that fell and rose ten times during the day is worse than one honestly down – because it looks like it works. Link utilization: a persistently saturated link surfaces as “the network is slow”, a complaint you cannot work with without numbers. Error counts: a rising number of errors on a port is typically a faulty cable or connector, and is often the only early warning you get. And service availability: is what should be running on the server actually running? This is most often collected over SNMP – the established way a monitoring system asks a device for its values (and how a device can send a notification of its own when something happens). Remember the difference from syslog like this: syslog tells you what happened, SNMP asks how things stand. One security note, because SNMP is old technology: older versions send data unencrypted and protect it with only a shared password that is often the default. Monitoring belongs in the management network, not among ordinary traffic – otherwise you turn it into a convenient source of information for an attacker.

Step by step

  1. Interface state: a link that fell and rose ten times today is worse than one honestly down – it pretends to work.
  2. Link utilization surfaces as “the network is slow”. And rising error counts on a port typically mean a faulty cable.
  3. It is collected over SNMP. The difference: syslog tells what happened, SNMP asks how the device is doing.
  4. Older SNMP sends data unencrypted, protected by only a shared password. Monitoring belongs in the management network.

A decoy as a clean signal

PCPC2SWFWLOGIDSNETthresholds need tuning, baselines age, false alarms annoy

The whole course has so far fought one problem: telling signal from noise. Thresholds need tuning, baselines age, false alarms annoy. But one kind of signal is clean by its very nature – a decoy (honeypot). It is covered in depth by the Zero Trust and microsegmentation course in the lesson “Assume breach”; here I look at what it means for monitoring. It is a device or service standing in the network with no legitimate purpose whatsoever: a fake file server, a fake management interface, an address no application knows. Nobody has a reason to touch it. Precisely for that, every access to it is suspicious, and you need no thresholds and no baseline – the line is zero. For monitoring it is the cheapest good alert you can obtain. Three practical rules matter, all of them. First: a decoy must be isolated and must have no path elsewhere – otherwise you brought a weakly secured machine into the network to serve an attacker as a springboard. Second: it must hold nothing valuable, because you assume somebody will reach it. Third: it must be wired into log collection and somebody has to watch, or you have built a trap that snaps shut in an empty room. And one sober closing note: a decoy stops nobody. It protects no data, blocks no attack, replaces neither segmentation nor rules. It is an early warning, nothing more – but a warning you hardly need to wonder about being false.

Step by step

  1. The whole course fights one thing: telling signal from noise. Thresholds need tuning, baselines age, false alarms annoy.
  2. A decoy is a device with no legitimate purpose: a fake server, fake management, an address nobody knows.
  3. Nobody has a reason to touch it, so every access is suspicious. No thresholds, no baseline – the line is zero.
  4. It must be isolated, hold nothing valuable and be wired into logging. But it stops nobody – it is only an early warning.

A monitoring checklist

PCPC2SWFWLOGIDSNETcollection: log server, all devices, a common time

The last module is practical: a checklist you can walk through on your own network or on a topology in the simulator. It is split into four areas and deliberately short, because a list that cannot be walked in twenty minutes will not be walked. Collection. Do you have a log server? Do all active devices send records to it – firewall, router, switch, IDS – not just the ones someone remembered? Do the devices share a common time so a timeline can be assembled? Path. Does a report from every segment reach the log server, that is, is port 514 still permitted after the last tightening of rules? Does the Syslog panel show zero lost events? Is some segment silent without you knowing why? Content. Do you log denials, alerts, state changes and failed logins – and conversely not passwords or message contents? Does every critical event have a written procedure for what to do? Attention. Does anyone really look at the alerts, or do they merely drop into a folder? What share of alerts led to an action? Do you know your baseline and when it was last updated? A last piece of advice worth taking from the whole course: monitoring is not a project with an end. A new application, a new rule, a new segment – every network change also changes what you see and what you do not. So the list is walked regularly, not once at rollout. And if a single sentence survives the course, let it be this one: what you do not collect you do not see, and what you do not see you cannot investigate.

Step by step

  1. Collection: do you have a log server? Do all active devices send to it? Do they share a common time?
  2. Path: does a report from every segment reach the server? Is port 514 still permitted after tightening? Are losses zero?
  3. Content: do you log denials, alerts, state changes and failed logins – and not passwords? Does a critical event have a procedure?
  4. Attention: does anyone really look? How many alerts led to action? What you do not collect you do not see – and cannot investigate.

▶ Open in the simulator