I work daily with organizations regulated by
NERC CIP, and it always helps to place things into perspective. One of those challenges is security event monitoring.
Security event monitoring involves the identification of observable events that may or do represent unauthorized access attempts into a secure environment.
One of the most important purposes of security event monitoring is to identify potential security threats before anything bad happens. It sounds like a great idea, right? However, as with most cyber security-related concepts, the devil is in the details.
The challenge starts with what can be detected… but that’s not quite right. The main sources of security event data are log files that cyber assets are configured to collect.
Now, let’s be clear about a couple of things. First, cyber assets can produce mountains of log file data, most of which is really not relevant to security-related events. Second, what is logged is dependent on each cyber asset's configuration, so one should have an idea of what can and needs to be written to log files to address security event monitoring considerations beforehand.
In NERC CIP, Standard CIP-007 sets the bar for the minimum security events that all cyber assets should be configured to log (where technically feasible). Events that are explicitly covered in the NERC CIP Standards include successful login attempts, failed access and login attempts, and detected malicious code.
There are many other detectable events that may also be part of security event monitoring. Each organization can build its own list of security events to monitor; if an organization is a regulated entity under NERC CIP, that list should naturally include explicitly defined events in NERC CIP.
However, just getting logging configured for the security event types doesn’t solve the problem. Remember, log files can contain a huge amount of information, the vast majority of which is not security event-related. That means log files must be parsed to identify the events, and the parsing rules must be built for many types of systems that log security event information according to different sets of rules.
Once assets are properly configured to log security-related events, the log files must be collected, parsed and normalized to extract a definitive list of actual security-related events.
Of course, once those log files are collected and security events are normalized and identified, that is where the next body of work comes in. The events must be reviewed (and should be reviewed frequently – within 15 days of their original occurrence for NERC CIP), and any appropriate action must then be taken.
With that in mind, there needs to be a formally defined process to review and respond to captured security-related events.
All of these components are necessary for an effective security event monitoring program, and there’s lots of help available, including tools that can simplify much of the complexity involved in detecting, collecting, assessing and responding to security-related events.
No matter how it gets done, security event monitoring should be a core part of every organization’s cyber security strategy, for what you don’t know can make the difference between a secure environment or a news headline announcing a compromise.
About the Author: Terry Schurter is co-author of the book Protecting Critical Infrastructure which will be released in April, 2016. Those interested in the book can sign-up now to receive a 20% discount link as soon as the book is available at this link.
Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.
Title image courtesy of ShutterStock
