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:
|
|
|
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.
|
|
Results |
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.
|
Vulnerability Summary By Nessus Family |
|
Vulnerabiltiy Summary by Port |
|
Raw Vulnerability Detail |
|
"Pop Up" IP Screen |
|
Normalized Event Visualization |
|
Directional Activity Graphing |
|
Correlated Event Visualization |
|
Raw Event Display |
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.
Additional Support to Look for Compromised Web Servers
With the recent news of more than 500,000 web sites becoming compromised, Tenable's research team added support into Nessus and the Passive Vulnerabiltiy Scanner to look for evidence of recently installed Javascript that may be indicative of a mass compromise.
With Nessus, the webmirror.nasl and webserver_infected.nasl plugins enumerate the web pages of a scanned web server and look for evidence of a compromise. With the PVS, plugin #4487 watches for unencrypted web traffic which contains evidence of these compromises.
Previously, Tenable has blogged about this type of active and passive detection for a different mass compromise event. Also, last week we blogged about auditing Internet facing web servers. The techniques outlined there should be utilized when auditing web servers that may have been infected with malicious content.
News References
How to audit an Internet Facing Server with Nessus
Very often, Nessus is used by MSPs, consultants and IT security staff to test the security of an Internet facing server. Occasionally, we see the default settings of Nessus, which are optimized for a credentialed internal LAN audit, used to audit an external server. Although this usually results in a majority of the vulnerabilties being identified, Nessus can be configured to work a bit harder for these types of scans. This blog entry details some different strategies and scan settings that can be used to perform a more complete audit of an Internet facing server.
Nessus Scanner Settings
When scanning a few external hosts, we do not envision the scanning process to impact your system's performance. However, if you do encounter issues, consider the following. The scan settings we will be enabling will cause Nessus to work much harder than it does during a typical LAN or default scan. If the system running Nessus is not a dedicated system (such as a consultant's laptop), you should consider configuring it to have less impact on the underlying operating system. Otherwise, the system may become unresponsive during the audit. On UNIX, the "be_nice" setting should be set to "yes" in the nessusd.conf file and then the nessusd process restarted. On Windows, the nessusd.exe process can have its priority lowered. For this blog entry, I had several heavier scans running at the same time from my local Nessus scanner and had no noticeable impact to my operating system.
If the audit is taking place over a slow Internet connection or a connection which is being served by a device that may be impacted by many simultaneous connections, considering reducing the "max_hosts" setting from the default of 40 to 10. This will generate less overall traffic during any given moment of an audit and also reduce the number of simultaneous checks (and connections). On the Nessus Client, this setting is available under the "Options" tab and is named "Number of Checks in Parallel".
Scan Policy Settings
Global Variable Settings
Many plugins implement more thorough audits when the "Thorough Tests (slow)" setting is enabled. These tests often implement the same logic, but try more combinations of potential security issues. This causes security audits to run longer than they normally do. For example, when looking for FTP, SMB or HTTP servers hosting potentially copy written content, this setting increases the level of recursion used to look for files. There is a slight chance of impacting a server's performance during this audit, as the server will also have to respond to more probes than during a normal scan.
Also in this section, the "Network Type" should be set to "Public WAN (Internet)". This effects some plugins which are required to choose relevant IP addresses.
Below is a screen shot of the Nessus Client implementing these settings:
|
Service Detection
By default, SSL detection is normally performed on services that are expected to support encryption such as port 443. However, for any discovered port facing the Internet, SSL service detection should be enabled. This is accomplished by changing the "Service Detection" set of options under the "Advanced" tab from the default setting of "Known SSL Ports" to "All".
If the audit is being performed remotely, this section also has a separate setting for the number of service fingerprints to be performed in parallel. This setting effects the few plugins which perform service fingerprinting and can generate many sessions at the same time. The default value for this is 10 and for the policy used in our example policy, I reduced this by half to 5.
Below is a screen shot of the Nessus Client implementing these settings:
|
Auditing CGIs
Nessus includes a plugin that can "torture" any discovered CGI or other type of interactive web document. This can uncover a wide variety of security, stability and other issues with poorly written login pages, feedback forms and other types of dynamic pages that process user content.
To enable this, under the "Advanced" tab, select the "Unknown CGIs arguments torture" and enable the "Send POSTs requests" check box.
During the audit, if a complex web site is being tested, you should discuss this type of test with the site owners ahead of time. Nessus will try a wide variety of common form exploits which can result in unexpected behavior or unanticipated system loads. Even if a web site is secure, these tests may show issues with logging failure messages (or lack thereof) and could also highlight issues with custom logging in general.
I've spoken with one customer that tried this sort of auditing and they did not have any security issues, but the error logging process involved writing to a SQL database. This surge in errors resulted in an unacceptable denial of service for the web site.
Port Scanning
Since this is an Internet facing system, no port should be left untested. A full port scan from 1 through 65535 is suggested. If you are omitting port scans for some reason, it should be noted in the final audit.
Web Mirroring
The default Nessus settings to look for web pages that may have vulnerabilities can be made more aggressive. These settings take longer to execute than a default scan, but are more likely to find a vulnerable server. The "Web Mirroring" set of scan options is available under the "Advanced" tab of the Nessus Client. The following settings are recommended:
- The default number of web pages to mirror is 200. This should be raised to something that matches the destination site being audited.
- If Nessus learns of a dynamic web page, it normally won't add this to the mirror list, unless the "Follow Dynamic Pages" option is set. Web sites that link to login screens, include feedback forms and have other types of dynamic content are often dynamically generated.
If an audited CGI or other type of dynamically generated web page is poorly written, the Nessus audit may cause a spike in the performance level of the audited server. For example, a web site may have a slow method to read content from a SQL database before rendering a login page or some type of default screen. A rapid set of web queries performed by Nessus could impact the system.
Below is a screen shot implementing these settings with the Nessus Client:
 |
