Application Security Policy

2025.1

Reviewed: 12/02/2024
Updated: 12/02/2024

Purpose and Scope:

1. This application security policy defines the security framework and requirements for all 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's production environment, as well as administrators and users of these applications; this typically includes employees and contractors.

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 ensure 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.

Appendix A: References

Data Classification Policy OWASP Risk Rating OWASP Testing Guide OWASP Top Ten Risk Cloud Storage and BYOD Policy SDLC policy Incident Response Policy Disaster Recovery Policy System Availability Policy

Controls and Procedures

Application Security Policy

1. The organization must ensure that all applications it develops and/or acquires are securely coded, 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:
   a. Data handled and managed by the application must be classified in accordance with the Data Classification Policy (reference (A)).
   b. Sensitive data (e.g., passwords) should not be displayed in plaintext.
   c. Ensure that applications validate input properly and restrictively, allowing only those types of input that are known to be correct (e.g. cross-site scripting, buffer overflow errors, injection flaws, etc.)
   d. Ensure that applications execute proper error handling so that errors will not provide detailed system information to an unprivileged user, deny service, or impair security mechanisms.
   e. 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.
   f. Ensure that applications encrypt data at rest and in transit.
   g. Implement application logging to the extent practical. Retain logs of all users and access events for at least 30 days.
   h. 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.
   i. Implement a change management process for changes to existing software applications.
   j. Standard configuration of the application must be documented.
   k. Default passwords used within the application, such as for administrative control panels or integration with databases must be changed immediately upon installation.
   l. 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).
   m. During development and testing, applications must not have access to live data.
   n. Access to production level data must be secured behind accounts with mandatory multi-factor authentication.
   o. Vulnerability scanning must be completed with each developmental version deployment.
3. Where applications are acquired from a third party, such as a vendor:
   a. Only applications that are supported by an approved vendor shall be procured and used.
   b. Full support contracts must be arranged with the application vendor for full life-cycle support.
   c. No custom modifications may be applied to the application without confirmation that the vendor can continue to provide support.
   d. Updates, patches and configuration changes issued by the vendor shall be implemented as soon as possible after testing in a non-production environment.
   e. 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:
   a. 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.
   b.Vulnerability scanning must be completed with each production version release.
   
   • Should a production release not occur within a quarter, a vulnerability assessment must be completed quarterly apart from a version release.
     c. Annual third party penetration tests must be completed on at least an annual cadence.
     d. Third-party or acquired applications must have a full assessment prior to deployment.
     e. Software releases must have an appropriate assessment, as determined by the organization's Information Security Manager (ISM) as defined within the Security Incident Response Policy, with specific evaluation criteria based on the security risks inherent in the changes made to the application's functionality and/or architecture.
     f. 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 VP of Product and Technology 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)):
   a. 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.
   b. 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 issues 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.
   c. 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:
   a. Full - composed of tests for all known web application vulnerabilities using both automated and manual tools based on the OWASP Testing Guide (reference (C)). A full assessment must leverage manual penetration testing techniques to validate discovered vulnerabilities to determine the overall risk of any and all discovered issues.
   b. Quick - consists of an automated scan of an application for, at a minimum, the OWASP Top Ten web application security risks (reference (D)).
   c. Targeted - verifies vulnerability remediation changes or new application functionality.
   d. To counter the risk of unauthorized access, the organization maintains a Data Center Security Policy (reference (E)).
   e. Security requirements for the software development life cycle, including system development, acquisition and maintenance are defined in the Software Development Lifecycle Policy (reference (F)).
   f. Security requirements for handling information security incidents are defined in the Security Incident Response Policy (reference (G)).
   g. Disaster recovery and business continuity management policy is defined in the Disaster Recovery Policy (reference (H)).
   h. Requirements for information system availability and redundancy are defined in the System Availability Policy (reference (I)).
8. The application will be protected by a combinations of AWS services:
   a. AWS WAF
   b. AWS Cloudfront
   c. AWS Shield/Route 53

Service Accounts

1. All application to application communication using service accounts is restricted and not permitted unless absolutely needed. Automated tools are used to limit account access across applications and systems.
2. Services that are part of IMPLAN platform leverage AWS IAM policy configurations and/or OAuth for authorization.
3. Generic accounts are not allowed on IMPLAN systems.
4. Direct system to system, system to application, and application to application authentication and authorization are limited and controlled to restrict access.
5. In AWS, service accounts are implemented in the form of IAM Roles, and their access defined by the corresponding IAM policies.
6. An inventory of all Service accounts is maintained by AWS IAM reviewed periodically.

Firewall Protection

Firewall protection is implemented at the following layers

• Network - including Network ACL and Security Groups in AWS as well as on- premise firewalls between the office networks and the Internet.

• Host - local firewalls are enabled on the user endpoints as well as servers (compute and database instances in AWS are protected by security groups)

• Application - web application firewall (WAF) and content distribution are configured at the application layer to protect against common web application attacks such as cross site scripting, injection and denial-of-service attacks.