Security Testing and Monitoring

Security testing and monitoring. These are how an organisation finds its weaknesses before attackers do, and detects them when they try. Both are easy to have in name only.

The scene. The security team runs a monthly vulnerability scan and files the report, and calls it their penetration test. Separately, every system ships its logs to a central store that has grown to terabytes, which no one has ever queried. So the organisation believes it both tests and monitors its security, when in truth it does neither as intended: a scan is not a pen test, and logs no one reads are not monitoring.

The exam draws a firm line between two activities people conflate. A vulnerability scan is largely automated and breadth-first. It enumerates known vulnerabilities across many systems, missing patches, weak configurations, exposed services, and reports them. It is fast and good at coverage, but it reports potential issues without proving they can be exploited. A penetration test is deeper and often manual. A skilled tester attempts to actually exploit weaknesses, and chain them together, to demonstrate what a real attacker could achieve.

So the difference is: find broadly, or exploit to prove. A scan tells you what weaknesses might exist; a pen test shows what an attacker could do with them. They are complementary, but they are not the same, and a scan report is not a penetration test.

They complement each other: scanning gives breadth across many systems, testing gives depth by proving real risk. You want both, but one does not substitute for the other. When a question contrasts them, scanning is automated identification of known issues, and penetration testing is active exploitation to demonstrate real impact.

Finding weaknesses is one half; detecting attacks as they happen is the other. A S-I-E-M, security information and event management, is the common tool: it aggregates logs and events from across the estate, correlates them, and alerts on patterns that indicate an attack, detection that individual system logs cannot give.

Correlation is the point. An attack often shows up as small, unremarkable events on several systems, a failed login here, an odd connection there, that only reveal themselves when brought together. Individual system logs, viewed in isolation, miss this; a S-I-E-M is what turns scattered records into a detection.

Which brings us to the terabytes no one queries. Logs are a detective control only if they are actually reviewed and acted upon, by people, by a S-I-E-M, or both. Collected and never examined, they faithfully record an attack that nobody sees, so detection never happens.

It is the same silent-failure problem as the unmonitored batch job in Domain four: the event occurred, the record exists, and no one is watching. So the finding in the scenario is not the storage cost; it is that logging without monitoring provides no detection. The value was never in generating the logs. It is in the monitoring and the response that logs make possible.

So detection needs response. You can only respond to what you see, and logging without monitoring provides no detection. The finding is not the disk the logs consume; it is that nothing is watching them.

And why test at all: testing and monitoring are how an organisation finds its weaknesses before attackers do, and detects them when they try. A scan filed and forgotten, and logs collected and ignored, are both security in name only.

So carry this away. A vulnerability scan identifies known weaknesses broadly; a penetration test exploits them to prove real impact, and one does not substitute for the other. And logs are only a control when something reviews them and can raise an alarm; unread, they detect nothing, however complete they are.