Finding the Right PCI Approved Scanning Vendor for Your Small Business

by Kristyan Mjolsnes @ http://www.secureconnect.com . June 7, 2010 . 9:45AM

For many businesses, maintaining PCI compliance and security in a fast changing world is a very stressful task. The best way to lower the stress and inherent hassles in security is to begin by finding the right PCI Approved Scanning Vendor for your small business. Instead of having to do everything yourself, you can contact a PCI Approved Scanning Vendor to make sure that your needs are being taken care of properly.

Chances are, if you process credit cards, the Payment Card Industry Data Security Standard (PCI DSS) requires that you perform quarterly vulnerability scans through a PCI Approved Scanning Vendor.  Beyond the scans however, this vendor will be able to provide expertise and cosultations to help answer questions or concerns you may have.  It is important to establish a foundation from which you can improve your security for the long term.  An Approved Scanning Vendor, such as SecureConnect, can advise you on where to start next with your security, and study your current security policy for any holes that could grow into more serious problems later down the line.

Overall, if you really get serious about finding the right PCI Approved Scanning Vendor for your small business, you will truly be one step closer to the security that you deserve!  Contact us today to learn more!

Vulnerability Management…What is that?

by Andrew Brooker, CISSP @ http://www.secureconnect.com . February 9, 2010 . 3:18PM

“Maintain a Vulnerability Management Program – What in the world is that?!?” No doubt many have said that to themselves and even if the words are defined the meaning is still unclear. Interestingly enough, the concept of “managing” vulnerabilities can be an effort in herding cats.

The difficulty lies in the defective software and operating systems – we have accepted the defects to be normal and without ability to change.  However, if it were a defective car or television, we would return it, call the headquarters to complain, and phone the BBB in an effort to curb future problems.  Without much uproar from buyers, the software companies have no motivation to change.  So here we are with the problem; keeping a handle on these vulnerabilities isn’t difficult because the landscape is changing, but instead, because more defects are being found. In most cases it is nearly the same vulnerability being exploited in a slightly different fashion or better yet, a technique used on one application, then ported to another vendor’s product.  What are we to do?

Avoid.  So the major payment card brands (Visa, Mastercard, Discover, JCB, and American Express) and the Security Standards Council do understand the importance of getting to the source – avoiding defects in manufacturing. A good portion of Requirement 6 (6.3, 6.4, 6.5) is about avoiding vulnerabilities by having quality (I mean secure) development. It underscores initial avoidance by ensuring systems and applications are up-to-date before going into production. And it underscores ongoing avoidance by adhering to set policies, standards, testing, and change control to preserve the environment.

Know.  Vendors are reactive when it comes to vulnerability discovery and remediation.  They wait for someone to bring a problem to their attention.  Then they prioritize what they will create a “patch” for.  Considering this is the general approach, from a security standpoint, it is too late.  Staying in the loop is crucial to ensure we can stay as forward as possible in this lagging process.  Enrolling in Internet weather, vendor, and industry alerts is must. Though you may find redundancy in notifications, what you derive is a better determination of risk.  Understand that vendor rating systems are skewed and often don’t accurately portray the impact a vulnerability may have.  Balancing the volume of patches to be applied and the downtime you need is a real challenge; having the right information to make the right decisions is required. (Requirement 6.1, 6.2)

Apply.  Now you know and half the battle is won.  The other half:  Acting on what you know.  Requirement 6.1 sets the standard at a one month cycle.  Keep in mind that this is your cycle; however it is defined in your policy.  The goal is to stay on top of all the critical patches and ensure they are applied quickly. In reality, this standard is not stringent enough for most organizations, as many of the recent vulnerabilities require immediate response, and one month is merely academic.  Remember, we are discussing vulnerabilities, not patching; as such, we can’t forget about anti-malware (or application white-listing).  With an estimated one-million new pieces of malware each year, it would be irresponsible not to have some malware mitigation in place.  Not only can anti-malware assist with the “defects”, it provides the much needed protection from users.  Clicking the wrong pop-up, the wrong hyper-link, or opening the wrong attachment in an email can provide a whole host of issues, you don’t want to deal with!   Do the right thing; use a widely accepted anti-malware or true application white-list.  Make sure it is running and the signatures/policies are up-to-date.  Often, even if the mitigation software can stop or remediate the rogue software, it can serve to alert of the activity taking place allowing you to take action.

I gave the indication that this process is a battle that can be won. Maybe that is true, but it is the war that cannot.  With all things security related it is about posing “best-effort”. Specifically with “managing vulnerabilities,” it is the notion of containment not control that should come to mind.  Follow good practice, stay informed, and act quickly – this is the best that can be done until the root problems are addressed.