S000000251 Attachment 9 TSS DIS Securing Web Applications Policy.pdf

Policy Statement – Securing Web Applications Title: Securing Web Applications Policy Document Number:

Effective Date: 02/10/2022 Published by: Arkansas Department of Transformation and Shared Services, Division of Information Systems

1.0. Introduction

There is an intersection of cloud and web applications – cloud is becoming the preferred environment for business workloads, service-oriented/based/focused architecture the preferred model for deploying applications, and most services are consumed via web APIs. This increases the exposure of web applications and their security. Cloud environments can be managed by Web UIs (consoles), Command-Line Interfaces (CLIs), and programmatically with Software Development Kits (SDKs), all of which connect in the background to sophisticated web APIs.

1.1. Some factors which contribute to the difficulty in securing web applications are:

1.1.1. Complexity – there are scores of development languages and frameworks, methods for authentication and authorization, and databases used to support workloads.

1.1.2. Velocity – modern web applications are conceived, planned, developed and deployed exponentially faster. Often developers with little security training are graded on their speed of deployment with minimal value placed to security.

1.1.3. Exposure – most are exposed via the public internet and are unrestricted by design

1.2 Securing web applications requires discipline, knowledge, and resources. Due to the large attack surface, it is difficult to impossible to consistently manage security manually

– there must be vigilant and programmatic assessments of security requirements, specifically to address previously identified vulnerabilities from resurfacing. This practice is known as “Test-Driven Security” (TDS).

1.3 A test driven security use case where a company had an internal API which processed sensitive information and contained known vulnerability was restricted from public consumption using cloud firewalls known as Security Groups. The risks were accepted instead of corrected due to its limited exposure within a trusted perimeter.

While migrating and modifying environments, the security groups which restricted access to the vulnerability were changed, allowing public access. It was compromised within hours. A simple script could have been scheduled to run every day or even hourly to confirm whether it was not accessible from the Internet, alerting security teams if it became exposed.

2.0 Purpose

Addressing the OWASP Top Ten Application Security Risks.

https://owasp.org/Top10/

This is meant to be the bare minimum that must be done to secure a web application.

Direct from OWASP in the section How to use the OWASP Top Ten as a Security Standard, “The OWASP Top 10 is primarily an awareness document. However, this has not stopped organizations using it as a de facto industry AppSec standard since its inception in 2003. If you want to use the OWASP Top 10 as a coding or testing standard, know that it is the bare minimum and just a starting point.

3.0 Policy

3.1. Implementation

Implement the OWASP Top Ten Proactive Security Controls.

https://owasp.org/www-project-proactive-controls/

These are a higher level set of controls, which should be implemented for all web applications.

3.1.1. Establish readily available evidence of compliance with each control. The first control, C1: Define Security Requirements, references the OWASP Application Security Verification Standard (ASVS) https://owasp.org/www-project-application-security-verification-standard/ which is an invaluable document for understanding and testing applications. In addition, this requires extreme attention to contractual and regulatory requirements, especially sensitive information like Social Security Numbers (SSNs). Details of changes and regressions testing, including TDS should be readily available for review.

3.1.2. C9: Implement Security Logging and Monitoring is best satisfied by coordinating with security teams to ensure logging is appropriate and sufficient to investigate security events. For example, the sample logs I received in relation to the Arknet engagement lacked a common format, HTTP methods, HTTP responses and other fields. Alerting must be configured to limit false-positives, provide actionable information, and prevent “alert fatigue”. Logs must be secured, ideally integrated within a SIEM for advanced threat detection and response.

3.2. Adopt Security Framework(s). Frameworks and guidance documentation specific to incorporated technologies provide robust and thorough specifics, some of which would likely be overlooked.

https://owasp.org/Top10/ https://owasp.org/www-project-proactive-controls/ https://owasp.org/www-project-application-security-verification-standard/ https://owasp.org/www-project-application-security-verification-standard/

The OWASP Application Security Verification Standard (ASVS) can serve as a standard for applications.

The Center for Internet Security publishes several benchmarks (sets of security requirements) for cloud services, operating systems, and important applications such as Docker and Kubernetes. Cloud service providers such as AWS, Azure and Google provide security guidance and tools for securing cloud implementations. You must understand the cloud Shared Responsibility construct.

The Cloud Security Alliance provides extensive resources for securing cloud deployments. https://cloudsecurityalliance.org/ Resources include training and their Best Practices for Cloud Security.

3.3 Maintain Your Own Security Structure. All organizations’ security needs are unique, and require their own set of Policies, Standards, Guidance, Use-Cases and Procedures.

Often times, Policies and Standards are developed but the associated and required processes are not. Training and documentation must be readily available to all interested parties, and tools and methods must support Test Driven Security. Change control must be implemented and documented.

3.4. Train Developers in Secure Coding Practices. This is often skipped due to the significant time investment, but the time taken to train developers will pay off ten-fold in reduced bugs and development efficiency. Training usually covers the OWASP Top Ten, with emphasis on input validation, cross-site scripting (XSS) and cross-site request forgery (CSRF), authentication and authorization. Some training resources are:

3.4.1. https://www.hackedu.com/

3.4.2. https://sans.edu

3.4.3. https://knowbe4.com

3.4.4. https://www.securecodewarrior.com/

3.4.5. https://safecode.org/training/ (free)

