Hey folks, If you’re not aware, NSACyber made a github repo that they’re calling ELITEWOLF
To make a long story short, it is a collection of rules that are meant to detect activity involving ICS Controllers from a variety of vendors – SSH login attempts, Browsing to the embedded web server on a controller, TELNET and FTP Banners, Default Credentials, Default SSL certificates, viewing certain pages that could contain sensitive information about the controller’s configuration, etc.
While most of this stuff is considered routine activity, there are benefits to monitoring for these events. These rules can be used as part of an auditing package for network activity to ICS controllers. The other benefit is being able to use the rules to detect ‘routine’ activity from non-standard sources – if a host IP address starts initiating connections to environment controllers suddenly, that is suspicious. If systems start trying to authenticate to controllers using default credentials, that is also suspicious.
The rules were released with a CC0 1.0 license, so that means that anybody could copy or utilize the contents of the repo to their hearts’ desire. So to that effect, I copied the existing rules and enhanced them for performance and accuracy to the best of my ability, then added them to the Emerging Threats Open ruleset. These new rules, should be in the ET SCADA ruleset. Additionally, I created a few Affected Products categories for these rules – Schweitzer Engineering Labs SEL Series Tridium Niagara Series Siemens S7 Series and Allen-Bradly/Rockwell Automation Series. I also added the ICS Attack Targets category as well.
Known Issues
The only obvious known issues I can think of are that these rules can be really noisy. First and foremost, if you are not using any of the Control Systems the rules are written for, consider disabling the rules entirely to reduce alert fatigue and system resource utilization.
Currently the rules are configured to detect traffic to or from ICS assets from any source or destination IP address – those could be internal IP addresses or external IP addresses. This is because in some cases, some organizations have ICS devices exposed to the internet, and should probably be aware when strangers are poking those controllers. While, in other cases, ICS assets are secured behind network security devices, and the access attempts are much more likely to come from compromised systems within an internal network.
We have to create our rules to account for the widest audiences and use case scenarios possible, so my advice for those who are seeing an exorbitant number of alerts who are not interested in using the rules for auditing purposes would be to make use of the multitude of ways in which Suricata allows you to squelch noisy rules:
- Create a “local” version of the rule and re-define the rule header to better suit your environment. For example, if the network 10.9.8.0/24 talks to your ICS controllers frequently over HTTP, and this is normal traffic, maybe consider making a rule where the header reads
alert http ![10.9.8.0/24] any -> $HOME_NET any
- Create a local pass rule that will pass rule traffic that triggers the criteria, and not alert on it. Remember that rules with the
passaction are, by default, evaluated before rules with thealertaction. For an example pass rule, lets use subnet 10.9.8.0/24, and let’s say we want to create a pass rule for 2048639. Our new “local rule” will have the sid1000000:
pass http 10.9.8.0/24 any - > $HOME_NET any (msg:"ET SCADA [nsacyber/ELITEWOLF] Allen-Bradley/Rockwell Automation Information Disclosure Attempt - Crashdump Display"; flow:established,to_server; http.method; content:"GET"; http.uri; content:"/rokform/advancedDiags?pagereq=crash"; fast_pattern; classtype:web-application-activity; sid:1000000; rev:1;)
- Consider setting Thresholds to keep alerts from triggering too frequently – Thresholds can define a limit as to how many times in a time period a rule triggers, or can define a threshold that requires the rule criteria to trigger X number of times in Y timeframe to trigger an alert. Thresholds can be define in the rule body itself (in a new local rule), or may be configured in a global thresholding file, called
threshold.config– and enabled in thesuricata.yaml. Here is the syntax. We’ll be picking rule 2048640 - request for home.sel
Here is a threshold:
threshold gen_id 1, sig_id 2048640, type threshold, track by_src, count 5, seconds 60
“Do not trigger an alert for this rule unless 5 alerts have been seen from the same source IP address in 60 seconds”
Here is a limit:
threshold gen_id 1, sig_id 2048640, type limit, track by_src, count 1, seconds 60
“Only allow a single alert for this rule from unique source IP addresses once every 60 seconds”
- Another option, which can only be configured in the
threshold.configfile is called a suppression. Suppression can be used to stop a rule from triggering completely, or can stop a rule from triggering when the source or destination IP address specified is present:
For example, Let’s pick on rule 2048648 – A rule detecting a default Common Name for a Schweitzer SEL controller being sent in the server_hello back to a client. Users can put this in their threshold.config:
supress gen_id 1, sig_id 2048648
“Never show me any alerts for rule 2048648”
What if we want to ignore events where the destination is systems in the 10.9.8.0/24 subnet?
suppress gen_id 1, sig_id 2048648, track by_dst, ip 10.9.8.0/24
“Never show me alerts for sid 2048648 where the destination is in the 10.9.8.0/24 network”
and if you have multiple networks (10.9.8.0/24 and 10.11.12.0/24 for example):
suppress gen_id 1, sig_id 2048648, track by_dst, ip [10.9.8.0/24,10.11.12.0/24]
Finally, if none of these are your style, maybe consider using BPF (Berkeley Packet Filters) and/or Capture hardware filtering. BPF can get pretty complicated pretty fast, but the ability to define what to send and what not to send to Suricata at all is pretty powerful. This is a great resource on how to create BPF filters, and here is the corresponding Suricata documentation for including them in your suricata config.
“Never show me alerts for sid 2048648 where the destination networks are 10.9.8.0/24 OR 10.11.12.0/24”
Remember: These rules alone do not detect malicious activity. It is only through analyst review, auditing, and context of which hosts should be talking to which control systems that you will be able to use these rules to detect anomalous activity.
The only other advice I can offer here is that if you use any of these methods for reducing rule alert noise in your environment is to document what you have done and how your configuration was altered. It could be a word doc, a text file, a spreadsheet, a ticket in a ticketing, system, or an internal wiki, but when it comes time to review your IDS config and rules, knowing why those configuration changes exist is priceless.
Contributing
As always, we count on the user community to help be our eyes and ears. If you have rules you would like to contribute to help detect activity on ICS or SCADA devices, we would be happy look them over and possibly include them in the ETOPEN ruleset. Remember that ETOPEN is free for everyone and ensures wider distribution to the community. Likewise if you have ideas for improvements on existing rules, or false positives to report, let us know. We want your feedback and constructive criticism to make better rules.