• Why should you prioritize the risks in your IT network?

• Why can’t you just fix ALL the problems?

Unless you work in a company that has unlimited resources and you have absolute support at all levels for remediating the vulnerabilities in your environment, you MUST prioritize the issues that cause the most risk to your IT environment.

Analogy.. “The To-Do List”

Say your wife gives you a list of 150 things to get done on a Saturday afternoon.. How many can you realistically get done? Maybe 5? Maybe 10 if the tasks are small.

If you have a large network, you likely have many possible vulnerabilities. Say you have a relatively small list of 300 security issues found from vulnerability scans and other security assessments and tests.. Can you realistically expect all the teams that would own fixing those issues to drop everything they are doing and fix the “list” of issues you give them?

How much security remediation work can you really expect to accomplish? The answer for these types of questions is more dependent on how your organization functions than on any calculations or math.  Every IT shop is trying to fight for resources to..

1) Implement customer projects.

2) Upgrade and/or modernize their own infrastructure.

3) Implement their own strategic initiatives.

4) Have a work/life balance.

Where does that leave working on tasks to fix issues that have been found through security testing?

The naive answer is to say that security should always be a top priority and the teams should figure out a way to get the work done. For those that work in the real world it simply is not that easy.

Resources such as budget, hardware, and time is limited. Some IT shops are fighting to survive. If they have to stop business driven projects for 3 months to fix security issues their business customers may choose to use other options.

What is the answer?

The answer is to use Risk Analysis and Risk Management techniques to determine what the highest risk vulnerabilities are to your IT environment. This is called using a “Risk Based Approach.”  Simply put, it means to fix the most risky things first. You would think this is common sense, but you would be wrong. There is often a reflexive response to any type of possible security issue. The reflex response is “just fix it”. If there are 5 issues, then just fix them. If there are 200 issues, then just fix them.

The problem is that most decent sized companies will have many possible issues. You simply can not have a completely secure environment without making the environment unusable.  I go back to the example of having a list of 150 tasks to complete in one day. It simply isn’t possible. However, could you get 5 done? Probably so. Could you get a small amount done on 20 tasks? Probably so.

So which one is better? Getting 5 security issues completely resolved or 20 issues partially completed in a year? That needs to be a management decision based on good risk analysis of the issues.

Fixing security issues is an effort like any other.

The whole point of this post is to get you to understand that resolving security issues is no different from any other project or effort. No company or organization can implement every good idea. They must prioritize in order to get the best results from their efforts.

Resolving security issues is a work effort just like any other in an IT organization. The effort must be prioritized against all other efforts so that they can get the proper focus and funding. If you don’t have focus on a few things, then you get very little accomplished, and your efforts are spread thin.

Final Analogy… Pruning…

Every organization is like a rose bush or a grape vine. In order for nutrients to allow the main stems and fruit to truly mature and reach its full potential, you must prune the small branches and vines that use up the resources of the plant that don’t add any fruit or flowers. The small branches use energy and resources, and eventually will cause the plant to be poor producer of fruit or flowers. Why? Because no focus was devoted to the things that mattered.

Final Point : To get things done, you must prioritize and be able to focus your energy and effort on what matters most.

OpenDNS is a Domain Name System (DNS) service that you can use as an alternative to the DNS system that your internet service provider offers.

For those not familiar with DNS , it can be summarized as the service on the internet that takes the website address or server name you type in and translates that into something your computer and systems on the Internet can use to find your website or server.

So why use OpenDNS?

Whether your know it or not, when you are hooked up to your cable modem or DSL line, your internet service provider (ISP) automatically tells your systems which “DNS” servers they should use. Is this a bad thing? No, but using OpenDNS can give you much more functionality than than the DNS servers your ISP gives you to use.

What does OpenDNS do that my ISP’s DNS servers don’t do?

The OpenDNS servers offer many services that regular DNS servers do not.  Below is a list of the services that OpenDNS can provide.

• Phishing & Botnet Protction
• SmartCache
• Web Content Filtering
• Constant Updates
• Whitelist/Blacklist Mode
• Detailed Statistics
• Typo Correction
• Shortcuts

