Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

Background

I'm in charge of auditing a medium-scale web application. I have audited web applications several times before, but I've always wrote a short PDF quickly explaining what I encountered and usually I'm the one who's gonna be fixing those vulnerabilities so I never cared for the actual contents of the report.

In my current job things are done in a way more organized fashion. First I have to write the report, then the project manager will review it, then he'll decide whether I'll be the one to fix the issues or someone else.

Question

What should such report contain? I'm looking for a general outline of how it should be organized.


Update: Because I couldn't find anything here on Security.SE about audit reports, I decided to make this question a bit broader and include any kind of security audit rather than just web applications. I think it'll be useful to more people in this case.

share|improve this question
    
I'd like to add that GIAC has what appears to be a sample security audit report. It is a very detailed sample report with good references and appendices, although it might be an actual security audit report. It's nearly 70 pages but it's definitely worth the read. –  Adnan Feb 1 '13 at 16:33

7 Answers 7

up vote 16 down vote accepted

There's a couple of ways that I've seen this done, each has it's pros and cons.

As noted by @RoryAlsop below a common point for both approaches is that the executive summary should, as much as possible, be written for a business audience (assuming that it's a test you're doing for a 3rd party or the report will be passed to management).

  • Reporting by finding. Here you list the findings, usually ranked by severity (e.g. CVSS score or some other scale like severity/likelihood). You then list out the technical details of the finding and potential mitigations if you have that information. This kind of report gets to the point quite quickly and plays well with tool output.
  • Reporting by methodology. Assuming here that you're following a defined testing methodology, the report is structured along the lines of the methodology and includes a section for each area of the review. The sections detail what testing was done and the outcome (e.g. either a finding or the fact that there was no finding in this section). The advantage here is that you're showing your workings and that someone reading the report can get a good idea that you've actually tested something and it was ok rather than you just having missed it out. The downside is that it tends to be a longer report and harder to automate. One other gotcha is that you need to make sure that the testers don't just follow the methodology and they actually engage brain to look for other things.

In terms of format for the findings, I usually include the following

  • Title (descriptive gets used in the table and linked to the detail)
  • Description - technical description of what the issue is and importantly under what circumstances it is likely to cause a security issue (e.g. for Cross-Site Scripting one of the potential issues is use to grab session tokens which could allow an attacker to get unauthorised access to the application)
  • Recommendations - How the issue should be resolved, where possible include specific details on vendor guidance to fix it (e.g. things like removing web server versions from headers have specific instructions for Apache/IIS etc)
  • References - Any links to additional information that's relevant to the finding (e.g. links to the relevant OWASP page for Web app. issues)
  • Severity. As I mentioned above this could be CVSS or something more general like High/Medium/Low based on impact and likelihood.
  • Other classification as needed by the client. For instance some client might need things lined up against a standard or policy or something like OWASP Top 10.

One other point to make is that if your do a lot of tests it's well worth having a database of previous findings to avoid having to look up references repeatedly and to make sure that severities are consistent.

share|improve this answer
    
All of the answers complement each others, but I must say I like the way this was explained. When you have time, could you please give an example of what you think would be a good entry for a finding? Soon this will top search results on Google about the matter (almost nothing about it anywhere else) so it would be nice to see that in the accepted answer. Thank you –  Adnan Jan 24 '13 at 18:08
1  
The one other thing I would add here (and I may be biased due to where I have worked the last 10 years) is that including an interpretation of what the report means in business language is essential if you want the organisation to understand the real risk to them. This (hopefully) drives correct response to the report. –  Rory Alsop Jan 25 '13 at 11:37
    
@RoryAlsop, a very important point, business language. That can play a great role in management's decision on handling these issues. –  Adnan Jan 25 '13 at 11:43
1  
@Adnan Updated with some details on format of findings, is that the kind of thing you were thinking of? –  Rоry McCune Jan 25 '13 at 12:09
    
@RoryAlsop good point, added. –  Rоry McCune Jan 25 '13 at 12:12

After a Penetration Test or Hybrid Application Analysis the resulting report is centered around the findings. There should be a high level overview that discusses the flaws and their collective impact on the system.

A finding is any security violation. This includes any CWE violation, but the most common web application findings fall under the OWASP top 10. Each finding should have steps to reproduce the problem, a severity, the impact of this flaw, recommendations for fixing the issue and links with more information. For example if you find an XSS vulnerability, show a screen cap of an alert box and the URL you used to trigger the issue and link to the OWASP page on XSS. If you can access the cookie with XSS, then the issue can be used to hijack a session, otherwise it could be used to undermine CSRF protection.

What if you can't find anything? Keep looking! The CWE system is massive, and even the most seasoned develops will make mistakes. There are vulnerabilities that affect literately every application I have touched. Clickjacking, lack of brute force protection, and Information disclosure is probably the most common. For example username/email address disclosure via the forgotten password or signup feature. Displaying version numbers (http headers or anywhere else). Verbose error messages, local paths, internal ip addresses.... anything that might be useful to an attacker.

share|improve this answer
4  
First of all, +1 for the appreciated effort. But most of the answer is irrelevant here, you're suggesting things to look for. My problem isn't with how to perform the audit, it's with outputting the results themselves in a professional manner. So I think the helpful part of this answer the second paragraph, could you please expand on that? Thank you. –  Adnan Jan 24 '13 at 16:29

I think what Rook says it very true, though this is more about the core of report, rather than its structure, to be placed after the report format has been designed.

Try the STAR model (Situation, Task, Action & Result): I have seen great reports written with this model under the hood. The great thing about it is that it can be used in almost all contexts: you would just need to adjust to what is relevant to you. In this case, you could structure your report around this model and use what Rook described to fill in the structure.

