Web Application Security Policy


This page talk about Web Application Security Policy for any university, it might helps you to protect your self in university live. 



Web Application Security Policy

Free Use Disclaimer: This policy was created by or for the SANS Institute for the Internet community. All or parts of this policy can be freely used for your organization. There is no prior approval required. If you would like to contribute a new policy or updated version of this policy, please send email to policy-resources@sans.org.

Things to Consider:  Please consult the Things to Consider FAQ for additional guidelines and suggestions for personalizing the SANS policies for your organization.
Last Update Status: Updated June 2014

1.     Overview

Web application vulnerabilities account for the largest portion of attack vectors outside of malware.   It is crucial that any web application be assessed for vulnerabilities and any vulnerabilities by remediated prior to production deployment.

2.     Purpose

The purpose of this policy is to define web application security assessments within  web application assessments are performed to identify potential or realized weaknesses as a result of inadvertent mis-configuration, weak authentication, insufficient error handling, sensitive information leakage, etc.  Discovery and subsequent mitigation of these issues will limit the attack surface of  services available both internally and externally as well as satisfy compliance with any relevant policies in place.

3.     Scope

This policy covers all web application security assessments requested by any individual, group or department for the purposes of maintaining the security posture, compliance, risk management, and change control of technologies use 

All web application security assessments will be performed by delegated security personnel either employed or contracted by All findings are considered confidential and are to be distributed to persons on a need to know basis.  Distribution of any findings outside  is strictly prohibited unless approved by the Chief Information Officer.

Any relationships within multi-tiered applications found during the scoping phase will be included in the assessment unless explicitly limited.  Limitations and subsequent justification will be documented prior to the start of the assessment.

4.     Policy

4.1 Web applications are subject to security assessments based on the following criteria:

a)     New or Major Application Release will be subject to a full assessment prior to approval of the change control documentation and/or release into the live environment.
b)    Third Party or Acquired Web Application will be subject to full assessment after which it will be bound to policy requirements.
c)     Point Releases will be subject to an appropriate assessment level based on the risk of the changes in the application functionality and/or architecture.
d)    Emergency Releases An emergency release will be allowed to forgo security assessments and carry the assumed risk until such time that a proper assessment can be carried out.  Emergency releases will be designated as such by the Chief Information Officer or an appropriate manager who has been delegated this authority.

4.2 All security issues that are discovered during assessments must be mitigated based upon the following risk levels. The Risk Levels are based on the OWASP Risk Rating Methodology. Remediation validation testing will be required to validate fix and/or mitigation strategies for any discovered issues of Medium risk level or greater.

a)     High Any high risk issue must be fixed immediately or other mitigation strategies must be put in place to limit exposure before deployment.  Applications with high risk issues are subject to being taken off-line or denied release into the live environment.
b)    Medium Medium risk issues should be reviewed to determine what is required to mitigate and scheduled accordingly.  Applications with medium risk issues may be taken off-line or denied release into the live environment based on the number of issues and if multiple issues increase the risk to an unacceptable level.  Issues should be fixed in a patch/point release unless other mitigation strategies will limit exposure.
c)     Low Issue should be reviewed to determine what is required to correct the issue and scheduled accordingly.


Reference and for more policies click on the link below: 




No comments:

Post a Comment