If you’re reading this blog, Web security testing is undoubtedly on your radar. You may have an ongoing process for testing Web vulnerabilities but do you actually have a policy for it? I’m all about keep things simple with security and, when you think about it, adding more documentation, more rules, and more process often creates more complexity – especially if it’s all managed incorrectly. The reality is with today’s compliance regulations, customer and business partner demands, and information systems complexities you really do need some formal documentation – specifically, a security policy – governing your Web security testing program.
Security policies state nothing more than “This how we do things around here”. They help set everyone’s expectations, ensure things get done, and – most importantly – hold people accountable. Whether you have an existing Web security testing policy or you need to create a new one, it’s good to have a formal structure to the document that clearly conveys the right information. The following security policy template can do just that:
Introduction: An overview of what the policy covers such as vulnerability testing for all Web-based production systems.
Purpose: The high-level goals of the policy such as ensuring application vulnerabilities are analyzed on a periodic and consistent basis in order to minimize business risks.
Scope: The sites/applications, business units, etc. that are covered or affected.
Exceptions: The sites/applications, business units, etc. that are exempt from the policy such as non-Internet facing systems, non-business-critical applications, test environments, and so on.
Roles and responsibilities: The team members involved such as developers, QA, IT staff along with what’s expected of them when implementing and enforcing the policy such as specific methods to follow, reporting requirements, remediation follow-up, and so on.
Policy: Your actual policy statement such as: Web security vulnerability assessments are performed on a quarterly basis (external systems) and bi-annual basis (internal systems) or before any new code releases or upgrades in the Web server software or operating system(s).
Procedures: Detailed steps on carrying out the policy such as running automated vulnerability scans using Acunetix Web Vulnerability Scanner from both an untrusted outsider’s perspective as well as an authenticated user’s perspective (all role levels), manual validation of vulnerabilities discovered by the scanner, and manual analysis of the application for additional weaknesses the scanner cannot uncover.
Compliance metrics: The steps that will be taken to ensure the policy is working and everything is in check such as internal audit spot checks, quarterly and bi-annual reports to management, and/or annual validation by a third party.
Review and evaluation: The specific timelines for reviewing and updating the policy for accuracy, applicability, and so on such as once per year or after any gaps or deficiencies in the Web security testing process are discovered.
Sanctions: Specific consequences for policy violations, such as, This will happen on the first offense, that for second offense, and so on.
References: Laws, regulations, and frameworks, such as HIPAA, HITECH Act, PCI DSS, FFIEC, OWASP Top 10 for 2010, and so on.
Related documents: Other standards, policies, and documentation pertaining to the policy such as your SDLC documentation, security standards document, annual audit report on internal controls, and so on.
Revisions: Ongoing changes made to the policy document such as who, what, when, where, how, and why.
Notes: Notes, lessons learned, and so on in support of future policy management and enforcement.
There are two final points regarding security policies: 1) you may have a niche policy such as this that focuses solely on Web security testing or you may elect to broaden the scope to include all of your information systems. There’s no right or wrong way to do this – just do what’s best in the context of your business and 2) do what you can do convey the message to management that just because a policy exists doesn’t mean that everything is in check and secure. Web security is so much more than that.
Get the latest content on web security
in your inbox each week.
THE AUTHOR
