8 posts from May 2008

 

Nessus 3.2.1 Released -- New Report Filtering Features Added

Tenable Network Security has released version 3.2.1 of the Nessus vulnerability scanner. This point release includes a variety of small bug fixes as well as a new report filtering interface for the Nessus client. This blog entry will discuss the new Nessus features, bug fixes and reporting filters for the Nessus Client.

Nessus Release Notes

New features

  • New multi-criteria report filter in NessusClient. There is more on this later in the blog.
  • On Mac OS X, it is now possible to authenticate with NessusClient to a remote Nessus server via a SSL certificate
  • New NASL functions - bn_dec2raw(), bn_raw2dec(), bn_hex2raw(), bn_raw2hex(), rsa_public_encrypt(), rsa_private_encrypt() and rsa_private_decrypt()
  • New options in nessusd.conf : 'enable_listen_ipv4' and 'enable_listen_ipv6' let the user disable IPv4 and IPv6 bindings
  • Builds for Ubuntu Linux 8.04 and Fedora 9
  • Support for Windows 2000

Bug fixes in this release

'nessus' command-line client :

  • report entries longer than 16Kb would be truncated
  • When exporting a report to the .nessus format, some report entries could sometimes be truncated
  • When exporting a report to the .nessus format, backslashes would not be properly escaped

Nessus server :

  • Fixed a concurrency issue when too many threads write to the plugin database
  • On Solaris, SIGCHLD signals would not always be properly handled, thus leaving zombie processes
  • Fixed a segmentation fault in nasl occurring on 64 bits systems

Nessus client :

  • When searching for plugins, the filtering interface now works as expected

Plugins :

  • ssl_ciphers.nes has been removed in favor of the new ssl_ciphers.nasl
  • Fixed a segmentation fault in nessus_tcp_scanner.nes

Packaging :

  • The %uninstall section of the RPMs contained a bug which would force users doing an upgrade to call 'chkconfig nessusd on' manually. Due to the nature of this bug, be sure to call 'chkconfig nessusd on' when upgrading from 3.x.y to 3.2.1
  • The Debian 4 i386 build was incorrectly registering itself as x86-64, thus breaking 'nessus-update' on Debian 4 i386

Report Filtering

In the below screen shot, under version 3.2.1 of the Nessus Client on OS X, when viewing a report a new "Filter..." option is now available.

Filterview

Clicking on the "Filter..." button will present the user with a dialog box that can be used to create a simple or complex filter statement. This box is shown below:

Filter

This box allows the Nessus user to create a set of rules where any or all of the following conditions are met:

  • Plugin ID
  • Plugin Name
  • Port Name
  • Host Name Starts With
  • Host Name Contains
  • Report Contains
  • Plugin Severity

All fields use a text box to enter desired strings or numbers except for the severity level which lets the user choose a list of low, medium or high.

By default, all options set with "any" so you could choose port names of http, https and smtp to give all web and email server vulnerabilities. If the "all" option is chosen, then only vulnerabilities matching the entire criteria will be listed. Keep in mind that if you choose two filters that create exclusive sets such as a port rule to match "http" and a second rule to match a port name of "smtp" you will most likely not have any matching results.

Once a desired filter statement is set, only the matching systems with the matching vulnerabilities are displayed. Also, only the matching vulnerabilities on those systems are displayed as well.

Filters that are in effect also control what type of data is sent to the .html, .nsr or .nbe file formats. This allows you to select what type of data goes into your .html web reports or that gets exported.

To reset the filter, simply choose the "Filter..." button again and reset the filter.

 

CIO Blogathon - Open Source in the Enterprise

Logo_blogathon_cio_vert I recently got invited to contribute to a new blog at CIO online about open source in the enterprise. User's of Nessus know that Tenable focuses on as many platforms as possible to test for security issues, including open source OSes like SuSE, Red Hat and FreeBSD.  Nessus is also available for many of these platforms.

Our enterprise customers also know that we take logs from Apache, MySQL, Sendmail and many other open source applications very seriously.

This is something new for CIO, but other contributers include folks from IBM, MySQL, the 451 Group, Novell and many other users who manage or produce open source technologies and services that are used in the enterprise. Initial topics being discussed include outsourced management of open source applications, security and virtualization.

The blog is located at:

The initial posts from executives participating is also at:


 

Boss, I think Half of our FTP Servers are fake!

Several new plugins for Nessus were recently introduced which can detect FTP servers that are fake:

The basic concept is that a hacker, botnet, malware or virus needs to have some sort of method for communication, to receive commands, to transfer data or provide continued access so they use a backdoor. But rather than use some sort of custom or proprietary command and control, they use a service that looks like an FTP server.

By "looking" like an FTP server, connecting to the daemon port (usually TCP port 21, but could be any port really) results in an FTP banner. Some of the fake FTP daemons that have been encountered even implement some of the actual FTP protocol. However, most fake daemons don't support all of the FTP options and error codes which is what the above Nessus plugins try to ferret out.

Below are two screen shots of different real-world systems that had an FTP service discovered on a port other than 21. One even claims to be a Microsoft server.

Fakeftp1 Fakeftp2

These plugins are available in the FTP and Backdoors Nessus plugin families. If you are doing a complete audit of a system or network, including these checks is a good idea. If you would like to simply scan your network for these checks, the following Nessus policy file can be used to quickly run your scans with the Nessus Client.

Download ftp-backdoor-scans.nessus

It includes three polices that enable the four FTP checks and "Experimental" NASL plugins. One policy performs a full TCP port scan, the other a generic scan and the last one just looks at port 21. To use this policy, download this file to your system and open it up with the Nessus Client and then connect to your Nessus canner and add your target network ranges. If you have not performed a plugin update recently, or don't have automatic updates enabled, make sure you grab the latest plugins (which you should be doing anyway) before trying this policy.

These plugins were also built to minimize security warnings. For example, if a fake FTP server always logs you in this can end up mis-identifying it as a valid Anonymous FTP server.

The hunt to find these types of backdoors should throw into light how your organization can detect these types of changes:

  • Do you have some sort of realtime network monitoring that can alert on new services? Products like the Passive Vulnerability Scanner sniff your traffic in real time and can send an alert when they find new hosts, services and vulnerabilities.
  • Do you have some sort of way to compare ongoing active vulnerability scans with each other and identify what is new? Products like the Security Center and Nessus automatically produce reports about what is new for every scan and also keeps a historical history for each vulnerability for when it was first found and last seen.
  • Do you have some sort of process to identify services that are unauthorized? Most Nessus users tend to think about finding vulnerabilities and mitigating the critical ones, but for compliance and consistency, many organizations simply want to know if a server or service is authorized or not and if it is being managed.
  • And if you do find such a backdoor on your network, being able to turn to netflow, firewall logs, IDS logs or whatever you have generating logs is also important. Products like the Log Correlation Engine can show you potentially how this system was compromised and if any other local systems have been communicating with it.

These plugins were written by long time Nessus plugin contributer Michel Arboi. Michel has his own blog, which includes lots of very good Nessus information such as a recent post on how to configure Nikto within a Nessus scan.

We've blogged before about hunting backdoors and detecting compromised hosts with Nessus. If you are hunting for these types of issues, also keep in mind that any high-port FTP service should be suspected, as that is a very common backdoor file transfer technique. If this topic is of interest to the reader, the older blog postings are listed here:

 

SSH Auditing - New Detected Vulnerabilities and New Features for Nessus

Nessus has several new features for auditing systems via Secure Shell and coincidentally, there was a major vulnerability announced this week regarding OpenSSH servers whose public keys are trivially guessable. This blog entry discusses these new features and SSH audits.

Full "su" and "sudo" Support

All Nessus users now have the ability to perform their credentialed patch and vulnerability auditing with the support of "su" or "sudo". Previously, Nessus users were limited to simply specifying a username for the Unix audit to occur with that had limited support for sudo.

Available as a new scan preference option, Nessus users can now specify credentials to log into a remote system, and then additionally invoke "su" or "sudo" with a separate password.

In addition, if an ssh known_hosts file is available and provided as part of the scan policy, Nessus will only attempt to log into hosts in this file. This can ensure that the same username and password you are using to audit your known SSH servers isn't used to attempt a login to a system that may not be under your control.

Below is a screenshot of the Nessus Client SSH credentials page.

Sshsudo

When auditing UNIX systems via su or sudo, please keep the following items in mind:

  • If your UNIX system has been tightened down to limit what sort of commands can be executed or files accessed by remote users, this may affect your audit. You should compare non-root audits with a root audit if you suspect the audit is being limited due to excessive security.
  • When scanning with known_hosts, the Nessus scan still needs to specify a host to be scanned as well. For example, if you scanned a class C but uploaded a known_hosts file that only contained 20 individual hosts within that class C, Nessus would just scan those hosts in the file.
  • Currently, su and sudo support is not available to perform UNIX configuration audits, but this will be available shortly.

Testing for Weak SSH Keys in Linux Distributions

For Debian and Ubuntu Linux distributions, any SSH, SSL or other cryptographic keys generated through OpenSSL since 2006 were not sufficiently randomized. This resulted in all Debian and Ubuntu systems using one of 32768 unique keys. This means that any type of SSH or SSL security which relied on encryption keys is now easily guessable by a remote attacker.

Although most of the coverage of this issue has been dedicated to SSH servers which have been secured with public/private keys, this issue also impacts SSL encrypted web servers, users of the the OpenVPN client and all applications using encryption that generated keys with OpenSSL. Links to the original vendor vulnerabilties are below:

Nessus plugin #32314 "Debian OpenSSH/OpenSSL Package Random Number Generator Weakness", audits Debian and Ubuntu systems without credentials (you can scan without a password) to find systems that have an easily guessable key.

Although the focus of this vulnerability has been on SSH, all cryptographic material on these systems maybe suspect including SSL. This implies secure web servers running on Debian or Ubuntu may also be at risk. Nessus plugin #32321, "Debian OpenSSH/OpenSSL Package Random Number Generator Weakness (SSL check)", performs this check on SSL web servers without requiring credentials.

These two previous new plugins are server focused. To test for client side weak encryption with this same bug, Nessus plugin #32320, "Remote host has weak Debian OpenSSH Keys in ~/.ssh/authorized_keys" is now available as well. This plugin requires credentials (and you can use su/sudo as well now), and analyzes every user's authorized_keys file to ensure that it does not contain any weak SSH key.

Each of these new SSH audits are available to Nessus Direct Feed subscribers and Security Center customers. 





 

Tenable updates plugin subscription model for Nessus Vulnerability Scanner

Tenable Network Security Inc. today announced an update to its Nessus subscription model that will benefit home users and qualifying charities around the world. We've posted a letter and a FAQ about the changes at nessus.org.

I was also recently interviewed about the license change for the Network Security Podcast by Rich Mogull and Martin Mckeay. The direct url for the interview is:

 

Visualizing Nessus Working Harder For You

Recently, several images were uploaded to the SecViz - Security Visualization web site which visualize how hard the Nessus, Saint and Retina vulnerability scanners actually work. Default scans for each scanner were performed in full view of a Snort sensor and the alerts from Snort were sent to Prelude for visualization with "pig". The visualization allows understanding of how many different and unique techniques are performed by each scanner. Below are screen shots for the results from each scanner:

Saintscan Retinascan Nessusscan
Saint Results
Retina Results
Nessus Results

When I first saw these results, I didn't think they were entirely relevant. The visualization is using Snort events, which means that all of the scanners might be trying techniques that Snort might not detect. For example, when Nessus performs a variety of non-credentialed Windows checks over ports 445 and various Windows RPC services, Snort generates some events, but it does not generate a unique event for every custom probe. However, after the author of these posts to SecViz contacted me and pointed out some of the test results, I thought it was a good blog topic. The raw results for Nessus included 1019 alerts, 166 alerts for Saint and 76 alerts for Retina which was fairly significant.

Since I didn't perform this test and did not duplicate it, I am not asking readers to draw any specific conclusions from these numbers. However, I strongly hope that readers perform their own tests of this nature to gain an understanding of how hard your assessment technology is working.

If you have multiple scanner technologies and various methods (NIDS, HIDS, SIM, NBAD, .etc) of detecting these probes, then doing comparison scans of the same targets can have interesting results. You may find that your default scanning policies aren't aggressive enough. Looking at how scanning can generate IDS events, netflow, logs and other types of data from scanner to scanner can help you understand what the scanner is doing and when. Keep in mind that if you are performing credentialed audits, ideally your security monitoring shouldn't see much other than an agent's processes working or remote logins via the Windows domain, Secure Shell or SNMP.

To illustrate this concept, I performed a scan of my target network with a remote Nessus scan and a free Qualys scan. Below are screen shots of from the Security Center and Log Correlation Engine I use for testing. The targets had http, https, ftp, vnc, ssh and several other protocols open during the scan. The results were both "zoomed" to the start and stop time of the scans.

Lcenessus Lcequalys
Nessus
Results
Qualys
Results

If you are not familiar with the LCE, each log, flow or event gets a name. Something like an Apache 404 error log will be normalized as an "Apache-404_Error" name. The graphs above show a time line from left to right. So for the Nessus scan, there are some initial surges in events of SnortET-Scanning (a normalized name for Emerging Threats Snort port scan rules), a Snort-TCP_Scan event and a bunch of NetGear-Blocked_TCP events. What follows are a variety of Snort and system logs that get mapped into a variety of normalized web events. The Nessus scan also had 765 VNC login and logoff events.