Isn’t there sofware I could install that does this?

Yes. But the problem with software is that it only works on each machine after you install it. The software must also be updated from time to time. It is also possible to bypass web filtering software installed on computers if you really want to. By using DNS servers to provide this function, you don’t have to install or maintain any software on your computers, it doesn’t slow anything down, and it is much easier to maintain. Once you are using OpenDNS it is maintenance free.

Also, does your website filtering software run on your iphone or samsung tablet or MAC or Linux machine? Probably not. But OpenDNS can provide the functionality at your home without having to install anything.

So how do I use OpenDNS?

Go to http://www.opendns.com and sign up for an account. Once you do you can find information on how to configure your computers to start using OpenDNS.  OpenDNS is an easy way to help restrict access to websites that are inappropriate for children and protect your computers from bad websites overall. The alternatives require more work or more cost, and don’t typically provide any more features.

Unauthenticated =  No usernames and passwords are used in the scanning or testing.

• This means if your website allows users to create a shopping cart tied to a user, the testing will never attempt to use a username and password to replicate a user’s useage of that shopping cart.

• This type of testing is typically less intense because it will only be able to find basic configuration issues or input and output validation type errors that don’t include the code base that handles user transactions like shopping carts.
• Unauthenticated scanning and testing do not attempt username and password combinations to attempt to logon to your system.

Authenticated = The scanning or testing is able to use usernames and passwords to simulate a user being on that system or website.

• Authenticated testing can be much more intense and have the possibility of causing impact to your website or system.

• Authenticted testing will usually find more vulnerabilities than unauthenticated testing if a vulnerability scanner is given credentials into a system. This is simply due to a scanner’s ability to see more of the system due to being able to get “inside” the system and validate issues instead of the guesses that a scanner or tester can has to make without authentication.

• Authenticated testing has much better code coverage on applications since it can simulate all of the user based functionality like transactions.
• Some authenticated scans can simulate “brute-force” style attacks, which could cause account lockouts depending on your system configurations.

Why should I care?

• Authenticated testing is much more thorough and is often able to find more issues than unauthenticated. However, it is also more likely to cause issues on a system or application.

• Since authenticated testing will often find more, you will spend more time parsing through data and trying to determine which findings are higher risk.

• Finally, unauthenticated testing alone will not simulate targeted attacks on your application or system, and is therefore unable to find a wide range of possible issues.

Ask yourself these question to decide what kind of testing or scanning you need.

