New Adobe Reader security feature - Protected Mode

Adobe has introduced this new security feature in Adobe X, the latest version of the Adobe Reader. This feature helps prevent exploits seeking to install malware and/or change the registry. This should help reduce the web-based attacks with malicious PDF, which had skyrocketed in the past year or so. According to Symantec, it accounted for 49% of web-based attacks in 2009.

Protected Mode is a sandboxing technology based on Microsoft's Practical Windows Sandboxing technique.  All operations required by Adobe Reader to display the PDF file to the user are run in a very restricted manner inside a confined environment, the "sandbox." Should Adobe Reader need to perform an action that is not permitted in the sandboxed environment, such as writing to the user's temporary folder or launching an attachment inside a PDF file using an external application (e.g. Microsoft Word), those requests are funneled through a "broker process," which has a strict set of policies (ACLs) for what is allowed and disallowed to prevent access to dangerous functionality.

This option is enabled by default for all "write" calls on Windows 7, Windows Vista, Windows XP, Windows Server 2008, and Windows Server 2003. Of course, the effectiveness depends on the ACLs and what action is permitted and denied.

Adobe Reader X is available here.

PCI 2.0 - What's new?

PCI council released the new version of the standard, PCI 2.0. Overall I feel that it is a welcome change since it either clarified or modified some of the requirements rather than leaving it to the QSA's interpretation. The requirements are now more practical and removed many ambiguities. It is a good sign that PCI council is listening to the complaints and improving the standards while keeping the core standard and requirements untouched.

Some of the major changes are below:

• Added "virtualization components" and added "If virtualization technologies are used, verify that only one primary function is implemented per virtual system component or device. " - This has been one of the most debated controls and now we have more clarity in this area.

• Clarified that segmentation may be achieved through physical or logical means. 

• Clarified that direct connections should not be permitted between the Internet and internal networks.  - In the earlier version it was direct "route".

• Removed specific references to IP masquerading and use of network address translation (NAT) technologies.  - PCI council has now realized that there are other methods to achieve the results. 

• Clarified that it is permissible to store sensitive authentication data when there is a business justification and the data is stored securely. 

• Clarified that key changes are required when keys reach the end of their defined cryptoperiod, rather than "at least annually."  - This is another big relief for IT operations folks and developers.

• Clarified that key custodians should "formally acknowledge" their key-custodian responsibilities rather than "sign a form."  - When companies use online acknowledgements and digitally signed emails, this is no longer required.

• Clarified that the test should confirm that audit log processes are in place to "immediately restore" log data, rather than that log data should be "immediately available" for analysis.  - This is the most welcome addition for SOC and monitoring groups since they don't need to keep the data "online". This will ensure that we have faster query time and faster analysis of near real-time data. This will also ensure that online data storage requirements and processing powers are no longer an issue, SIEM vendors will love this.

• Clarified that the internal scan process includes rescans until passing results are obtained, or all "High" vulnerabilities as defined in PCI DSS Requirement 6.2 are resolved.  - This is another welcome addition, IT operations folks can now concentrate on fixing "high" risk vulnerabilities. However, this may force organizations to forget about medium and low risk vulnerabilities.

• Modified the statement "Verify that noted vulnerabilities were corrected and testing repeated" to state "Verify that noted exploitable vulnerabilities were corrected and testing repeated".  - Even though it is good for the organizations, I have a feeling this is going to be controversial as to how organizations can verify the exploitability, using what services and tools. Is it really required to have a tool like Metasploit, CoreImpact, etc? This may require more clarification.

The new version is available for download from here.