handle with care: you have my va report!
TRANSCRIPT
Handle With Care: You Have My VA Report!
OWASP Boston Application Security Conference
October 2016
Nivedita Murthy, Cigital Security Consultant
• 7+ years of AppSec and InfoSec experience.
• My area of expertise: vulnerability remediation.
• Connect with me on LinkedIn.
Who are you?
• Organization using application software?
• Product company delivering a software product?
Today, we will create a guideline that organizations can follow while reaching a consensus in terms of
the application assessments and findings.
Report StructureOWASP Guidelines on Reporting
Report Structure: Project Objectives
•Who did the security assessment?• Assessor details help organizations determine assessment
quality. Gartner Magic Quadrant
•What assessment was done?• DAST? SAST? Architecture Review? Threat Modeling? • Was it automated or manually conducted?• It depends.• Automated scan report may be sufficient. • If it is an application used throughout the enterprise or
involves sensitive information, manual review should follow-up the automated testing.
Report Structure: Project Schedule
•When was the last assessment conducted? • You can’t rely on a 5-year-old assessment. • Valid report should be no older than a year.
•What’s the duration of the assessment?• If it was only two days, did it cover all functionalities (depends
on the size of the application)?• It’s important to compare the application size and findings to
determine if the assessment duration is sufficient.
Report Structure: Targets
•What was the scope of the assessment?• It should list all domains, functionalities, modules, URLs,
and port numbers that were involved in the assessment.
•Did the assessment include application server and database testing?• What about outbound streams and APIs connecting to the
application?• It’s important to know where data is stored and if the
database and server are vulnerable.
•What’s the version?
Report Structure: Limitations
•Are there any modules, domains, and functionalities that weren’t part of the assessment’s scope?
•Due to time constraints, limited application availability, and access issues, were some modules not tested?
Report Structure: Findings Summary
A summary of critical, high, medium, and low vulnerabilities often gives executives insight into where to focus the security
budget. It doesn’t exactly comfort an organization to know the possible ways they may be attacked.
•What are the good points? • What flaws weren’t discovered?
•What if you’re from a product company? • Include vulnerability title and description, risk level,
module (without giving details on exact parameters and fields) in your report.
• To hide the details, mask it or delete it.
Report Structure: Appendix
•What methodology was used for testing? • List the tools and scripts used for testing.• Were SAST and/or DAST tools used to run automated
checks? • Did the assessor follow a specific checklist?• Which attacks were checked? • These questions help determine if the assessment meets
the organization’s standards.
•What was the risk rating model used during the assessment?• STRIDE? DREAD? CVSS? NIST 800-30 r1? • The matrix should be listed. This gives insight into how risk
levels were calculated.
Report Structure: Remediation Plan
•How will the discovered vulnerabilities be resolved?• The higher the criticality, the faster they need to be resolved.• Identify who will resolve the issues.
•What is the remediation timeline?• Provide a description on how the vulnerabilities will be
resolved. • Will they be applying framework-level controls?• Will they be conducting spot fixes? • Is the remediation relevant with current standards?
Report Sharing Methodologies
Report Sharing Methodologies
•Password-protected PDF over secure mail.• Password needs to be sent securely within a separate piece
of mail.• It’s up to the organization how to share the report internally. • This reduces distribution overhead from the product
company’s perspective.• Alternatively, the product company has no visibility into
how many people with whom the report was shared.
Report Sharing Methodologies
•Online hosting.• Host the report in a file hosting or storage site. • Allows for limited viewing (no download) access to other
members of the organization. • The product company has full control over who can view the
report and keep logs regarding when it was accessed, from where, and by whom.
• The product company has to maintain an externally-facing document sharing portal. • Ensuring availability. • Access approval.
Report Sharing Methodologies
•On-site visit.• The actual report will never be available to clients at their
discretion. • The product company has to bear the expenses of having
an organizational representative on-site to physically read it.
2 additional points to consider when
assessment information is shared.
1. Remediation and Re-testing
• The vendor may have committed dates by which they aim to resolve the identified vulnerabilities.
• Re-test needs to be conducted to ensure that these vulnerabilities have in fact been resolved.
• This requires a follow-up on the part of the organization.
2. Secure Development Practices
• Vulnerabilities get resolved.
• The organization needs to determine if there are steps or procedures in place to ensure that new issues don’t crop up in future releases.
• Check if vendor developers are trained in secure development practices.
• Check if they have any internal security testing practices.
Additional Resources
• Overcoming the 6 Most Common Threat Modeling Misconceptions
• How to Build Security Into Your Software Development Process
• Top 6 Application Security Hurdles and the Secret to Overcoming Them
