HOW TO WRITE A PENETRATION TESTING REPORT

I see some people regularly asking for sample penetration test reports. Well, here's some I found on the net.

Sample Penetration Test Report by Offensive Security-- An excellent report by an excellent team.

www.offensive-security.com/offsec-sample-report.pdf

Writing a Penetration Testing Report -- Probably one of the best papers on this subject. It was written by Mansour A. Alharbi for his GIAC certification. The author starts with report development stages, then describes the report format and ends it with a sample report.
http://www.sans.org/reading_room/whitepapers/bestprac/writing-penetration-testing-report_33343

Report Template-- A report template by vulnerabilityassessment.co.uk

www.vulnerabilityassessment.co.uk/report%20template.html
PDF version:

http://www.okdhs.org/NR/rdonlyres/EDC02492-637C-4C45-B305-35856EBEE8DF/0/SecurityPenetrationTestResultsRprttemp_EPMO_05052009.pd

Penetration Testing Report-- Sample report by niiconsulting.com

http://www.niiconsulting.com/services/security_assessment/NII_Sample_PT_Report.pdf

Penetration Test Report-- Another good sample report

www.besnard.org/biometrics/2BIO706_business_report.pdf

Penetration Test Report-- Sample OSSAR report

www.digitalencode.net/ossar/ossar_v0.5.pdf

penetration testing report template-- Template by logicallysecure.com

http://www.logicallysecure.com/resources/downloads/penetration%20testing%20report%20template.doc

How to develop an enterprise security policy

By Marc Gartenberg

Computerworld - Policy is the cornerstone of an effective organization. It serves as a road map that every person in the organization can use in a variety of ways. However, the policy document has to be overarching and fairly all-encompassing -- clearly a challenge from the start. As such, policy development is often referred to as an art as well as a skill.
Federal agencies have a statutory obligation under the Federal Information Security Management Act to maintain an up-to-date security policy. The responsibility lies with the CIO, the chief information security officer (CISO) and, ultimately, the head of the agency. This maps well to industry; just replace the agency head with the CEO.
A good security policy takes into consideration the mission of the organization, the critical assets requiring protection, the threats posed and the mitigating risks against known vulnerabilities. These are all parts of a risk assessment that includes a business-impact analysis, which identifies the weaknesses, the critical assets and the effect on the company if vulnerability were exploited.

Developing a security policy isn't a daunting task once the scope is identified using this simple explanation. The challenges are in defining the scope and writing a policy that can be embraced by other areas of the organization.

By definition, the policy is the high-level document that's used to guide the formulation of procedures and guidelines. The policy answers the question of "What should be done and by whom?" The procedures and guidelines answer the question of "How should it be done?"
Below are some tips for developing a comprehensive enterprise security policy. It's a checklist for any policy wonk given the responsibility of putting the document together. 

1. Know your organization. Without a realistic understanding of the organizational structure -- the players, the environment, the mission, goals and objectives -- it's exceedingly difficult to write a policy that will fit. Therefore, knowing the lay of the land -- the hierarchy and the roles and responsibilities of different areas -- is very important.

2. Define the scope and the agenda. What will the policy cover? This should be stated upfront in the policy document. Equally important is what it won't cover. If you can derive both, it will be meaningful to the people who need to translate the policy to practical procedures and/or guidelines.

3. Know your target audience. Who are the stakeholders for the various sections of the document? Who will be reading and signing off on it? The CEO, CIO and CISO are normally the key stakeholders, and each has a specific agenda that should be addressed. For the CEO, it would be the areas derived from the business-impact analysis; for the CIO, it would be the overall enterprise architecture and infrastructure that aligns and enables the CEO and the organizational mission; and for the CISO, it should address the critical infrastructure and assets, along with risk, vulnerability and mitigation focus.

4. Stay high-level, general and broad. These are critical points that need to be remembered as each policy statement is written. Going too far down in the weeds leads to the area of procedures, so it's important to keep the policy statements at the appropriate level and aligned with the mission.

5. Ensure that it can be easily translated to procedures and guidelines by the appropriate areas. Try a small sample, imagine the area to which the policy might apply and see if you can easily derive a procedure or guideline. After all, you might be asked for some examples down the road by less-experienced managers.

6. Keep weaknesses and organizational deficiencies in mind so the policy can address specific areas while staying aligned with your goals. Recognize the gaps and try to bridge them through policies. Keep the mission and business-impact analysis in mind. These are critical to effective policies that supplant the gaps in organizational functionality.

7. Be aware of external drivers. Depending on your industry, there may be regulatory requirements or cross-cutting laws. The policy should address the requirements to ensure compliance and make your organization a model.

8. Be realistic. If you can get a first cut past the approving authorities, it's a step in the right direction. Policies can never be static because the environment and organizational operations are always changing. Companies on the leading edge are dynamic in nature, and gaining competitive advantage requires continuous change and improvement. A policy that addresses 90% of the needs and is implemented is better than one that aims for 100% but never gets out of draft mode.

9. Ensure version control and backups. This seems like common sense, but you'd be surprised at how many organizations don't maintain tight version control, including documented procedures for modifications along with a good single backup strategy. You never want to end up hunting for the most current policy document, nor should you ever question its integrity. This in itself may require a policy.

10. Avoid controversy. This of course depends on how well the policy is rolled out and what changes are made. If change is required, do it incrementally. It hurts less. Having the backing of senior executive leadership is also important in the event that critical gaps require immediate change.

11. Wear a white hat. Remember, the whole reason for developing security policies is to benefit the organization and its personnel. If you are given the task of getting the job done, try to get acceptance from the key managers sooner rather than later. An effective policy development effort has collaboration written all over it. And, done properly, it can even be fun.

12. Finally, don't forget to smile and keep your sense of humor. It can be an intense effort, but by using proven project management methods, including milestones and timing, you can ensure that the important pieces are addressed first and that stress is minimized. It comes down to having a good road map, a strategy and a flashlight.