• What is the purpose of the scan or test? (Specific compliance requirement??)
• Do my scanning or testing requirements give preference to authenticated or unauthenticated testing?
• Do I want to simulate what a user on the system could do? (Go with Authenticated)
• Do I want to start at the highest risk findings that a dumb scanner on my network could find? (Go with unauthenticated)
• Is this the first time the system or network has ever been scanned or tested? (Go with unauthenticated unless you have other requirements.

So what should my approach be?

Using a risk based approach, you could start with unauthenticated scanning and testing because it will typically find the highest risk and most glaring issues. Once you have the unauthenticated findings, you can gradually start authenticated testing once you have a good comfort level that it will not impact systems.

Note*** In large environments you may need to be wary of old printers and devices that may have strange network stacks. You will typically only see scan issues on legacy network appliances or devices like old network printers.

Qualys, Inc. just recently announced IronBee,  a new open source web application firewall project.

The project appears to be funded mainly by Qualys, Inc, but Akamai also appears to have some influence based on the press release published on Feb 14, 2011.

This new project is led by some of the same folks that originally developed ModSecurity, but appears to be more focused towards widespread usability and a “cloud” or Software as a Service design.

Why WAF?

Web Applications Firewalls (WAF’s) are not used nearly enough where they could be helpful to block web application vulnerabilities.

When I have discussed the non-usage of WAF”s with various folks that manage webservers, their answer was that they added another layer of complexity they did not want to manage.

IronBee seems to be answering many of the issues folks have had with WAF’s by offering…

• Ease of implemenation
• Portability of rules
• Flexibility of implementation

There are many reasons to use a WAF, and projects such as IronBee are reducing the reasons not to use one.

The Business of Web Application Security

• I can see Akamai using IronBee as part of their WAF solution offered to customers.The flexibility of implementation may save them costs over their current WAF solutions.

• Companies like Qualys  could offer a cloud based WAF like IronBee to help protect the customers that are already using their vulnerability scanning services.

• Web Hosting providers like RackSpace or GoDaddy could more easily offer a WAF like IronBee as a default part of their service, or charge a slightly higher fee to protect your website with a WAF. This concept is already being used with HyperGuard on Amazon Web Services.

I’ll be keeping track of the IronBee project, and possibly offering help where I can.

Some compliance standards (PCI-DSS) require quarterly scans of your external and internal networks that are “in scope” for your specific compliance related systems or networks.

Why Quarterly Scans?

Requiring quarterly vulnerability scans and remediation is an easy way to set a minimum standard for scanning and remediation of vulnerabilities. Quarterly scans should be considered a “low standard”, where continuous compliance and continuous vulnerability scanning are the widely accepted goal that companies should be working toward.

Why Not Quarterly Scans?

There are some fairly basic timing issues you run into requiring quarterly vulnerability scans and remediation that put an unreasonable burden on large companies while not truly improving security over other methods.

Scenario:

So the requirement is that you Scan AND Remediate vulnerabilities within a 90 day window. So what if it takes 2 weeks to run a scan on your several million IP addresses, and maybe another week or so to run your application scanning on 30 or 40 web applications and put together your list of findings.  You are now easily 30 days into your 90 day window.

Now you get the scan results, process the thousands of findings (because vulnerability scanners tell you everything from what ports are open to missing patches) to determine what truly needs to be worked on, and determine who needs to fix which findings. You are now easily 40 days into your 90 day window.

Next you communicate your findings to the folks that can actually resolve the findings and try to determine who is going to work with you and what they can plan to do, (because they always act like the findings are a surprise even though they have been getting them every 90 days for the past 3 years). This easily puts you 50 days into your 90 day window.

So no problem. We now have 40 days left out of 90 to

1) change requirements for release schedules,

2) make code changes and go through Q/A processes,

4) change priorities for entire infrastructure teams,

5) ask various application teams to go through testing and Q/A for webserver configuration changes.

6) Go through all the normal change control documentation and bureaucracy associated with any decent sized IT shop’s change control process.

7) Validate all of the vulnerabilities have been resolved.

Wait! So that 40 days (not business days, only about 28 business days, or around 5-6 weeks at best) doesn’t seem very long anymore. The more mature of an IT company you are, with more mature testing and Q/A and prioritization requirements you have around your business, the harder it is for you to stop on a dime and change priorities.

What is the alternative???

I feel the true intent of requiring a 90 day window for vulnerability scans and remediation is to ensure that you are regularly looking for and resolving security vulnerabilities.  I propose that measuring “Vulnerability Duration” is more important that requiring quarterly scans. I explain why below.

Vulnerability Duration?

Vulnerability Duration can be defined as the duration of time between when a vulnerability is found, and the time when it is resolved.

What is the difference between Vulnerability Duration and Quarterly scans?

The important difference is that requiring quarterly scans assumes that you have short window of time needed to scan and report vulnerabilities. However, for large companies this simply isn’t possible yet. So requiring quarterly scans and remediation requires a large company to typically only have a month or less to remediate vulnerabilities, because much time is needed to get “workable” findings, and run validation scans on the vulnerabilities within that 90 day window also.

This means that requiring quarterly scans only gives large companies about 30 days or so to react to vulnerabilities. Is this the true intent of the quarterly scan requirement???

Also, the quarterly scan requirement also allows vulnerabilities to exist in environments for over 90 days. If a vulnerability is created shortly after a scan, it can exist undetected for a full 90 days (or more) until the next scan in the next quarter is run.

What is the Point I really want to make??

Vulnerability Duration focuses on the true amount of time that a vulnerability exists in an environment, and doesn’t focus on an arbitrary 90 day window for performing specific actions of vulnerability management. Vulnerability duration focuses on the important stuff. It focuses on how long a vulnerability exists and keeps that duration small.