Being able to take these types of activity summaries and compare them is very useful. For example, the Qualys scan performed far many fewer VNC logins than the Nessus scan did. Does this mean the user running the scans configured the scans incorrectly, or does this mean there were less actual checks being performed?

Lastly, performing this type of analysis can not only help you understand how hard your scanning technology is working, but you can make sure that your logging infrastructure is also working. When I started this blog entry, I realized I was getting Snort port 80 web events, but the actual logs from my web servers were not being sent to my Log Correlation Engine. I had reverted a target virtual machine which was sending syslogs to the wrong Log Correlation Engine.

Conclusions and Recommendations

I'm sure some readers will interpret this blog as slight against non-Nessus vulnerability scanners, but the point I'm really trying to make is that if you look at the effects of a scan through some sort of network monitoring solution, you may be able to learn not only how your scanner works, but how it interacts with your network.

This technique can be used for several different tasks:

  • If you are evaluating a vulnerability scanning technology that is not leveraging credentials, looking at the logs generated by your SIM, NBAD or NIDS might help you see some differences in the scanner's performance for your environment.
  • If you are evaluating an MSP scanner offering (regardless if it is PCI certified or not), using your NIDS, SIM or NBAD solution can show how these services might be performing different types of checks. I've seen a great deal of variety in the techniques and implementations of MSPs that use Nessus for their scanning and they all do things much different and unique than I would have thought.
  • If you are evaluating a SIM or NBAD solutions, the solution should be able to look at all of the data generated by a scan and show very detailed analysis of how the scan took place and what steps it went through.

 

Cyberterror (Part II of a series)

Hello again!

In my last column, we looked at cybercrime and how its dynamics are subtly different from real-world crime. In this episode we're going to tackle a much tricker topic - namely cyberterror. Of all the cyber-badness that's out there, cyberterror is the most puzzling: if it's so gosh-darned lethal a threat, why haven't we seen any of it, yet?

This series of columns is based on a set of talks I gave as the keynote for IDC's CEMA Security Roadshow in 2008, with additional material and commentary. As always, I welcome constructive feedback at mjr@tenablesecurity.com.


CyberTerror

It's impossible to have worked in the information security arena in the last decade without running across someone who was encouraging you to be afraid of cyberterrorists. This, in spite of the fact that there hasn't - yet - been anything worthy of being considered "terror." Is cyberterror just a myth that's being trumpeted in order to generate cash-flow for security consultants, or is the threat real? As Dogbert used to say "that's not an 'or' question!" - perhaps the fear of cyberterror is a cash cow and there's a real danger.

"Terrorism" is typically defined as "the attempt to change a target's political process through fear and intimidation." It differs from crime because it's ideological and the terrorist's agenda is furthered by publicity. A cybercriminal does not want CNN to cover "the threat of bank scams" whereas the modern terrorist fails if they don't get media coverage. Other than fear, another agenda of the terrorist is to separate the people from their government, by demonstrating that the government can't keep up its side of the social contract. Since a government (in theory) is to protect its people, the terrorist's victory is all but assured when it can drive a wedge between the government and the governed. That's how the media serves to amplify the effect of a terrorist's strike - every time some talking head asks, "how could the government screw up so badly..?" the terrorists win a little bit.

So, you'd think cyberterror would be a splendid weapon: it's a venue that's utterly ripe with government screw-ups waiting to happen. Instead of death and destruction, so far we've been treated to "cyberterror" attacks that hardly qualify as more than "cyberannoyance." In 2001, when I researched the topic for my book on homeland security, the most significant cyberterror event I could find was one government agency that had been flooded with millions of Emails - not even bush league terror; closer to comedy. Today, we have the example of the cyberterror attacks against Estonian government sites. Initially, it was reported as if it was likely to be sponsored by the Russian government, but later it turned out to be a single disgruntled hacker. DDOS attacks such as the Estonian attacks are within the reach of most mid-level or advanced hackers. So, why isn't it happening more? Simply put: it's not particularly scary. And, in fact, once it happens a few dozen times it'll no longer be newsworthy. Remember: terrorists feed media attention, which means that they need to be scarier than Britney Spears' latest personal crisis and more damaging than the stunts on "Jackass."

The Cyberterror Paradox

