Welcome to the Tenable Network Security Podcast - Episode 21
Announcements
- A new blog post has been released titled "New Nessus Videos - Scanning With Credentials" that covers how you can provide credentials to Nessus for both network-based and web application scanning. Kelly Todd also published an article titled, "Understanding The New Massachusetts Data Protection Law".
- A webinar is scheduled for February 25, 2010 titled, "Finding and Stopping Advanced Persistent Threats webinar" where Tenable CEO Ron Gula and Tenable CSO Marcus Ranum will discuss strategies for preventing, finding and eliminating advanced persistent threats in enterprise networks.
- You can provide feedback to this podcast and all of our social media outlets by visiting our discussions forum and adding messages to the "Tenable Social Media" thread. I would love to hear your feedback, questions, comments, and suggestions! I put up a call for ideas on new Nessus videos, so please give us your feedback!
- We're hiring! - Visit the web site for more information about open positions, there are currently 12 open positions listed!
- You can subscribe to the Tenable Network Security Podcast on iTunes!
- Tenable Tweets - You find us on Twitter at http://twitter.com/tenablesecurity where we make various announcements, Nessus plugin statistics, and more!
Interview: Ron Gula - Security Center Version 4
Tenable CEO Ron Gula and I discuss the features of Security Center and some of the recent enhancements being made in the new version 4.0.
Stories
- Holy RFI Batman! - Rsnake has published a list of web applications that are allowing an RFI attack to occur. This attack vector allows the bad guys to potentially run code on the remote server and clients visiting the site. These attacks can also lead to Local File Inclusion, allowing attackers to read files on the remote host. I've also found a list of remote file inclusion vulnerabilities that were harvested from the OSVDB. This is a pretty common attack vector commonly used by attackers to drop in some malicious JavaScript code into web sites.
- Google Willing to Pay For Bugs In Chrome - Google has announced that they will pay up to $1,337 for bugs that are found in the Chrome browser and $500 for lesser severity bugs. You can look at this two ways. First, my inclination is to state that Google is a large enough company that they should be implementing secure coding practices and have a team dedicated to the security of Chrome. It is likely they have this, however on the flip side, giving incentive to millions of people to find bugs is something Google could not do on their own. So, they offer a reward for bugs to harness the power of the Internet community to make their software better. The problem is two fold, if you are a "whitehat" hacker you can make more money selling it to other organizations or stand up to a moral code and provide Google the details without asking for anything in return. Regardless of where you stand on that issue, Google's bounty for vulnerabilities is not in tune with reality. The other factor is that if a "blackhat" hacker were to find a bug, they may decide to keep it for themselves and use it to compromise systems and make money through a botnet or pop-up ads. They may also decide to sell it on the black market to other "blackhats".
- Network Security Fundamentals - Default Deny - Ah yes, the wonders of firewall administration and "default deny". I remember it vividly during my time (an extended period of time, mind you) as a firewall administrator. Many subnets within the organization were implementing the reverse of "default deny", "default accept" and blocking only the exceptions. This was a bad place to be because going to a "default deny" in this situation would almost certainly break things, and lead to cranky users. It was a long process of analyzing traffic to see what needed to be allowed and adding rules. Was it worth it? Maybe, over time my opinion of firewalls is changing. I'm still in favor of using firewalls, but in many situation I believe more effort should be places on system hardening. This includes using the principal of least privilege, applying software updates, turning off unnecessary services, and tuning the configuration to be "secure" (as in enabling the security features). Lets face it, the firewall only blocks a certain class of attacks, which is important, but lets not forget about security completely because we have a firewall. I like to extend the "default deny" to other aspects of security, such as system hardening (why do we have so-called "default" passwords!), and host intrusion prevention client software (why do we allow DLL injections and embedded iFrames?).
