FUDwatch: Armenia

by Marcus J. Ranum on May 3, 2013

For a field that loves statistics, computer security sure treats them casually. In order to get my humble BA in Psychology, I absorbed my share of course hours in statistics and testing methods, including a set of lectures based upon Darrell Huff's brilliant book, " How to Lie with Statistics " - which I highly recommend. It's fun easy reading satire - those lectures had the effect of making me hyper-skeptical about any large, round, number that's thrown my way. Sometimes, I get the urge to play and this is one of those times. Please don't take anything from this point forward very seriously...

The Big Red Button and the Kill Switch

by Marcus J. Ranum on April 25, 2013

I have no idea if I had a role in the "Internet Kill Switch" debacle, but it's possible that I was one of the pushes that got that particularly horrible ball rolling. Back in 2002, when I was between jobs, I did a talk at CSI in Chicago, about the need for organizations to be better able to react to attack, especially if they were part of critical infrastructure. At the time, I was concerned particularly with denial of service attacks; I had been thinking about them and had concluded that it's never going to be possible to completely prevent such attacks. "Well, that has big implications for...

Comments and Commenting Policy

by Marcus J. Ranum on March 7, 2013

I believe that one of the things that gives a blog life and interest is its commentariat. This is not a free-for-all zone, however, so comments are moderated (for appropriateness, spam blocking, etc). The comment area is intended so you can talk amongst yourselves, though I'll try to review it and may respond occasionally. If you have a question that may be appropriate to answer in a blog posting, I reserve the right to lift your comment out of the comment section and address it at more length. Or, if you want to email me comments, questions or topics you think I might want to address, feel...

We have Microsoft Tuesday, so how long until we have Indicator Wednesday?

by Ron Gula on February 26, 2013

Recently, Tenable's Research team created Nessus checks and log searches to look for indicators specified in the Mandiant APT1 report. Our response was not unlike a typical Microsoft Tuesday afternoon where our team writes active, credentialed, and passive checks for missing patches. There are a lot of other indicator sources and, following the press surrounding the APT1 report, there will undoubtedly be more disclosures. When this steady stream of indicator disclosures starts, there will likely be an outcry from IT security professionals everywhere to align these releases to a certain day of the week for the same reasons we have Microsoft Tuesday.

Default Credentials: Low-hanging Fruit in the Enterprise

by Paul Asadoorian on September 17, 2012

Passwords are Like Underwear, and It's Laundry Day Perhaps one of the most easily overlooked security problems in the industry is password security. I'm not referring to the stored end-user password problems ( discussed here ), but the default (or weak) usernames and password combinations used to protect common administrative interfaces to applications and systems. The problem stares us in the face every day, each time we log into a router, database management system, or remote access console and enter a password. Often we put a lot of time and effort into securing the end user-facing passwords, such as implementing account lockout password policies and forcing them to change their passwords at a regular interval. I find it ironic that the applications and devices used to run the organization often do not implement the same controls. Hundreds of applications and/or devices are known to be deployed with default passwords, and if not changed before or immediately after they are plugged into the network, can present serious risk to the organization. Default credentials are considered "low-hanging fruit" for two reasons. First, they are easily exploitable by an attacker and can often lead to a serious security breach. Second, once you've identified the problem, it is easy to fix by setting a more secure password.

Black Hat 2012

by Paul Asadoorian on August 1, 2012

Conferences Fuel Your Passion Few things spark your passion for information security the same way as a conference. It’s inspiring to talk to so many different people in the industry and listen to a variety of talks, all in one place. I had the chance to personally meet many readers of the Tenable blog and listeners of the Tenable podcast. I also heard some great talks as well. Here are some highlights. Smashing the Future for Fun and Profit I was really excited to see the folks on this panel come together and "talk shop." It’s a rare opportunity to see Jeff Moss (Dark Tangent), Adam Shostack, Marcus Ranum, Bruce Schneier, and Jennifer Granick all share the same stage! This did not happen by chance, as this panel brought back five of the original speakers Jeff Moss assembled at the first two Black Hat conferences held in 1997 and 1998. I've had the unique opportunity to interview each of the 2012 panel members individually, so I was particularly interested to see how their thoughts, ideas, and opinions would converge. I was not disappointed. The topics ranged from software security, the government’s role in security, consumerism and how ease of use impacts security, the vulnerability market, and so much more. Jennifer Granick was an outstanding moderator (which was not an easy task by any stretch!). The big question for me was, “What changed?” Jeff had a great anecdote. He said we don't really solve the problems, but we just run away from them and they seem to go away. We've just been able to run faster. I reviewed the topics presented at the first Black Hat conference in 1997 , and I couldn't agree more. Vulnerabilities in TCP/IP, secure coding, and over-reliance on firewalls all made the list — topics we still discuss, and problems we still run from today.

If a Security Control Falls in the Forest...

by Paul Asadoorian on July 16, 2012

