At an MSSP, a customer ACL log shows denies, and the IDS placed behind that ACL has no events for the same traffic. What is the correct reading of those two records?
Select an answer to reveal the explanation.
Short Explanation
If the bouncer stops someone at the street door, the camera in the back hall has no picture of that person. You should read the ACL denies as packets that did not reach the IDS behind them. The trap is encryption, a fail-open sensor, or NetFlow replacing the IDS.
Full Explanation
An access list that denies a packet drops it at that point. A sensor placed behind the list never receives the denied packet, so it has nothing to log for that flow. The ACL deny plus a silent IDS is explained by path order, not by a second failure mode. "Denied packets logged by the customer ACL did not reach the IDS that sits behind that filter". The deny is in front of the sensor, so the absence of IDS events follows from packets that stopped at the ACL. "The IDS saw no events solely from encryption hiding the customer payload". Encryption can hide payload on traffic that still arrives at a sensor. It does not explain empty IDS output for packets an upstream ACL already denied. "The IDS failed open and allowed the denied packets to continue toward customer hosts". A fail-open reading would mean inspection stopped and the packets continued. The ACL log says those packets were denied, so they did not continue, and these two records do not show a fail-open event. "NetFlow collection replaced the IDS and now handles detection for this customer". Nothing in the two logs says the IDS was removed or that a flow summary took over detection. The IDS is still the sensor behind the ACL, and it is quiet because the packets did not arrive. Exam caveat: do not treat fail-open as a default from a quiet sensor. The deny log already accounts for the missing events. Operational check: compare ACL deny times with the IDS store for the same source and destination and confirm those flows are absent behind the filter.