Today we are excited to launch this revolutionary new platform which extends Qualys’ industry-leading Cloud Security and Compliance Platform with lightweight agents to continuously assess security and compliance of organizations’ global IT infrastructure and applications. Lightweight 1MB Cloud Agents can be easily installed on global IT assets, including on-premise systems, dynamic cloud environments, and mobile endpoints. With these Cloud Agents IT personnel can now search for information about any asset and easily scale to search millions of assets in a matter of seconds.

Continue reading …

The PCI SSC today released a new version  (2.0) of the Data Security Standards. The previous version  1.2.1 was released July 2009. I attended the PCI council community  meetings in September and October where the council went over the  changes with the key stake holders in the process. While the change from  1.x to 2.0 might seem like a big change, in reality most of the changes  are minor clarifications or some additional guidance. The council has  settled on a 3 year update cycle to the DSS and seems like the major  version of DSS with will revved up every three years so expect PCI DSS  3.0 in October 2013. This does show that the standards have matured  enough now that major changes are not required regularly.
The council also talked about the work they are doing to look at  emerging technologies like end-to-end encryption, tokenization and  virtualization. You will see that some of the changes in this version  already reflect recognition of the new technologies and I am sure more  updates will be coming in these areas. The SSC now has a dedicated Chief  Technology Officer who is actively working to make sure the DSS stays  in step with rapid changes in technology.

The key dates associated with the new requirements are

• October 28, 2010 – PCI DSS 2.0 published. Merchants get the opportunity  to go through the new requirements. The council also updated the  Navigating DSS guide and relevant changes to the Self Assessment  Questionnaires (SAQ)
• January 1, 2011 – PCI DSS 2.0 becomes effective. Merchants can chose  to validate compliance against version 2.0 or 1.2.1 after this date.  Remember that merchants can’t mix and match some requirements from 1.2.1  and some from 2.0
• December 31, 2011 – PCI DSS 1.2.1 is retired and can no longer be used to validate compliance against.

Essentially for all of 2011 you can use either version as long as you are fully done with your assessment before end of 2011 if you decide to use 1.2.1

     While the council has left it open for merchants and assessors  to agree upon which scoring methodology to use, in reality I expect  most merchants to use CVSS 2.0 scoring with its base, temporal and  environmental components to decide what is HIGH. While this does put an  extra burden on the merchant, the good news is that once you have the  process in place you only need to fix the HIGH vulnerabilities to pass  validation for 11.2 internal scanning requirement. While it is still  recommended to fix all vulnerabilities this at least helps prioritize the  work load.

     It’s important to remember is that this  scoring and fixing requirement does not apply to 11.2 external scanning  to be performed by ASV every quarter. All vulnerabilities identified by  ASV as failing PCI must be remediated within that quarter and rescanned  till ASV passes the merchant.

      In DSS 1.2.1 the requirement was to implement only one primary function  per server. e.g. Not implement web server function and database server  function on same 'server'. It was not clear in a virtualized environment  if two virtual machines (VMs)

running on the same physical hardware box was considered as two primary functions per 'server'. Now in 2.0 the council makes it easy by saying that in virtualized environments you can have multiple VMs on same physical box as long as each image implements one primary function. So you can have a VM for a webserver and a VM for a database server running side by side but you can’t have one VM with a webserver and database  server on the same image. This should definitely accelerate the use of  virtualization in PCI CDE since clarity for compliance was an issue that  was holding back the adoption of virtualization.

     DSS 1.2.1  indicated there should be no WEP in the CDE at all after June 30, 2010.  But DSS 2.0 has modified the language to say mere presence of WEP in CDE  does not fail you as long as the WEP is not used as the security  control. You can have WEP in the CDE as  long as it is considered like an open wire. This means you need to have  another level of encryption to protect data sent across a WEP  connection, it can’t be plain text because you have WEP. e.g. sending data over SSL on a WEP wireless connection would seem to be ok.

      You might find it funny but some merchants were using the same authentication method twice, and folks that is NOT two-factor authentication. Having two different passwords is NOT two-factor authentication. To illustrate that think of a stealth key logger installed on your computer that will be able to steal both your passwords to login and steal data. Because of this,  the council makes it clear you need to have TWO different methods of the following implemented. 1) Something you know, like a password. 2) Something you have, like a token or smart card 3) Something you are like biometric data.

All in all we see the number of merchants adopting PCI increasing.  The council has done a great job at being reactive and responsive, in  an open community based effort, to get the standards to a mature state.  Now they are attempting to stay ahead of the curve with new technologies  in a dedicated effort working with industry leaders. Ultimately we  expect DSS 2.0 to help merchants improve the security of their PCI  networks while providing flexibility with their compliance efforts given  the many different implementations that are out there.

Please post your thoughts on the new version … what do you think?

** The views expressed in this blog are a reflection of the author’s  thoughts on this topic. They should not be considered an authoritative  interpretation of the new or old DSS for purpose of compliance.

The September 1, 2010 deadline is here and the new PCI DSS scanning changes announced by PCI SSC earlier this year go into effect today. The new ASV program guide 1.0 includes considerable changes to the way ASV scans are performed. A lot of attention has been given to scoping, discovery, scoring and attestations. These are great improvements and bring about a lot of uniformity and accountability in the scanning process even though it does add a certain amount of extra work on the merchant and the ASV.  Today we released QualysGuard PCI 5.0 to support the new requirements and help merchants easily navigate through the complexity these requirements bring about. All of us in engineering have been working on this release for the past few months, and we have put in considerable efforts to come up with a very cool UI to increase the interactivity and ease-of-use of the product, starting with the home page all the way to submitting the report for attestation. We are very excited about these new features and we hope you will like them as well. We welcome any feedback, so feel free respond to this post and ask questions or provide comments.

Let me summarize the new UI capabilities added to QualysGuard PCI 5.0 and discuss how these changes support the new ASV requirements for today’s deadline:

Dashboard:

The new dashboard style homepage instantly presents a clear view of the current status of your network by showing whether you are passing or failing and what % of hosts are compliant. We also show counts of vulnerabilities under the new categorizations of High, Medium and Low. No matter how large your network, you can get this info without running any reports. The same applies to the SAQ dashboard, which shows how complete your questionnaire is, and how many YES/NO answers you have filled out. Also the new homepage is a great starting hub for all the important workflows like the asset wizard, SAQ wizard or starting a scan.

Reporting:

There are many new changes in the reports. New scoring criteria for vulnerabilities based on CVSS base score (High, Medium, Low). Reports now include clear information of passing/failing components as well as documenting false positives etc. In the application the main change is the interactivity of the reporting module with sliding panels for detailed information, as well as quick filters that help you search and sort on various criteria instantly. Navigation is very easy and pages are loaded without needing a full refresh of the screen. There is also a very useful graph of your current account summary highlighting the potentials and confirmed vulnerabilities. PCI council has made a clear statement now that ALL ASVs need to report potential vulnerabilities, which Qualys has always done from the beginning.

Compliance:

The new compliance report wizard walks you through every step of the process in an informative manner presenting the various tasks that need to be taken care of for the compliance report, including a way to fill out the mandatory merchant attestation. 'Special Notes' are required for certain type of software detected on the network. Merchants can provide a consolidated action plan for IPs that still fail compliance. The wizard will then walk you through the steps to attest the report and request a review of the report from the ASV. Given the extra steps I recommend merchants allow for an extra 3-5 days to get the review completed before they can download certified reports.

Assets Wizard:

A new workflow has been added to walk merchants through the process of identifying IPs and domains that are in scope for PCI compliance. providing the URL of your payment application is important so we can scan it for various web application vulnerabilities like SQL injection and XSS. There is a new discovery process that tries to identify other ips based on common host-names like www, mail, smtp and MX record lookup to provide merchant with option to include them in their account. Steps have been included to attest to load balancer settings as well as provide info on configuring IPS/IDS to allow for Qualys scanner ips as this is a requirement from the council.

False Positives Reporting Workflows:

The new requirements states that all approved false positives must be revalidated by the ASVs on a quarterly basis. In order to help you identify these expired false positives, we introduced new workflows with an easy-to-use false positive request tracking interface to identify them and resubmit for approval every 90 days.

Seamless Integration with QualysGuard:

Another important change is that now customers using QualysGuard to perform PCI scanning can continue to do so in QualysGuard, but must use QualysGuard PCI to generate certified reports and submit for attestation. As part of this release, we have added seamless integration between the two products to facilitate this attestation process and allow customers to continue to use QualysGuard (Enterprise, Express or Consultant) for PCI scanning. For more information, see Using QualysGuard PCI integration.

As you can see, these are all considerable changes and we hope they will help all our customers, as well as our ASV partners, that use QualysGuard in their PCI practices to become more efficient in managing PCI compliance. I have attempted to make a quick video highlighting the new QG PCI 5.0 UI as best as an engineer can :-) Please give us your feedback!!

Sumedh

Today the PCI Council released a summary of the expected changes to PCI-DSS and PA-DSS v2.0 releases scheduled for October 2010. You can find the summary on their website.

Remember that this is just a list of the highlights of the proposed changes. The actual changes themselves will come later. The draft of the new DSS will be shared with the PCI community in September at the Orlando meeting and then likely to be published in October 2010. Changes will be expected to take effect Jan 2011.

Apart from bunch of interesting 'guidance', 'clarifications' and 'evolving requirements' what I found most interesting was the language around virtualization. Current requirement 2.2.1, with its language of "one primary function per server", has always been the thorn in the side of many merchants trying to catch up with technology and become more scalable and dynamic by using the powers of virtualization. What if you do want to put a virtual webserver and virtual database on the same physical server? Does it violate the "one function per server" requirement?

The PCI council had setup a SIG to deal with virtualization and it going to be awesome to finally see their recommendations getting incorporated into the DSS. We will have to wait and see the actual language in the new standard but it’s encouraging to see that PCI DSS is addressing the cloud and virtualization!  It will be interesting to see how that change affects other requirements like firewalls and pen testing and performing vulnerability scans of dynamic environments with images that are not up all the time. I suspect merchants will be able to use the 'sampling' route to comply with the other requirements.

In any case, I am looking forward to the PCI community meeting in Orlando to get more details on these changes and discuss them with the council and the community. And I hope the results will make quite a few merchants who want to fly to the 'cloud' very happy!

Sumedh