Many guidelines and compliance standards state that in order to be "secure" or "compliant" all of your systems must be patched. Turns out that this is easier said than done. Just when you believe your systems to be patched, something fails and patches seemingly disappear. We can then apply the "falling off" principal to several other areas of information technology, such as web applications, configuration management, and antivirus software. How do security controls in these areas fall off? Read about how this might happen and what you can do to help correct the problems.

Are You at Risk for Burnout? The Top Causes…and a Sneak Peek at Findings from a New Tenable Study

by Jack Daniel on July 9, 2012

Around the time of RSA in February, I wrote about the risk of burnout for security professionals, and offered some warning signs — including feelings of stress, exhaustion, or a lack of self-efficacy — that might indicate you’re on the burnout scale. At this year’s Gartner Security and Risk Management Summit, the Tenable team decided to dig a little deeper and conducted a survey that explores a number of security issues, including some of the causes of burnout. Keep a look out for the official numbers in the coming weeks. In the meanwhile, here are three questions you should ask yourself — based on the early survey findings — to prevent security burnout before you’re on the scale. Are you working too many hours? The study found that working 50 hours a week isn’t just ordinary — it’s the minimum for most security pros. In fact, the vast majority of respondents said they work between 70 and 80 hours every week. There are two schools of thought to consider here. First, security pros see the economic turmoil that surrounds them and are willing to do more to keep their jobs. Or second, security pros have more work (and responsibility) than they can realistically handle. The second option feels more realistic to me, which leads me to my next question…

Do Passwords Matter?

by Paul Asadoorian on June 20, 2012

Password Breaches Are Nothing New You don't have to look very hard to find an article discussing password breaches. Recently, there was a lot of buzz around LinkedIn, LastFM, and eHarmony, three very large sites suffering from passwords being leaked to the public. This is not a new phenomenon (earlier this year everyone was all up in arms about the Zappos password breach ), but one that continues to garner attention in the media. However, what most journalists are saying about password breaches is likely different from what I am about to tell you -- it simply does not matter how strong your password is, how it is encrypted when stored by the provider, or how the transport layer is encrypted (e.g., SSL). Here's why: How It's Encrypted Matters, but No One Does It Right Many websites today, primarily for performance reasons, are using traditional one-way hashing algorithms to store your passwords (such as MD5 or SHA1). This means you give the website a password, it computes a cryptographic hash and stores it in a database of some kind. The plaintext password should never be written to disk. The next time you login, the website computes the hash in the same manner and compares it to the value stored in the database. This is all well and good, until someone obtains a copy of the password hashes. Obtaining the hashes, without any other protections, such as password salting, two or more users with the same password will have the same hash value. This allows attackers to generate very large databases of already-hashed passwords and make a comparison. Hardware on graphics processing units (GPU) can help accelerate the process. There are also websites that will provide hash-cracking services (submit the hash to a website and get the cleartext password in return). Several of these sites also use “Rainbow Tables,” a form of lookup tables which takes a bit longer, but allows for smaller tables. A ‘salt’ will help slow down this process, a little. Salts are a random string appended to the password such that user's passwords are different. However, sometimes developers implement salts incorrectly, and use the same salt for each user or store the salt where attackers can obtain it (or calculate it). Even if salts are implemented correctly, the processing power of GPUs can be used to crack the salted password hashes in more time, using even larger pre-computed password dictionaries than ones without a salt. What does all this mean? Likely, at least a few websites (internal to your organization or external) are storing your password using a hash that can be reversed in a relatively short timeframe, depending on the hash used and computing power of the attacker.

Vulnerabilities, Exploits, and Good Dental Hygiene

by Paul Asadoorian on April 12, 2012

Vulnerability Management Constantly assessing the security of your own systems is an important task in maintaining a secure network. I relate regular security assessments to personal hygiene, such as brushing your teeth everyday (and even more "in-depth" maintenance such as flossing and using mouthwash). All of these actions are an effort to prevent "bad things" from happening. Often, the "bad thing" hasn't happened yet, and you are trying to get ahead of the curve to protect yourself from cavities, gum disease, or worst-case, all of your teeth falling out. Vulnerability management plays the same role in your organization. By regularly assessing your systems, finding problems, and fixing them, you hope to get ahead of the curve and prevent bad things from happening, such as data leakage, breaches, and compromises of your systems by “evil bad guys”. All of us can hear our parents voices in our heads, as when we were growing up we were all told to "brush your teeth before you go to bed". As I stated above, finding the vulnerabilities is just the first step. You must have a process in place to fix the vulnerabilities that you've identified. After that, your processes need to check to be certain that a vulnerability was remediated. Your plan for network health has to track vulnerability remediation, and empower those responsible to be in the loop and fix the problems before something "bad" happens (if it were only so easy as brushing, flossing, and using mouthwash). Tenable has a suite of tools to help you both find as many vulnerabilities as possible and implement a process for continued remediation. Below are some examples: