Application Security Policy

March 2019 Contents 1 Purpose and Scope 2 2 Background 2 3 References 2 4 Policy 2

1. Purpose and Scope
   1. This application security policy defines the security framework and requirements for applications, notably web applications, within the organization’s production environment.
   2. This document also provides implementing controls and instructions for web application security, to include periodic vulnerability scans and other types of evaluations and assessments.
   3. This policy applies to all applications within the organization’ production environment, as well as administrators and users of these applications. This typically includes employees and contractors.
2. Background
   1. Application vulnerabilities typically account for the largest number of initial attack vectors after malware infections. As a result, it is important that applications are designed with security in mind, and that they are scanned and continuously monitored for malicious activity that could indicate a system compromise. Discovery and subsequent mitigation of application vulnerabilities will limit the organization’s attack surface, and ensures a baseline level of security across all systems.
   2. In addition to scanning guidance, this policy also defines technical requirements and procedures to ensure that applications are properly hardened in accordance with security best practices.
3. References
   1. Data Classification Policy
   2. OWASP Risk Rating Methodology
   3. OWASP Testing Guide
   4. OWASP Top Ten Project
4. Policy
   1. The organization must ensure that all applications it develops and/or acquires are securely configured and managed.
   2. The following security best practices must be considered and, if feasible, applied as a matter of the application’s security design:
      1. Data handled and managed by the application must be classified in accordance with the Data Classification Policy (reference (a)).
      2. If the application processes confidential information, a confidential record banner must be prominently displayed which highlights the type of confidential data being accessed (e.g., personally-identifiable information (PII), protected health information (PHI), etc.)
      3. Sensitive data, especially data specifically restricted by law or policy (e.g., social security numbers, passwords, and credit card data) should not be displayed in plaintext.
      4. Ensure that applications validate input properly and restrictively, allowing only those types of input that are known to be correct. Examples include, but are not limited to cross-site scripting, buffer overflow errors, and injection flaws.
      5. Ensure that applications execute proper error handling so that errors will not provide detailed system information to an unprivileged user, deny service, impair security mechanisms, or crash the system.
      6. Where possible, authorize access to applications by affiliation, membership or employment, rather than by individual. Provide an automated review of authorizations on a regular basis, where possible.
      7. Ensure that applications encrypt data at rest and in transit.
      8. Implement application logging to the extent practical. Retain logs of all users and access events for at least 14 days.
      9. Qualified peers conduct security reviews of code for all new or significantly modified applications; particularly, those that affect the collection, use, and/or display of confidential data. Document all actions taken.
      10. Implement a change management process for changes to existing software applications.
      11. Standard configuration of the application must be documented.
      12. Default passwords used within the application, such as for administrative control panels or integration with databases must be changed immediately upon installation.
      13. Applications must require complex passwords in accordance with current security best practices (at least 8 characters in length, combination of alphanumeric upper/lowercase characters and symbols).
      14. During development and testing, applications must not have access to live data.
   3. Where applications are acquired from a third party, such as a vendor:
      1. Only applications that are supported by an approved vendor shall be procured and used.
      2. Full support contracts must be arranged with the application vendor for full life-cycle support.
      3. No custom modifications may be applied to the application without confirmation that the vendor can continue to provide support.
      4. Updates, patches and configuration changes issued by the vendor shall be implemented as soon as possible.
      5. A full review of applications and licenses shall be completed at least annually, as part of regular software reviews.
   4. Web applications must be assessed according to the following criteria:
      1. New or major application releases must have a full assessment prior to approval of the change control documentation and/or release into the production environment.
      2. Third-party or acquired applications must have a full assessment prior to deployment.
      3. Software releases must have an appropriate assessment, as determined by the organization’s information security manager, with specific evaluation criteria based on the security risks inherent in the changes made to the application’s functionality and/or architecture.
      4. Emergency releases may forego security assessments and carry the assumed risk until a proper assessment can be conducted. Emergency releases must be approved by the Chief Information Officer or designee.
   5. Vulnerabilities that are discovered during application assessments must be mitigated based upon the following risk levels, which are based on the Open Web Application Security Project (OWASP) Risk Rating Methodology (reference (b)):
      1. High - issues categorized as high risk must be fixed immediately, otherwise alternate mitigation strategies must be implemented to limit exposure before deployment. Applications with high risk issues are subject to being taken off-line or denied release into the production environment.
      2. Medium - issues categorized as medium risk must be reviewed to determine specific items to be mitigated. Actions to implement mitigations must be scheduled. Applications with medium risk issue may be taken off-line or denied release into the production environment based on the number of issues; multiple issues may increase the risk to an unacceptable level. Issues may be fixed in patch releases unless better mitigation options are present.
      3. Low - issues categorized as low risk must be reviewed to determine specific items to be mitigated. Actions to implement mitigations must be scheduled.
   6. Testing is required to validate fixes and/or mitigation strategies for any security vulnerabilities classified as Medium risk or greater.
   7. The following security assessment types may be leveraged to perform an application security assessment:
      1. Full - comprised of tests for all known web application vulnerabilities using both automated and manual tools based on the OWASP Testing Guide (reference ©). A full assessment must leverage manual penetration testing techniques to validate discovered vulnerabilities to determine the overall risk of any and all discovered issues.
      2. Quick - consists of an automated scan of an application for, at a minimum, the OWASP Top Ten web application security risks (reference (d)).
      3. Targeted - verifies vulnerability remediation changes or new application functionality.
      4. To counter the risk of unauthorized access, the organization maintains a Data Center Security Policy (reference ©).
      5. Security requirements for the software development life cycle, including system development, acquisition and maintenance are defined in the Software Development Lifecycle Policy (reference (d)).
      6. Security requirements for handling information security incidents are defined in the Security Incident Response Policy (reference (e)).
      7. Disaster recovery and business continuity management policy is defined in the Disaster Recovery Policy (reference (f)).
      8. Requirements for information system availability and redundancy are defined in the System Availability Policy (reference (g)).