Measuring “Vulnerability Duration” requires the “Continuous Compliance” mindset. If I can scan  for vulnerabilities every 2 weeks or as often as possible, I have the ability to distribute scan findings much more often than every 90 days. This should create a much smaller window of time that vulnerabilities can exist in my environment because vulnerabilities are….

1) Being found much more quickly.. And

2) Vulnerabilities are resolved much closer to the time that they are found.

What does it take to pull this off?

In order for the focus on Vulnerability Duration to be effective you must be scanning for vulnerabilities as often as possible. This means as soon as one scan ends, the next begins. This constant scanning and reporting of vulnerabilities creates the time saving loop that should create a much shorter window of time that vulnerabilities exist.

Analogy – Leaky Boat

I have a leaky boat. The general estimate is that the boat can keep afloat for a week with a leak. So I only check for leaks once a week. Some weeks, no leaks at all. Some weeks, there is a lot of water in the engine room. On a really bad week, there are several leaks and the boat sinks. If I check for leaks and fix them every day there is much shorter amount of time available for any leaks to flood the boat and cause damage. Although not perfect, I think this analogy makes sense.

Why post this at all?

My whole point is that a PCI assessor,  PCI QSA, acquiring banks, and the PCI Council should consider that quarterly scans are a bare minimum that has been set. Requiring the outdated mindset of having to create quarterly reports can hamper the ability for companies to move forward with a “Continuous Compliance” mindset where they are scanning and remediating all the time and measuring vulnerability duration instead of focusing on this quarterly scan and report requirement.

Alternative to the PCI Quarterly Scan requirement?

Allow an alternative reporting method instead of quarterly scans only. Something like having a PCI ASV attest that scans are taking place more often than every 90 days and that the vulnerability duration of any PCI impacting findings do not reside more than 90 days. Anything open more than 90 days would require some type of documentation.

Let’s face it, a computing platform is only as usable for consumers as the applications that ride on top of it.  Below I explain my logic on why have chosen certain platforms over others.

Mobile Computing – Iphone

http://www.apple.com/iphone/

Application availability.

I am not an “Apple person”, but the iphone is the “anti Macintosh” to me. (The iphone has good pricing and App availability, the Macs demand a premium price with less apps available.)

Over 50,000 applications available for the iphone.  How many applications are available on the other phones? I don’t know, but I know it isn’t even close to how many the iphone has available. And the pricing for apps is reasonable. It’s going to be a while before other platforms catch up. I think there will be better competition in the future, but for now, I’m sticking with the iphone.

Firefox

Plugins!!!

Mozilla has made it easy to develop plugins for Firefox. I don’t particularly like the browser itself any better than IE8 or Safari. However, the abundant plugins available and extra functionality it provides in the browser is unbeatable by the other browsers right now. As browsers become more of an application platform, this may become an even bigger selling point.

Browser developers like Google, Microsoft & Apple need to ensure their plugin development environments are easy to use for developers, and facilitate stable functionality.

Windows 

Apps Everywhere!

Disclaimer, I’ve managed Microsoft systems for years. So I could have some bias here.

Don’t get me wrong, it has not been an easy road. Microsoft is just now maturing their utilities to the point where you can manage large amounts of their machines without having to write your own code using their API’s. (which is what I had to do for years) I’ve had more 36 hour days fixing my Microsoft systems issues than most people have had 12 hour days at work. I don’t even remember having a life my first few years at work.

Some things that Microsoft does do well is listening to customers, and trying to make it easy for people to develop applications for their platforms.  A few years ago there seemed to be a tipping point where you saw applications that had only been available on Apple being ported over to work on Windows. That seemed to be the point where the demand for Windows applications was so large that enterprises and consumers were demanding apps be available for Windows, and they got what they wanted.

I have confidence I can go out and get (either free or purchase) any type of application that I need to work on the Windows platform. Mac & Linux really just don’t have the same volume or variety of apps available.

Summary

To summarize, the success of computing platforms depends on demand for that platform. I feel that one of the main factors for driving the demand of those platforms is application availability.

My advice to companies is to focus on making application development for their platform so easy that anybody can do it, while protecting the system from poorly designed apps.