Performing the Scan
Nessus 3.2 does include the ability to pause a scan. If your audit causes some unanticipated effect on the target servers, you should stop it or pause it immediately.
Tenable receives many reports from customers scanning their remote systems and having ports that were available during the start of a scan, not be available at the end of a scan. This shows up in a Nessus report like this:
System: 192.168.20.200 unknown (0/tcp)
Vulnerability: [10919] Check open ports
Severity: Informational
The following ports were open at the beginning of the scan but are now closed:
Port 80 was detected as being open but is now closed
This might be an availability problem related which might be due to the following reasons :
- The remote host is now down, either because a user turned it off during the scan
- A network outage has been experienced during the scan, and the remote
network cannot be reached from the Vulnerability Scanner any more
- This Vulnerability Scanner has been blacklisted by the system administrator
or by automatic intrusion detection/prevention systems which have detected the
vulnerability assessment.
In any case, the audit of the remote host might be incomplete and may need to
be done again
If an Intrusion Prevention System (IPS) or Unified Threat Manager (UTM) devices is configured between you and the target host, it may detect some of your activity after the scan has started and then block further testing. This can cause an incomplete audit. In these situations, it's important not to speculate. Finding out how the IPS is detecting the scan is important because it is also part of the system being audited. For example, if it is only configured to block hosts that perform a port scan, it may not stop a host or worm trying one SQL injection attack. The point is to provide an accurate assessment so the customer or management does not put their faith in something that might not be reflective of other threats.
For More Information
We have blogged several times in the past about configuring Nessus for optimum scanning:
Risky Business -- Episode #59
Tenable Network Security recently began sponsoring the Risky Business podcast with Patrick Gray. Episode 59 is now online. This latest installment includes:
- A review and commentary of the week’s security news.
- Jeremiah Grossman of Whitehat Security talks about some of the very latest web vulnerabilities including Cross Site Request Forgery attacks.
- Patrick Gray interviews me about Tenable, our work in the logging and correlation space and the Nessus vulnerability scanner.
If interested in the podcast, it is at the following link:
Marcus Ranum in Europe
For those readers that are located in Europe, Marcus Ranum, Tenable’s CSO, will be speaking at two events in Q2 of 2008:
On April 23rd and 24th, Marcus Ranum will be speaking at the Mnemonic Risk Management and Information Security Conference 2008 in Norway. The conference will be held at the Ulleval Business Class. He kicks off the conference with his talk titled: “Lateral Thinking in Security”.
Computer security, as a field, appears to be trapped in a hamster-wheel of repeating the same ideas over and over again. And the results are clear: 15 years into the field, more systems are getting compromised than ever, in spite of billions of dollars and thousands of man-years invested. Why is this happening? It's possible that we're going about doing things backwards and trying harder isn't going to result in any improvement. In this presentation, he'll look at a few things that don't work as well as they should, and he'll try to come up with "plan B" options.
On June 4, 5 and 6, Marcus Ranum will be keynoting the SÉCURITÉ DES TECHNOLOGIES DE L'INFORMATION ET DE LA COMMUNICATION in Rennes, France. Marcus will begin the conference with his keynote titled: “Anatomy of The Security Disaster”
Computer security has historically been a disaster and continues to be a disaster. Many practitioners have attempted to explain it in terms of risk management, failure to communicate, or lack of education. In reality, it is a simpler social problem, and is not solvable by any means short of a redesign of human behavior. The view he will present has implications for the real meaning behind why economic models represent "market failures" and risk management approaches are merely "hand-waving."
For more information on other Tenable upcoming speaking events, please visit:
Tenable Receives FDCC Certification
Recently, Tenable's Security Center product was awarded certification to perform Federal Desktop Core Configuration (FDCC) audits, along with several other types of NIST SCAP audit capabilities, for the Windows XP and Vista platforms. FDCC makes use of the NIST SCAP XCCDF standard to describe security profiles, configuration settings and specific techniques to test for configuration settings. This blog entry describes how this process works and some of the benefits of the NIST SCAP program.
Performing FDCC Audits with the Security Center
Security Center users can download XCCDF content, such as the FDCC policies, and load them into a tool named the "xTool". This tool processes the OVAL, CPE and XCCDF content and logic to produce an audit file that can be used by the Security Center to control one or more Nessus scanners. Tenable's FDCC auditing technology requires credentials for the target systems and does not use an agent.
One of the features of the xTool is to dynamically create audit policies with as little or verbose content available from the XCCDF content. For example, in the screen shots below, the xTool has been configured to display the Nessus audit logic used to test the minimum password age policy.
|
|
In the image on the left, none of the meta data was included. In the image on the right, all information related to the Common Configuration Enumeration (CCE) ID, the specific XCCDF audit policy and a handful of related DOD, NIST, ISO and other standards is included. The xTool gives security and compliance managers the ability to customize how much information in the audit is included for analysis by the end user.
The audit policies generated by the xTool are loaded into the Security Center and can then be used to perform configuration audits. These can occur alongside vulnerability scans, patch audits or sensitive data auditing. In the below screen shots, a summary of CCE issues and an example view of detailed results for one CCE is shown:
|
|
Once scans are completed, the Security Center can be used to sort the results and identify which types of compliant and non-compliant FDCC issues have been found. These can be sorted by IP addresses, asset group, by type of CCE entry and many other filtering and reporting options.
When submitting results to NIST for FDCC compliance, the results of all systems are not required -- just the results of systems that are representative. For example, based on operational requirements, an organization may need a waiver for the length of their minimum passwords.
With more than 700 configuration checks performed by FDCC, the Security Center can be used to sort and identify unique combinations of non-compliant configurations for hundreds, thousands or even tens of thousands of unique hosts. This makes the process of finding your unique non-compliant samples much easier.
Lastly, the xTool can also import the results of the configuration audit and produce an FDCC report which includes non-compliant tracking of exceptions.
FDCC and SCAP Benefits
Independent Vendor-Neutral Content
As new XCCDF content is developed and hosted by NIST, Security Center users can download it and produce audit polices for new platforms. Tenable currently has customers who have produced audit polices for the beta XCCDF content available for Windows Server 2003, other Windows platforms, Symantec Anti-Virus and the Microsoft Office 2007 suite. As new XCCDF compliant content is developed, the xTool can consume it and produce audit policies.
Logging and Anomaly Detection
Knowing how a system or set of systems are configured is just as important as knowing their vulnerabilities. For example, consider an incident response process that was invoked due to a network wide brute force password attempt. Knowing the password policy (complexity, minimum length, expiration, .etc) of a system can help you prioritize which systems to respond to first.
Similarly, if a user population of systems is configured for a policy that has locked down likely exploit vectors, enabled access-control logging, enabled logging of access to object such as folders and shares and enabled a firewall, the ability to gather logs and look for anomalies is greatly enhanced. Performing anomaly and compromise detection is much easier when the composition of the network you are monitoring is known.
Quicker Identification of Unmanaged Systems
When complimented with traditional active and passive vulnerability scanning, the Security Center can be used to quickly identify when a system is configured in a non-sanctioned or unauthorized manner.
Perhaps a new system has been installed prior to being locked down. Perhaps some sort of software upgrade resulted in a down-grade of secure system settings. Perhaps a hacker, insider or malware has indeed infected a system and turned off these settings as well. Whatever the reason, in an environment where most hosts are configured the same, finding a host that is different is much easier.
Commercial Auditing
Although the SCAP program has a federal government mandate, the content is also being used in a variety of commercial applications. For example, Tenable has many financial and health care organizations that are private or commercial entities, yet choose to configure their networks according to NSA best practices, the DISA STIGS and now the SCAP content feeds.
The NIST SCAP program also offers some platforms and recommendations for configuration settings not provided by the Center for Internet Security best practice guides, or directly from vendors such as Microsoft.
For More Information
Tenable has an online video demo of how the xTool and Security Center can be used to perform FDCC and SCAP audits. We've also previously posted about how to configure Windows XP and Vista systems for auditing as well as comments from a NIST FDCC implementor's workshop. To learn more about SCAP and the XCCDF specification, please visit http://nvd.nist.gov.
Safari Windows Detection ... and all That Implies
Apple recently gave Windows iTunes users the option to download the Safari web browser. This move was criticized by many bloggers and security experts. What we will be discussing in this blog today is detection of the Windows Safari application and also examine how organizations could react to this situation.
Detection
Nessus plugin #31788 named "Safari Detection (Windows)" looks for Safari installed on a Windows platform. This plugin requires credentials to analyze the Windows system to see if the browser has been installed. If credentials are not available, this plugin won't report an issue.
The Passive Vulnerabiltiy Scanner can also be used to generically report the active web browser being used on any host it sees web traffic originating from. In the Security Center screen shots below, all user agents detected by the PVS have been listed:
|
|
In the screen shot on the left, only Safari browsers on Mac OS X computers are shown. On the right screen shot, a host that has a single Windows Safari client is shown among several different other browser types. The PVS also has a unique plugin (#3705) which detects the Safari browser.
Analysis
I've had a few conversations with our customers about this issue and there are a few themes:
- In organizations that banned the use of iTunes, this event gives them much more evidence to support this decision. The organization should be in charge of what software gets run on a network, not the application vendor. This also gives them reason to ban other applications that might include a software delivery method.
- In organizations where iTunes use is allowed, but there is still a requirement for a standard browser such as Internet Explorer, some leniency was given to users who have been educated to accept security updates from their vendors. It could be argued that the Safari push looked like a security update.
- Some organizations are modifying their acceptable use policies to more explicitly state that unauthorized software should not be installed, even if it is from the vendor of an approved application. I've heard several comments from customers basically expecting other major software and operating system vendors to use this sort of technique.
For More Information
We've bloged in the past about enumerating various applications and finding software that should not be there on a corporate network:
Tenable Network Security
- The official BLOG of Tenable Network Security and the Nessus vulnerability scanner.
Recent Posts
- Tenable updates plugin subscription model for Nessus Vulnerability Scanner
- Visualizing Nessus Working Harder For You
- Cyberterror (Part II of a series)
- Tenable Releases Security Center 3.4
- Additional Support to Look for Compromised Web Servers
- How to audit an Internet Facing Server with Nessus
- Risky Business -- Episode #59
- Marcus Ranum in Europe
- Tenable Receives FDCC Certification
Search
Categories
- Compliance Monitoring
- Control Systems
- Data Visualization
- Event Monitoring
- Events
- Log Analysis
- Nessus
- Passive Network Monitoring
- Patch Auditing
- PCI Compliance
- Ranum's Rants
- SCADA
- Security Center
- Security Interviews
- Security Metrics
- Security Strategy
- Tenable
- Tenable Events
- Tenable in the news
- Tenable Partnerships
- Tenable Product Usage
- Tenable Research
