Adobe Reader X - Sandbox

Published: 2010-11-19
Last Updated: 2010-11-19 17:45:42 UTC
by Jason Lam (Version: 2)
9 comment(s)

Adobe released the Reader X version today. This is the version of Reader that has sandbox feature built-in, there is now a degree of separation between the OS and the potentially malicious PDF files. The same sandbox mechanism had been implemented in Google Chrome and also MS Office. Containment of the harmful files lessen the damage should a successful attack were to happen. Given the amount of 0-day attacks on this software, we recommend our readers on Windows platform to upgrade to this version of Reader soon to leverage the sandbox technologies. While it does not prevent all exploitation, every little bit helps.

Adobe has written a series of blog entries explaining the sandbox mechanism. A good read if you are curious how it helps to protect against attacks.

9 comment(s)

Exchanging and sharing of assessment results

Published: 2010-11-19
Last Updated: 2010-11-19 06:26:39 UTC
by Jason Lam (Version: 2)
3 comment(s)

Penetration tests and vulnerability assessments are becoming more common across the whole industry as organizations found that it is necessary to prove a certain level of security for infrastructure/application. The need to exchange test result information is also increasing substantially. External parties ranging from business partners, clients to regulators may ask for prove of tests being done and also results of the test (aka. Clean bill of health).

The sharing of pentest information can create a huge debate, just how much do you want to share? There are at least a couple ways to get this done. The most seemingly easy way to do this is to share the whole report including the summary and also the detailed findings. While this seems easy, the party sharing out the report may be exposing too much information. Pentest reports can be like treasure map to attack an infrastructure and/or application. The detailed report usually include ways to reproduce the attack and effectively documenting a potential attack path in a step by step manner. It is true that vulnerabilities should be fixed as soon as possible after the pentest is done. Consider this scenario, the day after pentest is done, the regulators shows up and ask for the most recent test result. If you are not above the law, you should be yielding the latest report that is full of unfixed flaws.

Another way to share pentest result is to only share the executive summary portion. This portion of the test report usually gives a good overall view to what was done in the test and what sort of overall security posture the test subject is in. While this protects the party sharing out the test result, this may not grant the reviewer the right kind of information.  Some executive summary does not contain sufficient information especially those ones done by less competent testers. Aside from that, one of the trend I am noticing is the less experience the receiver of test result, the more him/her want to see the whole report, they just don’t know how to determine the security posture based on the executive summary alone.

There is no current industry standard for this kind of communication, it seems that all the exchange and sharing currently done are on ad-hoc basis. Some like it one way and others like it another way. I consider the current baseline for this kind of communication to be a well written executive summary containing actual summary information of the test with the methodologies used and also the high level view of the vulnerabilities that was found to be sufficient for giving a decent view into overall security posture. This obviously can escalate into a full report sharing if the quality of the executive summary just isn’t there.

If you have any opinions or tips on how to communicate this kind of information, let us know.

3 comment(s)

Comments


Diary Archives