Purpose and Scope
This application security policy defines the security framework and requirements for applications associated with our Shuffl Service, notably web applications, within the organization’s production environment.
This document also provides implementing controls and instructions for web application security, to include periodic vulnerability scans and other types of evaluations and assessments.
This policy applies to all applications within the organization’ production environment, as well as administrators and users of these applications. This includes all partners, employees, consultants, and contractors.
Background
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.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.
References
Policy
Shuffl must ensure that all applications it develops and/or acquires are securely configured and managed.
The following security best practices must be considered and, if feasible, applied as a matter of the application’s security design:
Data handled and managed by the application must be classified in accordance with the Data Classification Policy (Reference 1).
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.)
As of current date, Shuffl does not process protected (PHI) data.
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.
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.
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.
Ensure that applications encrypt data at rest and in transit.
Implement application logging and monitoring to practical and logical extents.
Where possible, authorize access to applications by affiliation, membership or employment, rather than by individual.
Ensure that applications encrypt data at rest and in transit.
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).
Default passwords used within the application, such as for administrative control panels or integration with databases must be changed immediately upon installation.
During development and testing, applications must not have access to live data.
Where applications are acquired from a third party, such as a vendor or Personal Data is being processed by a third party (data processor):
Only applications that are supported by an approved vendor shall be procured and used.
Third parties must provide at least the same or higher level of protection for Personal Data as we do, to the extent applicable.
Contracts must be arranged with the application vendor for full life-cycle support.
Updates, patches and configuration changes issued by the vendor shall be implemented as soon as possible.
A full review of applications and licenses shall be completed at least annually, as part of regular software reviews.
Web applications must be assessed according to the following criteria:
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.
Third-party or acquired applications must have a full assessment prior to deployment.
Software releases must have an appropriate assessment, as determined by the organization’s Chief Technology Officer or Managing Partner, with specific evaluation criteria based on the security risks inherent in the changes made to the application’s functionality and/or architecture.
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 Technology Officer or designee.
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 2:
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.
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.
Low - issues categorized as low risk must be reviewed to determine specific items to be mitigated. Actions to implement mitigations must be scheduled.
Testing is required to validate fixes and/or mitigation strategies for any security vulnerabilities classified as Medium risk or greater.
The following security assessment types may be leveraged to perform an application security assessment:
Full - comprised of tests for all known web application vulnerabilities using both automated and manual tools based on the OWASP Testing Guide (Reference 3). A full assessment must leverage manual penetration testing techniques to validate discovered vulnerabilities to determine the overall risk of any and all discovered issues.
Quick - consists of an automated scan of an application for, at a minimum, the OWASP Top Ten web application security risks (Reference 4).
Targeted - verifies vulnerability remediation changes or new application functionality.
Security requirements for handling information security incidents are defined in the Security Incident Response Policy (Reference 5).
Disaster recovery and business continuity management policy is defined in the Disaster Recovery Policy (Reference 6).
Requirements for information system availability and redundancy are defined in the System Availability Policy (Reference 7).
Standard Controls Satisfied
TSC CC6.2