Video Screencast Help

SSIM Rules Improvements - 4.7.4

Created: 30 Jan 2013 | 8 comments

In operation of the SSIM against a diverse range of equipment I have found the default rules have some things that should be obvious have not been added into the rules. I am posting this in the hope we can get a discussion going sharing rules improvements made. Maybe this can even make it back into the Symantec default rules ?

Rule: IRC Bot Net

OR  IP Destination Port = 6667

    IP Destination Port = 6666

    IP Destination Port = 7000

This rule only detects on the basis of port = 6666,6667,7000. It produces false positive from Cisco ASA closing any connection which may have originated from those port numbers to a legitimate port. It also detects blocked inbound attempts, which really don't matter.

I have ANDed this group with the following checks

AND IP Source Port IS NOT IN Authorized_Ports_Outbound ,

and added some standard outbound port numbers to that lookup list 80,443,53,123

OR Option 2 ≠ drop OR Network Traffic Direction ≠ Inbound

Rule: Block Scan

AND Mechanisms DOESNT CONTAIN Port Sweep

    Source Host Policies DOESN'T CONTAIN Firewall

    Source Host Policies DOESN'T CONTAIN Proxy

    Mechanisms CONTAINS Port Scan

So this rule picks up a false positive when there are any probes from Vulnerability Scanners. Interestingly, Symantec have added the following to the rule Web Vulnerability Scan, but not the others !! ???? So I very simply customised in the same way the following rules:

Rule: Vulnerability Scan Detector

Rule: Port Scan Detector

Rule: Ping Scan Detector

Rule: Internal Port Sweep

Rule: External Port Sweep

Comments 8 CommentsJump to latest comment

Vikram Kumar-SAV to SEP's picture

Hi Gareth,

I understand your concern, butthe default rules gives you room for improvization and refinement..

Trust me in many organization out-of-the-box rules would work perfect and in places it will generate thousands of FP incidents in a day.

So SSIM rules should be looked from both InfoSec and IT Sec angles..What is the requirement to what can be mapped.

Every rules should be evaluated whether you really need it or not and if not then what should replace it.

Every Org. has different positioning of Security devices and types of devices they use.

Some people like to get incidents on Dropped packets, even public IP's blocked that made certain number of attempts.

Malware Rules can totally be defined how big your infrastructure is the more number of clients you will have to keep the interval and hosts accordingly.

Vikram Kumar

Symantec Consultant

The most helpful part of entire Symantec connect is the Search use it.

JH-Analyst's picture

I like the topic of discussion as this is something that is very important to me and I've been constantly researching also. While I agree with Vikram's assessment that every environment is different and will, therefore, require a diverse default set of rules, I also think Gareth (OP) is on the right track that some of these system rules are due for revisiting.

Many of the FPs that result from the rules, in my observations, are related to proxy traffic and firewall traffic. It is with that perspective that I'm trying to evolve a set of rules that take those behaviors into account.

Rules, such as IRC Bot Net, are potentially so ambiguous in their configuration that they may be better suited as suggested tuning brainstorming rather than an actual rule one may deploy thinking that it will catch all IRC behavior.

Outbound firewall traffic to port 80, however, does not necessarily mean the traffic is innocent in cases where the exploited machine uses port 80 to retrieve its C&C Instructions or initiate a reverse TCP backdoor, since port 80 is the most likely allowed port through the firewall. This makes it quite difficult to create rules that eliminate web browsing activity with more subversive, devious behavior. Still working on that :)

Vikram Kumar-SAV to SEP's picture

I would agree on that..out of box rules are very generic and some rules would create a lot of false positive if enabled..But I like many of the rules which are default they are good directly out of the box..

But I guess there arent enough Idea's posted on the forum on what type of Rules they would like to see by default. But remeber you have to consider that it shouldn't be relevant only to your organization but to the majority.

Vikram Kumar

Symantec Consultant

The most helpful part of entire Symantec connect is the Search use it.

GarethR's picture

A few of the default rules do work well, but many of the others need enhancements that are generic, and not specific to a customer's site, such as those I referenced earlier. Some of these edit should have been obvious and included by Symantec in the intial release.

So the Symantec SSIM Rules Guide is a good place to start, but it could say so much more, and the default rules which can be updated via LiveUpdate should be improved to give a better starting point. Without this, there is a lot of work any administrator HAS TO DO before the SSIM can become effective. Symantec needs to review where the SIEM competitors are, and incorporate improvements or they will keep moving away from the Magic Quadrant top right quarter (2010=Leaders, 2012=challengers).

The Rules and Queries are updatable by Liveupdate it says in the manual. However, there is no indicator on a System Rule showing its save date, and thus being able to see when default rules are updated by LiveUpdate. Maybe this can be included in a future SSIM release. The rule parameters can be changed, and we have done this for password guessing for example to match corporate policy as p99 (Rules Guide).

So, I am still looking for other ideas for improving the rule set, and will continue adding ideas for those rule changes that have been made to make the SSIM here work more effectively, reducing false positive.

Gareth Rhys

Managed Services, SSIM, SCSP, SEP

GarethR's picture

Noted missing text from my above initial post:

Source Host Policies CONTAINS Vulnerabity Scanners

And add any authorised vulnerability scanners by IP Address to the Asset List, setting the policy Vulnerability Scanners.

Gareth Rhys

Managed Services, SSIM, SCSP, SEP

Vikram Kumar-SAV to SEP's picture

Also there are rules which can be same even generating more than 1 incident.The generic rule of Malicious URL also produces large amount of false positive at times..

Also I find the administrators and consultants do lot of creative work in terms of Rules on the SSIM, but for some reason they find it confidential sharing the rules.

Writing complex rules can be challenging and the most important part is selecting the right template

However a colleague of mine has written a good article which i'd like to share

Vikram Kumar

Symantec Consultant

The most helpful part of entire Symantec connect is the Search use it.

Laurent_c's picture

One way to avoir false positive is to make sure your netowrk section is populated correctly. As well as your asset table.

A lot of default rule use filter based on traffic direction. For this to work the Networks have to be defined.

Second part is asset table and making sure all Asset are correct and have for example the right policy assigned.

This will help reduce a lot false positive.

GarethR's picture

The Networks Lookup table is initially poulated with RFC addresses , , and which will detect correctly for any network using the RFC addressing internally.

From there on, you can define further internal network to define subnets of RFC or use of public IP internally, but also note that the firewall devices themselves often populate the direction field.

Assets in this infrastructure are imported from SEP installed on most Servers and workstations, and from Network Vulnerability scanning. Policies are applies where relevant, for PCI Protected Assets (Symantec have not updated the definition of this Policy since introduced by VISA !!) and also for Vulnerability Scanners.

The Host Policy for Firewalls and Proxy is OK, but is **wrongly used** in the default rules that are in the first post - because they are the logging device, not the Source Host (Source Host Polices = Firewall used in default rule to reduce false positive - it won't, because it the firewall isn't the Source Host in communications logs as used detecting Port Scans etc.). I am investigating how to create a rule that detects Port Scan followed by Accept from same host - now that IS something to be more concerned about; port scans denied happen all the time and are not very significant.

That is why I am suggesting that we have this discussion to help improve the default (and little updated) rules in SSIM.

Gareth Rhys

Managed Services, SSIM, SCSP, SEP