Here's the odd thing about cyberterror: whenever a bunch of my friends and I get together at a conference, and pass the bottle while conjuring up cyberterror scenarios - we manage to scare the bejeezus out of ourselves. I find it hard to imagine that I'm more evil(tm) than all the terrorists in the world, but if a couple of half-sloshed computer programmers can plot a roadmap to ruin for a superpower, surely Bin Laden's buddies can, too. So what's going on?

One possibility is that terrorists are really nowhere near as sophisticated as the media (and the government) make them seem. Of course, when I consider how computer-security literate and sophisticated the media/government are, the fact that Al Quaeda owns laptops probably elevates them to the status of "power user terrorists." Never mind that they haven't figured out the most rudimentary kinds of encryption or communications security. Simply: these are not the kind of guys I'd vote as "most likely to hack into and destroy something important." Terrorists, to me, seem disappointingly unimaginative - they come up with a trick and then use it over and over until it's played out. Fortunately for us, that plays well with the security establishment's horrible tendency to try to protect against the last attack. It's as if the good guys and the bad guys have synchronized their decision/response(OODA)loops. The real fireworks happen when one side or the other shows a bit of innovation.

In the past I've been very critical - even to the point of outright scoffing - of the concept of cyberterror. But I have to admit that the potential is real. In the last few years I've learned things about SCADA networks that I wish I could forget. Yes, there is very real potential for horrific attacks and damage. Is there some twisted hacker out there, right this moment, about to sign up and change the face of 21st century terrorism? Perhaps all that's been sparing us, so far, is that most IT-savvy young men do not have the requisite feelings of disenfranchised hatred. Have we been saved by stock options?

As with serious, high-end, cybercrime I think we've been spared the worst scenarios because of set-up time required for deeply destructive attacks. Most of the time, when I read the scenarios offered by cyberterror pundits, they're assuming a cyber- component combined with a physical attack, either as an enabler or an amplifier. I think that what has saved us, there, is that terrorists have not demonstrated any penchant for long-term deep-cover operations. I shouldn't play armchair psychologist, but deep-cover operations don't seem to fit with a mindset that is hate-filled and action-oriented. Terrorists don't seem to be strong on long-term strategy other than survival. I don't think that terror has had its Napoleon Bonaparte, yet, and we should all be thankful for it. Do you think that energy companies, chemical companies, amtrak, trucking companies, and shipping companies do deep background checks on their employees? What about on the companies that provide basic services such as security, janitorial, and telephone to critical infrastructure? If you think about it for a bit, and imagine that you were able to plot on a 5-year timescale instead of 6 months, you ought to be able to really scare yourself. Is it simply a focus on short-term damage and rewards, or are they stupid and utterly clueless about tradecraft?

Ease of Abuse

I think the most likely reason terrorists have ignored cyberspace is because the skills necessary to launch real-world attacks are lower and willing soldiers are easier to recruit. Until such time as there is a massively successful (i.e.: horribly destructive) cyberterror event, terrorists will likely want to stick with the tactics to which they have already acculturated the media. Once again, it's easier for CNN to understand a suicide bomber - for now - than a mysterious refinery explosion that may have been caused by computers. The tipping point, unfortunately, would happen once the media started to conclude that anything that went wrong was likely to have been caused by cyberterrorists. If that were to happen, we could expect the United States to head-butt itself into insensibility with an overreaction such as we saw post-9/11. You can easily imagine a deliberate strategy of getting one's opponent to waste money through overreaction. Look at how much the United States has spent on the Transportation Security Administration, throwing away liquids and gels, and removing our shoes. Here's where the terrorist can always win: the worst part of asymmetric warfare is that the expense is asymmetric, too.

If the target does not respond to an attack, they are vulnerable to more of the same. If they do respond, the attacker can simply focus someplace else and repeat the process all over again. It's because of this dynamic that I've changed my views about cyberterror: it seems like a great way for an attacker to get the United States to spend ridiculous amounts of money. The more we spend to protect our physical systems, the more attractive a target we make our virtual systems. And vice-versa. The worst part about the mere threat of cyberterror is that it can drive costs up for higher-tech nations, at nearly no cost to lower-tech nations or independent actors.

Necessary For The Future

