Using PVS to detect Corporate policy violations

Most companies have some sort of policy in place which defines network or computer activities which are considered 'Acceptable computer usage'.  Such policies are often difficult to enforce.  The Tenable Passive Vulnerability Scanner (PVS) can help companies detect and report on inappropriate usage. This blog post discusses how the PVS can be used to look for policy violations and items such as credit card numbers, social security numbers and other types of sensitive content in motion.

Tenable ships PVS with (at the time of this writing) about 3,000 distinct checks.  The primary focus of these plugins is to discover hosts, applications and their related client/server vulnerabilities. The entire list of built-in PVS checks can be perused here.  As you will note, there are already many plugins (or even entire families) which detect and report on what many corporations would consider 'Inappropriate usage'.  These categories or plugins include, but are not limited to,:

• Game server detection
• Botnet client and server detection
• Peer to Peer file serving
• IRC server/client
• Chat clients
• tunneling software or applications like Tor, gotomypc, and logmein
• and more

Below is an example screenshot of PVS discovering an internal system which is allowing external, remote access via logmein.com. It is being viewed under the Security Center.:

Detecting Custom Activity Prohibited by Policy

What if, however, you are a company that would like to look for something specific with respect to your corporate policies and guidelines? Creating your own PVS policy file may be a good investment of your time. 

Tenable has created detailed documentation on writing custom plugins.  The documentation can be viewed here.  The documentation details how to write detection rules for the PVS which are saved as files referred to as "prms".

If, for example, you wanted to view all users who were accessing a competitor's mail service, or all users who were managing their myspace.com web page from the corporate network, etc.,  you could create a custom prm policy file to detect and report on these issues. 

Let's walk through a quick example.  Our first plugin will detect users logging into myspace.com accounts.  We will first create a unique plugin ID of '9000'.  So, the first line of our plugin will be:

id=9000

Next, we will want to have a description of what the vulnerability detects.  So, we will create a description of:

description=The remote client was observed logging into a myspace.com account.  You should ensure that such behavior is in alignment with corporate policies and guidelines.  For your information, the user account was logged as:
  %L

The '%L' will be the results of our regular expression statement which we will create later.  In a nutshell, we want to log the source address of the offending computer as well as the UserID that they used to log in.  Next we will create a distinct name for our plugin.

name=POLICY - myspace usage detection

Note that I begin the name with the string 'POLICY'.  This will make all POLICY violations easily searchable from the Security Center interface.  In addition, you could actually define a Security Center dynamic asset list which contained only POLICY violators. 

Our next field will be a family.  As this is a client web application (a browser), we choose the family ID of:

family=Web Clients

And, since this is a web browser, we can assign a dependency which will tell PVS to only look at clients which have been observed surfing the web:

dependency=1735

Further, since we are looking at client traffic, we will define:

clientissue

Next, we will assign a risk rating for the observed behavior:

risk=MEDIUM

In the final section we will create 'match' and 'regex' statements which PVS will look for passively.  We want all of these statements to be true before we flag the client for inappropriate usage:

match=>POST /

The web request must begin with a POST verb.  This will weed out all those 'GET' requests right off the bat.

match=^Host: login.myspace.com

We want to ensure that they are posting to the host 'login.myspace.com'

Finally, we have a match and regex statement which detects their login credentials: 

match=email=
regex=email=.*%40[^&]+

Putting it all together, we have a single plugin which reads like:

id=9000
description=The remote client was observed logging into a myspace.com 
account.  You should ensure that such behavior is in alignment with 
Corporate Policies and guidelines.  For your information, the user 
account was logged as:  %L
name=POLICY - myspace usage detection
family=Web Clients
dependency=1735
clientissue
risk=MEDIUM
match=>POST /
match=^Host: login.myspace.com
match=email=
regex=email=.*%40[^&]+

You could name this plugin myspace.prm and add it into the /usr/nevo/var/nevo/plugins/ directory.  Or, for central management of PVS policy plugins, you could log into the Security Center as the 'tns' user and upload the plugin into the /opt/sc3/proxy/outbound directory. 

When the behavior is caught, it will generate a Security Center entry like:

If you wish to create a policy file which included multiple checks, you will need to use the reserved word 'NEXT' within the policy file.  Example:

id=9000
rest of plugin
NEXT
id=9001
etc

Detecting Confidential Data In Motion

Finally, many organizations will want to ensure that confidential data does not leave the network.  PVS can look at binary patterns within observed network traffic.  So, for example, if the security group had the ability to modify or specify modifications for critical corporate assets, then PVS will have the ability to detect these files being passed outside the network.  Example:

Create a document which has a binary string of:
0xde1d7f362734c4d71ecc93a23bb5dd4c and
0x747f029fbf8f7e0ade2a6198560c3278

A PVS plugin could then be created which looked for this pattern

id=9005
trigger-dependency
dependency=2004
dependency=2005
hs_dport=25
description=POLICY - Confidential data passed outside the 
corporate network.  The Confidential file don'tshare.doc was 
just observed leaving the network via email.
name=Confidential file misuse
family=Generic
clientissue
risk=HIGH
bmatch=de1d7f362734c4d71ecc93a23bb5dd4c
bmatch=747f029fbf8f7e0ade2a6198560c3278

How were these binary codes generated?  They are just md5 hashes of the following strings:

"Copyright 2006 BigCorp, file: don'tshare.doc"
"file: don'tshare.doc"

The security compliance group maintains the list of mappings (confidential file to md5 hash).  The md5 hash would be embedded within the binary file and could then be tracked as it traversed the network.   

You can do similar checks against ascii strings (if, for example, the attacker cut-and-pasted confidential data into an email).  You just create text watermarks which appear benign to the casual observer and map to a specific file name.  For example:

"Reference data at \\192.168.55.2\c$\shares\employmentfiles for HR data regarding Jane Mcintyre" could be a string which maps to Finances.xls.  A PVS plugin could look for the string like:

id=9006
trigger-dependency
dependency=2004
dependency=2005
hs_dport=25
description=POLICY - Confidential data passed outside the 
corporate network.  Data from the confidential file Finances.xls was just 
observed leaving the network via email.
name=Confidential file misuse
family=Generic
clientissue
risk=HIGH
match=Reference data at
match=192.168.55.2\c$\shares\employmentfiles
match=for HR data regarding Jane Mcintyre

The two plugins above (id 9005 and 9006) would detect files leaving the network via email.  Most corporations have a list of ports which are allowed outbound access.  SMTP is typically one of these ports.  Other ports may include FTP, Messenger client ports (AIM, Yahoo, ICQ, etc.), Peer2Peer (GNUTELLA, bittorrent, and more).  Depending on your specific network policy, you may wish to clone plugins 9005 and 9006 to detect these strings on other outbound protocols.

Policy Abuse Files

Tenable is releasing four policy files which look for Social Security Numbers, Credit Card numbers, surfing of Pornography, and generic policy violations.  The two examples, from above, are included in the 'policy.prm' file.  Any one of these files could be used as a template for creating a specific, corporate policy file.  The four files can be found at:

• http://www.tenablesecurity.com/pr0n.prm
• http://www.tenablesecurity.com/policy.prm
• http://www.tenablesecurity.com/cc.prm
• http://www.tenablesecurity.com/ssn.prm

After creating your custom policy files, the Security Center can be used to centrally manage and disperse these policy files to all PVS instances.  To do this:

1. Log in as user 'tns'
2. Upload the policy files to /opt/sc3/proxy/outbound

That's it!  The Security Center will disperse the policy files and begin reporting on policy infractions.