3.5. Use Tools to Scan for Deficiencies. There are readily available free and commercial tools for testing security, and they should be leveraged where possible. Scanners are imperfect and must always be secondary to secure coding practices. Moving up the development stack, some categories of tools are:

3.5.1. Static Application Security Testing (SAST) – Security vulnerabilities in code are bugs. These utilities scan source code for security bugs and can even be integrated within Interactive Development Environments (IDEs). They can assist developers in making common mistakes and a case could be made that these provide the best value to an organization due to early detection and prevention of bugs. OWASP maintains a long list of both commercial and open-source/free tools https://owasp.org/www-community/Source_Code_Analysis_Tools , as does NIST https://www.nist.gov/itl/ssd/software-quality-group/source-code-security analyzers . Many are language specific. A few example tools:

https://cloudsecurityalliance.org/ https://www.hackedu.com/ https://sans.edu/ https://knowbe4.com/ https://www.securecodewarrior.com/ https://safecode.org/training/ https://owasp.org/www-community/Source_Code_Analysis_Tools https://www.nist.gov/itl/ssd/software-quality-group/source-code-security%20analyzers https://www.nist.gov/itl/ssd/software-quality-group/source-code-security%20analyzers

i. Fortify – commercial and covers a very large list of different languages

ii. Bandit – free/open-source scanner for Python

iii. SonarQube – free/open source and covers 15 languages

3.5.2. Dynamic Application Security Testing (DAST) – Intended to discover vulnerabilities in running applications, usually in staging or quality-assurance environments. Should ultimately be used to test production environments as well. Just like SAST, OWASP maintains a list of both commercial and free/open-source tools. A few examples:

Arachni – Free, lends itself to automation, but no longer supported Nessus – Commercial and very powerful Vega – Open-source and very new Zed Attack Proxy (ZAP) – Open-source

3.5.3. Penetration Tests/Web Application Security Assessments – Advanced tests conducted by skilled security practitioners on live applications which should mimic production as closely as possible. They are meant to identify errors in programming logic and other deficiencies scanners are not equipped to detect.

They are the most expensive to conduct, and their findings are almost always the most expensive to correct.

3.6. Access Control. Access control to resources, systems, and networks is must be maintained and limited to least privileged. This is critical to the overall security of data and your applications, but is difficult to manage well. Examples of bad practices include:

3.6.1. Using root accounts for managing cloud assets,

3.6.2. Assigning too many people admin rights

3.6.3. Assigning applications to use database accounts with excessive privileges

3.6.4. Failing to manage departures resulting in orphaned accounts.

Multi-factor Authentication (MFA) must be used for all privileged accounts, and while the initial incorporation of MFA may be daunting, once set up correctly it is relatively easy to maintain.

3.7. Data Management. In most cases, your most valuable asset is your data. Unauthorized access or the loss of your data is likely your biggest risk as well. Applying best practices to the following in regard to your data is necessary to reduce risks and hopefully data breaches:

3.7.1. Control access to your data (item 7 above)

3.7.2. Maintain a data inventory with data classification

3.7.3. Secure data at-rest using encryption whenever possible. Manage keys appropriately.

3.7.4. Reduce exposure – Truncating sensitive data in displays, limit collection and distribution.

3.7.5. Manage retention – Data cannot be exposed if it does not exist. Define your retention requirements and automatically purge data when not in use. If data must be retained but not immediately available, move to longer-term retention and encrypt. Consider de-identifying information, when possible, to reduce sensitivity.

3.7.6. Fully understand regulatory and contractual requirements and your obligations in regard to the data you process (collect, distribute, store and manage).

4.0 References

4.1. Arkansas Code Ann. Sections 25-4-105(a)(2)(M) and 25-4-105(a)(2)(0) give the Division of Information Systems the authority to define standards, policies, and specifications for state agencies and ensure agencies’ compliance with those policies, procedures, and standards. In addition, the Division develops information technology security policy for state agencies.

4.2. The State Cyber Security Office reserves the right to audit for compliance with this standard. Furthermore, the State Cyber Security Office has the right to grant an exception or exclusion to any part of this standard. The Arkansas Division of Legislative Audit also audits for compliance with this standard.

5.0 Definitions

5.1. “Application” means a separately identifiable and interrelated set of information technology resources that allows information processing to support specifically defined objectives.

5.2. “Customer” means a state agency, other governmental entity, or nongovernmental first responder entity that purchases or uses services under A.C.A. §§ 25-4-101, et seq.

5.3. “Information technology” means any component related to information processing and wired and wireless telecommunications, including data processing and telecommunications, hardware, software, services, planning, personnel, facilities, and training.

5.4. “State network” means The Arkansas State Network including the hardware, software, and services managed by the Division of Information Systems that make up a shared backbone for connecting state entities’ local area networks together and to the Internet.

6.0 Inquiries

Direct inquiries about this policy to:

Division of Information Systems State Cyber Security Office Little Rock, Arkansas 72201 Phone: 501-682-9437 Email: itpolicyteam@arkansas.gov DIS standards, policies and best practices can be found on the Internet at:

http://www.dis.arkansas.gov/policiesStandards/Pages/default.aspx mailto:itpolicyteam@arkansas.gov http://www.dis.arkansas.gov/policiesStandards/Pages/default.aspx