Web Application Security Policy

1. Overview

Web application vulnerabilities account for the largest portion of attack vectors outside of malware.   Any web application must be assessed for vulnerabilities, and any vulnerabilities must be remediated before production deployment.

2. Purpose

The purpose of this policy is to define web application security assessments within eCuras. Web application assessments are performed to identify potential or realized weaknesses resulting from inadvertent misconfiguration, weak authentication, insufficient error handling, sensitive information leakage, etc.  Discovery and subsequent mitigation of these issues will limit the attack surface of eCuras 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 to maintain the security posture, compliance, risk management, and change control of technologies in use at eCuras.

All web application security assessments will be performed by delegated security personnel either employed or contracted by eCuras.   All findings are considered confidential and distributed to persons on a “need to know” basis.  Distribution of any findings outside of eCuras 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 before the start of the assessment.

4. Policy

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

  1. New or Major Application Release – will be subject to a full assessment before the approval of the change control documentation and/or release into the live environment.
  2. Third Party or Acquired Web Application – will be subject to full assessment, after which it will be bound to policy requirements.
  3. Point Releases – will be subject to an appropriate assessment level based on the risk of the application functionality and/or architecture changes.
  4. Patch Releases – will be subject to an appropriate assessment level based on the risk of the changes to the application functionality and/or architecture.
  5. 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 by the Chief Information Officer or an appropriate manager delegated this authority.

4.2 All security issues that are discovered during assessments must be mitigated based upon the following risk levels. 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 more significant.

  1. 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 matters are subject to being taken off-line or denied release into the live environment.
  2. 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.
  3. Low – Issue should be reviewed to determine what is required to correct the issue and scheduled accordingly.

4.3 The following security assessment levels shall be established by the InfoSec organization or other designated organizations performing the assessments.

  1. Full – A full assessment consists of tests for all known web application vulnerabilities using both automated and manual tools based on the OWASP Testing Guide.  A full assessment will use manual penetration testing techniques to validate discovered vulnerabilities to determine the overall risk of any and all discovered.
  2. Quick – A quick assessment will consist of a (typically) automated scan of an application for the OWASP Top Ten web application security risks at a minimum.
  3. Targeted – A targeted assessment is performed to verify vulnerability remediation changes or new application functionality.

Other tools and/or techniques may be used depending upon what is found in the default assessment. The need to determine validity and risk is subject to the discretion of the Security Engineering team.

5. Policy Compliance

5.1  Compliance Measurement

The Infosec team will verify compliance with this policy through various methods, including but not limited to periodic walk-thrus, video monitoring, business tool reports, internal and external audits, and feedback to the policy owner.

5.2  Exceptions

The Infosec team must approve any exception to the policy in advance.

5.3  Non-Compliance

An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.

Web application assessments are a requirement of the change control process and must adhere to this policy unless found to be exempt.   All application releases must pass through the change control process.  Any web applications that do not comply with this policy may be taken offline until such time that a formal assessment can be performed at the Chief Information Officer’s discretion.

6. Related Standards, Policies, and Processes

Revised: March 14th, 2018

Table of Content

  1. Acceptable Encryption Policy
  2. Acceptable Use Policy
  3. Clean Desc Policy
  4. Data Breach Response Policy
  5. Disaster Recovery Plan Policy
  6. Digital Signature Acceptance Policy
  7. Email Policy
  8. Ethics Policy
  9. Pandemic Response Planning Policy
  10. Password Construction Guidelines
  11. Password Protection Policy
  12. Security Response Plan Policy
  13. End User Encryption Key Protection Policy
  14. Acquisition Assessment Policy
  15. Bluetooth Baseline Requirements Policy
  16. Remote Access Policy
  17. Remote Access Tools Policy
  18. Router and Switch Security Policy
  19. Wireless Communication Policy
  20. Wireless Communication Standard
  21. Database Credentials Policy
  22. Technology Equipment Disposal Policy
  23. Information Logging Standard
  24. Lab Security Policy
  25. Server Security Policy 
  26. Software Installation Policy
  27. Workstation Security (For HIPAA) Policy
  28. Web Application Security Policy
  29.  Analog/ISDN Line Security Policy
  30. Anti-Virus Guidelines
  31. Server Audit Policy
  32. Automatically Forwarded Email Policy
  33. Communications Equipment Policy
  34. Dial In Access Policy
  35. Extranet Policy
  36. Internet DMZ Equipment Policy
  37. Internet Usage Policy
  38. Mobile Device Encryption Policy
  39. Personal Communication Devices and Voicemail Policy
  40. Removable Media Policy
  41. Risk Assessment Policy
  42. Server Malware Protection Policy
  43. Social Engineering Awareness Policy
  44. DMZ Lab Security Policy
  45. Email Retention Policy
  46. Employee Internet Use Monitoring and Filtering Policy
  47. Lab Anti Virus Policy
  48. Mobile Employee Endpoint Responsibility Policy
  49. Remote Access Mobile Computing Storage
  50. Virtual Private Network Policy