What is running on your system and are you keeping track?

Do you know what software applications are running on your system right now?

Or how about ports, protocols, and services (PPS)? Do you know exactly which PPS are communicating with your computers and devices?  Let’s face it…probably not.

Your system probably has things installed and running that you are unaware of. It’s a fact of (security) life! (At least in my experience)

That’s why you need use security listing.

Most folks THINK they know what’s running. But there are always those “sneaky” applications or PPS. Stuff you didn’t know got installed or that you might have overlooked.

And that “sneaky” stuff can communicate outside of your system without your knowledge. Especially if your edge security is weak.

So what difference do these “sneaky” applications and PPS make in the security of your system?

Well, if you expect your system to be secure…you should absolutely know this answer!

I’ll explain what I mean.

Let’s say you have a “sneaky” application installed and it’s communicating back to the vendor for health and status (e.g. phone home).

And for argument sake, let’s say your firewall is not blocking the outgoing communications.

If a vulnerability is announced from that application vendor, how do you know if you’re affected by it?

If there are “sneaky” applications and PPS running, and you don’t know what they are…you won’t know if you’re affected or not.

In this case, you likely increased your risk of a vulnerability exploit…and didn’t even know it!

As the Gieco Caveman guy said…

Not Cool

Obviously you know this is “not cool”! So how do you fix this?

How do you identify all of the applications or PPS running on your system?

And how do you keep track what is PERMITTED or RESTRICTED?

Well, you can do it a few different ways, but here is what I recommend.

1. Scan the Network (Recommended)
The easiest way is to run a vulnerability scan using Nessus, Nmap, or something like that. OpenVAS is an alternative to Nessus if you want something open source.

Analyze the report or command line output and go from there. Look at all the different PPS that are identified by the scanner.

2. Check the local hosts
Lastly, you can check the local machines (Linux, Windows, etc.) and see what the machines are doing with the different PPS and applications.

TCPdump and WinDump can be used here as well. Another option is to use the netstat command.

On a Windows server or workstation, open a command line and enter the command:  netstat | more

If you want to see the installed applications in Windows, type:  wmic product get /format:csv > c:/Software_%Computername%.csv

*Warning…the wmic command will take awhile to complete.  But it will dump everything out into a CSV file.  (Thanks to Helge Klien for that awesome command)

On a Linux or Unix server, open a terminal window and enter the command:  netstat -a | more

You’re likely get a long list of services running on your server. You’ll see the protocols currently running and possibly communicating.

To see the installed applications (packages), reference this article.  They differ based on the type of Linux distribution.

3. Sniff the Network

To sniff the network, you’ll need to use a protocol analyzer like Wireshark.  TCPdump, or WinDump (Windows) are other alternatives as well.

Create a mirror port/monitor session on a network switch and send the network traffic to that switch port.  Plug your sniffer into that switch port and start watching everything flying through the network.  (Ok…it’s a LITTLE bit more difficult than that.  Click Here for an article to help you get started.)

This is likely to be the most time consuming way to identify the various PPS.  You also won’t learn much about installed applications this way either.

 Tracking what is permitted or restricted

Now that you know what to use to find the PPS, let’s talk about if they are PERMITTED to run or not.

First off, you should know it right when you see it. If you see a PPS, like FTP, Telnet, or RSH…these should catch your attention…and should not be running. Unless of course you have an operational need for it.

Same for HTTP, SMTP, and other unsecure PPS.

One way track all of the PPS is to create a list.

An often overlooked aspect of security is what I call security listing.  Security listing is identifying and documenting anything that is permitted or restricted on the system.

Users, applications, PPS…anything you want to control.  They can all be used in security listing.

Listing items that are permitted on the system is called whitelisting. Listing items that are prohibited or restricted on the system is called blacklisting.

Simple right? Full disclosure…this is not a quick and easy task. It can take a few weeks, even months, to get everything right. Then you have to keep it up and maintain it.

But, listing is very important when it comes to maintaining a controlled system baseline (knowing every aspect of the systems operations).

In fact, if your system is required to go through a compliance audit (PCI, FISMA, etc.), it may even be required to have!

Black or White Lists?

So which list if right for you or your system? White or Black lists?

Marcus Ranum, the CSO of Tenable Network Security (makers of Nessus and other fine products) said it best.

“For a number of years – about twenty – I’ve been saying that ‘default permit’ security is stupid. Basically, you’re adopting the approach that ‘everything is allowed’ and then trying to identify the things that are known to be dangerous, in order to block them. We’ve seen this approach used in virtually every area of computer security, and it has been a failure every time.”

In other words…whitelists are WAY BETTER for security than blacklists. So why are blacklists used more often than whitelists.

Bruce Schneier of schneier.com says:

“Traditionally, execution control has been based on a blacklist. Computers are so complicated and applications so varied that it just doesn’t make sense to limit users to a specific set of applications.”

In other words, whitelists don’t make sense for every system.  And whitelists can also take FOREVER to create. But it depends on how deep you go.

If you’re tracking every little thing…get ready to spend lots of time and money to create a whitelist.

And most companies don’t want to invest the time and money to do that.

I’ve found that blacklisting first, then slowly whitelisting is a good compromise.  Identify the “bad stuff” first, then slowly document the “good stuff” after.

Why do I recommend that? For one…it saves time and money! Which is most important to your customer or employer. Security in an afterthought usually.

But, as you’re hardening, scanning, and engineering a system or new baseline, you can slowly identify things that are permitted to run on the system.
You’ll eventually end up with a whitelist that you can use…using the blacklist as a duplicate document to justify restrictions.

Make sense?

Security Listing:  Do you create a black or a white list?

Actually, you can do that many different ways. Manually, which is most common, or you can automate it. Automating can be done using a script or a software application.

I’ve used a combination of both. Using a scanner and sniffer to find everything, then manually document them in a database or spreadsheet.

Then I will add it to a security document, such as a System Security Plan (SSP).

You can list them in the appendix of the SSP, or just keep track of them in a separate spreadsheet or database.

But you should have a list of some kind. And you should include it as part of your formal or official security documentation.

Summary

You should know what PPS are permitted or restricted to run on your system. Otherwise it’s a complete free-for-all for the user.

Scan or manually review the system and document the PPS, applications, or whatever you want to permit/restrict on the system.

Document those in a spreadsheet, database, etc. and include it with your security documentation.

Lastly…set a date/time to review and update the list. The interval is completely up to you. Every 90-180 days is common in my experience.

Whew! That was a long post! But you made to the end!

Thanks for reading this and I hope you found something you can use to make your system more secure.

Brandon