All of this brings me to the future. It's fairly safe to predict that sooner or later, there will be a significant cyberterror event. Before that happens, the United States needs to clearly establish a public doctrine regarding how we will respond to such events. This is especially important if you consider the question of whether the event is state-sponsored or the perpetrators are being sheltered by a state. Lately there has been a great deal of rumbling - rumbling I consider irresponsible, since evidence has not been presented - about alleged Chinese-sponsored cyber-espionage against United States and European powers. We need to encourage the international community to start thinking about this topic: at what point is a cyber-(whatever) attack an act of war, or a serious provocation? What kind of proofs and evidence are adequate to link a state sponsor to an event?

I know that these questions seem a bit over-the-top, but I'd hate to see wars and killing as a result of poorly-thought-out reactions to someone's exploiting a misconfigured firewall! It's a plausible scenario, unfortunately, and it's made more plausible by security practitioners' horrible tendency to worry inordinately about problems that take us by surprise. At this point, our computing infrastructure may be so poorly secured that it's not cost-effective for us to try to lock it down. We're going into a future for which we are clearly unprepared.

Next, let's look at espionage. If you think cyberterror is a depressing problem, just wait!
See you soon,
mjr.

 

Tenable Releases Security Center 3.4

Earlier this week, we released Security Center 3.4 to our customers. Version 3.4 adds a lot of new features in the user interface and reporting. It also strongly ties in log analysis and network monitoring with vulnerability scanning and configuration auditing. Anyone can see video demos of the product being used to analyze logs, audit configurations, perform scans and look for intruders under the "Unified Security Monitoring" section of our Demo Videos.

Some of the major new features include:

  • An enhanced and modern user interface
    It makes use of more screen area, can save any query for later usage and has intuitive links to quickly view raw syslog, vulnerability or configuration information.
  • Support for manual Nessus report uploads and downloads
    You can perform scans with the Nessus Client and upload them to the Security Center. Any tool or product that works with the Nessus report format can also receive these types of reports from the Security Center.   
  • A more robust, intuitive and feature-rich scan scheduling interface
    This includes the ability to override a variety of scan settings at scan time, such as changing the required credentials to perform a patch or configuration audit of a server.
  • More than 170 report templates for PCI, FISMA and other standards
    These templates consider vulnerabilties, patch audits, configuration audits, change auditing, compromise events, correlated events and many other types of data sources.

There are hundreds of other features not listed here which focus on ease of use and new technical functionality. For example many new scanning options support new ones available in Nessus 3.2. A full list of new features is available to customers on our support portal.

Below is an array of screen shots which show various aspects of Security Center 3.4 in action.

Pluginfamilysummary

Vulnerability Summary By Nessus Family
Detected vulnerabilities can be summarized and sorted by each Nessus family. A running total of individual severity levels is also shown and can be clicked on, bringing the user to a list of all vulnerabilties from that severity level in that family.

Portsummary

Vulnerabiltiy Summary by Port
This sort lists all ports for which some sort of vulnerability or information has been discovered either through a Nessus scan or from a Passive Vulnerability Scanner report.

Rawvulndetails

Raw Vulnerability Detail
In this view, we are showing two hosts that had high level severity issues for their SSH daemons. From this link, users can open tickets, look at logs from these hosts and recast the severity level if needed. Any of the raw text in these screens is available for searches as well as dynamic asset classification.

Scapauditasset

"Pop Up" IP Screen
Throughout the Security Center user interface, when working with an IP address on a vulnerability, intrusion detection or log event screen, clicking on it will "pop up" a  box containing asset classification, descriptions about the IP address and hot links to other queries.

Lcetypeview

Normalized Event Visualization
In the screen, a user is presented with an activity graph for all normalized log events. You can see that some events occur continuously by the horizontal graphs. The vertical list of events was the result of a large network scan which caused events from different sources across the entire network.

Idstimedistsummary

Directional Activity Graphing
When working with IDS or log events, the amount of activity inbound, outbound and internal to the entire network or specific asset groups can be displayed. For example, you might be interested in IDS events "leaving" your entire network and then choose to look at IDS events "leaving" your DMZ or server farm.   

Correlatedlceevents

Correlated Event Visualization
In this graph, we are showing correlated events. These include IDS events that have been automatically correlated with known vulnerabilities, as well as events generated by the Log Correlation Engine which have discovered a wide variety of suspicious activity.

Viruslog

Raw Event Display
For each gathered and normalized event, the data from Syslog, Windows Events, netflow and so on, is available for display. In this screen shot, several Snort Emerging Threats rules are displayed.

The Security Center is priced solely based on the number of active IP addresses being managed. A 500 IP Security Center license lists for $15,750. All Nessus scanners connected to the Security Center also receive Direct Feed plugin updates. For pricing and quotes on larger networks, please contact our sales team.