Also, even if you have no actual findings, you could still write a full report based on the STAR model and still deliver something that is professional and coherent.

share|improve this answer
    
Excellent, this is more in the direction of what I'm looking for. –  Adnan Jan 24 '13 at 16:33

Adnan,

Exciting question! Too often I feel that our industry strives for the latest and greatest fad in security. We go after the latest exploits, spend serious cash on the latest tools and blame layer 8 for the gaps. I know that is a gross generalization, but I wanted to underscore the importance of this topic -- Reporting!

I have my opinions as to what should be included in a Vulnerability report. From a structure perspective a thorough report will have the following:

  • A title page: this will indicate the report name, the agency or department it is for, the date as to when the report was published.

  • A table of contents: Seems obvious, but these documents can get lengthy, include this as courtesy.

  • An executive summary: This will be a high level summary of the results, what was found and what the bottom line is.

  • An introduction: A simple statement of your qualifications, the purpose of the audit and what was in scope.

  • Findings: This section will contain your findings and will list the vulnerabilities or issues that should be re-mediate. This listing should be ordered by critical levels, of which are hopefully defined by internal policies (i.e. if your vulnerability scanner finds a high critical vulnerability, based upon how that vulnerability is implemented in your environment, it may not be a true high critical, so internal policies should assist in defining the critical levels)

  • Methodologies: Here you will discuss tools used, how false positives were ruled out, what processes completed this audit. This is to provide consistency and allow your audits to be repeatable in the event a finding is disputed or deemed not worthy of fixing by management.

  • Conclusion: Basic conclusion, summarize the information you have already put together.

  • Appendixes: This will be any extra attachments needed for reference.

Some of the folks over working on the PTES are laying down some good foundations. While the focus there is penetration testing, I would think that many of the methodologies, especially reporting, could be transposed for an audit. You can check them out at: http://www.pentest-standard.org/index.php/Reporting

share|improve this answer
1  
This answer is together with @RoryMcCune's the most complete and it should really receive more up-votes than it currently does IMHO. That PTES link you're including was also the first thing I thought about when reading the question. I'm sure a lot of thought and experience went into preparing it, is comprehensive, and gives a good insight into the scope of pen-testing in general. It should be a good start for security audits as well, if possibly a bit overwhelming LOL. Also relevant: pentest-standard.org/index.php/Intelligence_Gathering (and most of that Wiki, honestly). –  TildalWave Mar 31 '13 at 10:47

I've never written a security audit report, though in my role I tend to receive them. The best one that we had looked over our whole product at specific areas in interest. The report was broken down into those areas. Overall the format was:

  1. Title
  2. Executive summary - a brief overview of the purpose and scope of the audit. And high level comments, on the main areas of concern, and more importantly cover those areas that are done well
  3. Assessment methodology
  4. System description - covering the deployment being investigated
  5. Then sections on each area/target
  6. Summary and recommendations

Section 5 was broken down for each target as:

  1. Introduction
  2. Objective
  3. Significance
  4. Assessement (covering methodologies and actual vulnerabilities)
  5. Conclusion
share|improve this answer

In first: It's like writting a book, first line will keep reader or not. (The Intro is to write at least.)

Something like intro, begin, content, end.

  • Introduction
  • Goals
    • Refresh terms of contract.
    • Description of targets
    • Description of methods
  • Execution
    • Step by step: goal, action, reaction
    • Observations -> questions
    • furter operations, step by step
    • New observations...
    • furter again... and again if in case
  • Conclusion
    • success or not
    • what clearly wrong, having to change
    • what fail, having to be corrected
    • purposes

Some trick having to keep in mind:

  1. Your work is not intended to be read by technical people, so try to stay simple, but
  2. Your work have to be read by technical people, for validation or application of your recommendations, so don't forget anything!! Your work must to be exact, comprehensive and incontestable.
  3. As your job concern security failure, making some obfuscation, like using John Doe:XXXXX for couple username, password may be a good practice, they have to be mentionned at intro, but this could be usefull for further discuss.

So for staying light for the administrative people, Introduction and Conclusion have to be explained in simple manner, maybe using pictural language, and

for staying light for technical people who have to work around your text, be exact and detailed. Maybe a simple console dump with some comments could be enough.

share|improve this answer

This may sound like a cop-out but it isn't, and that is to simply ask what format they like. I've performed all sorts of reviews and most companies have a format of what information they like and how they like it. Ask to see previous reports as a template, it will save you loads of time.

share|improve this answer
    
I have to disagree with you, while the company does have its own template for certain tasks, I believe a security audit report should have a more-or-less standard format. What if the company decided to hire a third-party to fix the problem? –  Adnan Jan 24 '13 at 16:37
    
@Adnan, as a third party which often does security assessments I can tell you that I always attempt to use the customer's report format. Maybe your company doesn't have one, but it is worth asking as you could save lots of time. –  GdD Jan 24 '13 at 16:41
    
I have to agree with this one. I understand @Adnan's objection, but the purpose for such a report is (or should be) to get the company to understand and fix problems - ASAP. Every company has a built-up corporate culture, and develops common ways of communicating. In good ones, the various business units all "speak the same language" which includes gradually adopting similar looking reports, similar looking memos, etc. If you want the company to quickly act, give it to them in the format they like, so they don't have to "translate" it into something they understand. –  David Stratton Jan 24 '13 at 17:58
    
That said, I also agree that there are some things that a report should always include. The "adapt to the business" is in how the information is presented, not what information is presented. –  David Stratton Jan 24 '13 at 18:01
    
Put that way, I'm now able to see both sides of this. Thanks David & GdD. –  Adnan Jan 24 '13 at 18:03

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.