ASU Web Application Security Standard

Transcription

1 ASU Web Application Security Standard Spring 2014

2 2 1 PURPOSE This standard seeks to improve the security of ASU Web applications by addressing the following: Threat modeling and security testing Web application criticality and the associated review process Web application Sign- Off/Approval process 2 SCOPE This standard applies to all ASU web applications including: Web sites on ASU managed networks, including wireless Web sites that include asu.edu in their DNS hostname Web sites using Arizona State University s registered trademarks, service marks, word marks, or logos, including Arizona State University, ASU, seal, or athletic mascot Sparky (reference the communications guide: 3 DEFINITIONS The following are common terms that will occur throughout this document. Availability Rating Availability rating is a business-based classification, a rating that is based entirely on ASU s assessment of the importance of the site s availability for ASU s business continuity. Tier 1 - core web sites that are vital to all of ASU. This set of applications will be defined by the CIO and CISO in conjunction with ASU s executive leadership. Circumstances that could indicate a Tier 1 rating include: ASU cannot do business if this web site is down. Many other ASU systems rely on this web site being available. Tier 1 examples include enterprise student learning management systems, payroll systems, student administration systems, the ASU home page, , and authentication systems to support these systems. Tier 2 - enterprise-wide systems relied upon by most students or employees such as MyASU, and other online learning systems used in for-credit classes. Tier 3 sites including department-specific applications and all other applications. Centralized A centralized Web application is a Web application that is developed, hosted, and managed within the University Technology Office (UTO). These applications may have been developed at the request of an external source. Core Application Security Review team This team is organized by the Information Security Office and is convened to review criticality application ratings. The team typically includes members of the Information Security Office, UTO application development, UTO operations and members of the University s decentralized development community as appropriate. Criticality Rating The criticality rating is the overall web site rating which combines both the data rating and the availability rating to determine an overall rating. See the table in section 4.2 for an example.

3 3 Data Rating Data Rating is the rating of a web site based on the data included on the site in accordance with ASU s Data Handling Standard. Web site data rating is determined by the data classification as follows: If a web site has access to Highly Sensitive data or can modify Sensitive or Highly Sensitive data at the authoritative source, the site s data rating is High. If a web site has access to Sensitive data but is not rated high, the site s data rating is Medium. If a web site has access to Internal data, but not Sensitive or Highly Sensitive data, the site s data rating is Medium-Low. The expectation is that this rating (or higher) applies to all sites that are protected by passwords or other forms of authentication. If a web site has no access to data other than Public data, the site s data rating is Low. These sites do not prompt for a password or use other types of authentication. Decentralized A decentralized Web application is a Web application that is owned, developed, hosted, or managed through individual departments or units at ASU and is not centrally coordinated by UTO. Financial Applications The ASU financial applications are defined as the ASU Advantage system and specific modules within the Oracle/PeopleSoft Student Administration System and HR/Payroll System as defined and reviewed in the 2008 Auditor General Financial Audit. All of these systems except Advantage are Web applications. Legitimate purpose A web site on ASU s network should further some aspect of the University s mission, such as providing education or services to students, supporting funded research projects, or enabling University business administrative functions. Official Scan An official scan is a scan that has been performed by a member of the Web Scanning Team. The Web Scanning Team is composed of the following two groups: UTO Operations Information Security Office These groups provide the service of conducting official scans on Centralized Web Applications, Decentralized Web Applications and Hosted Web Applications in the production and QA environments. Decentralized departments may be approved to conduct their own official scans provided that the tool that will be utilized is comparable to the current, University-designated scanning tool and the request is approved by the Information Security Office. Production Instance The production instance of a web site is the one that is intended to be available for business use. QA Instance The QA (Quality Assurance) instance of a web site is intended for final testing before a new web site or significant change is released to the production instance. It is expected that the QA site will be as identical to the current or proposed production site as possible, with the exception that the QA site uses test data. Also, a QA site is expected to deliver test communications, including , to test users. Security Testing Security testing seeks to uncover any vulnerabilities that were previously unseen and confirm that mitigation plans and strategies have been successful. Significant Change A significant change is any change, including a code fix, that creates or alters executable code, whether the code runs on a server, a Web browser, or elsewhere. A cosmetic change, including changes in text, formatting, or color is typically not considered significant for the purposes of this definition.

4 4 Steward An ASU employee who is responsible for a web site on ASU s network from a business perspective, and who ensures that the site exists for a legitimate purpose and meets ASU s security requirements. Technical Administrator An ASU employee or contracted third party with the skill and availability to maintain a web site, including timely and effective response to security issues. The Technical Administrator is the lead technician for a web site, and could also serve in the role of lead developer or system administrator. Threat Modeling Threat modeling is a process to identify potential risks in an application and potential steps to mitigate those risks. URL Path The URL Path is the portion of the URL before the? and query string, or before the # and fragment identifier. If neither the? or # are present, the URL Path is the entire URL. Web Application A Web application is any Web site that uses server side logic to determine what information is sent to the user s Internet browser based on data from a database or a Web service. A site with a URL that receives data from a form typically includes server side logic to process that data, and is considered a web application. Web Site A Web Site is a collection of one or more URLs that respond to requests using the hypertext transfer protocol. A typical web site will have a starting URL that provides links allowing authorized users to navigate, directly or indirectly, to the other URLs available on the site. Many web sites reside entirely on a single web server or even within a single subdirectory on a web server. 4 STANDARD ASU has a broad set of security standards for web applications including security testing, the Web application criticality review and governance process, and the Web application sign-off/approval process. All ASU web sites should have: A legitimate purpose, An identified steward from the appropriate department, A technical administrator, Reasonable security measures in place. Sites that do not meet these criteria may be removed from ASU s network. ASU maintains a web application inventory that is modified as applications are added or decommissioned and reviewed periodically. Stewards, technical administrators and developers should be clearly identified by department heads and updated as staffing or functional roles are changed. Web site stewards or technical administrators should ensure that their applications are accurately reflected in the web app inventory. 4.1 Security Testing All web sites should undergo security testing commensurate with their criticality ratings and any risk a security breach may pose to the site or to other ASU systems. Every URL Path should be tested. If it accepts parameters through a query string or HTTP POST, the URL Path should be tested with a representative sample of valid, invalid, and potentially malicious parameters. Testing may be automated or manual but there are many advantages to automated testing including lower labor costs. Manual testing should be at least as thorough as automated testing would be. An example of automated testing is running a web scanning tool that is designed to test for a broad spectrum of potential security risks.

5 Potential security risks include: * Risks identified by industry security standards such as the Top Ten Web Application Vulnerabilities identified by the Open Web Application Security Project (OWASP). * If it is possible for a web browser, hacker, or user to send requests that cause a web server to crash, hang, or otherwise stop providing service. * If a web site accepts and stores data or other changes that are harmful to the database or to other users of the site. * If there is no way to audit or recover from malicious changes to data. * If a web page can be abused to send SPAM or other excess volumes of . * If a web page deliberately or inadvertently prevents scanners or penetration testers from effectively testing the page. * Other risks as identified by business rules or the project team. If an issue is not assigned a severity by a scanning tool or an external penetration testing firm, by default the issue severity is "Medium". Security testing should commence: 5 Before the launch of a new web site Before a significant change to a web site Upon request from the CIO, CISO, scanning team, sponsors, technical administrators, or developers of a web site When there are security concerns including active threats, security events or security incidents 4.2 Security Testing Routine Maintenance Schedule Ongoing testing should occur throughout the life of an application. The minimum scanning schedule includes: Criticality Data Rating Availability Rating High High - Highly or Sensitive/Sensitive data (Update authoritative source) Tier 1 - Mission Critical Medium Medium Sensitive data or Tier 2 - Enterprise Applications Medium- Low Medium-Low Internal data and Tier 3 - All other Low Low Public data and Tier 3 - All other Scanning Schedule Every 6 months Once a year Periodic Periodic The Web Scanning Team should select web sites for scanning according to the schedule above. For sites with a data rating of Medium-Low or Low and an availability rating of Tier 3, the Web Scanning Team should randomly select and scan sites on a regular basis. If a selected web site cannot be scanned, the required security testing should be conducted through other tools or handled manually. If a production site is not able to be scanned, a QA instance that meets the definition of a QA instance from the ASU Web Application Security Standard or a clone of the production site should be scanned or manually tested. If a web site is hosted by a third party service provider, (not hosted on ASU s network), an automated or manual test should be coordinated with the third party service provider. The results of the scan should be submitted to InfoSec@asu.edu upon completion.

6 4.3 Threat Modeling and Security Testing 6 All new Web applications or significant changes to an existing Web application should use a set of threat modeling procedures during development and require security testing prior to a production migration. For a Web application with a Criticality rating of High, security testing should include an official scan or third party penetration test. For medium Criticality Web applications, an official scan is highly recommended. A Web application rated Medium-Low or Low may use scanning as the means of security testing or its documented security testing plan. Packaged applications, while still requiring security testing, may have modified security testing requirements. An example is Web applications where the architecture inherently protects the application from potential security risks and generally do not require official scanning as part of the security testing process. See the Web Application Security Testing Guidelines for details about scanning. Web applications should pass security testing, preferably in a QA environment, before being released to production. All threat modeling and security testing should include a documented plan describing the tests that were performed and the results of those tests. The procedures for these development steps will be identified by the development groups to include their products and/or project teams. See the Web Application Security Testing Guidelines for more details regarding suggested threat modeling and security testing procedures. The Information Security Office will approve procedures by using standard security guidelines, such as the OWASP Top 10 Vulnerabilities, as a baseline for approval. Development groups, project and/or product teams are responsible for submitting new or altered security procedures as required by the Information Security Office. Details on Threat Modeling and Security Testing should be submitted to InfoSec@asu.edu. 4.4 Web Application Criticality and Availability Review Process Initial classification Applications are initially classified by the Technical Administrators or responsible developers. Those who participate in the creation or support of an ASU Web application should perform an initial self-evaluation and propose an initial data and availability classification based on this document. Criticality rating of new applications should be recommended prior to the scheduled go-live date Classification Review The Core Application Security Review Team is to act as an oversight committee for the periodic review of Web application criticality, updating classifications as necessary. The Core Application Security Review Team should include the appropriate decentralized development community members during the classification review of decentralized Web application to ensure that proper classification occurs. A Web application should be reviewed and updated off cycle if its Data Classification changes due to a code migration or if there are changes in the criteria documented in this standard. The review would typically be initiated by the project team, or technical administrator. 4.5 Web Application Sign-Off / Approval For all High Criticality Web applications or any financial Web application, proper development documentation and approval steps are required during the sign-off/approval process prior to migrating new Web applications or significant changes to the production environment. Technical approvals should include the necessary level of security testing as described in Section Threat Modeling and Security Testing of this standard, and all issues identified by security testing and not classified as low risk should be addressed.

7 The documentation requirements for financial applications consist of the following items: 7 A user request Functional specification Test plan with results Functional approval Technical approval For High Criticality applications that are not financial applications the documentation requirements are: Functional approval Technical approval For all other Web applications a functional and technical review and approval process is recommended. 4.6 Scanning During Critical Processing Freeze Since a scan does not change a web application, it may be scanned during university-wide critical processing periods. However, High criticality and Tier 1 web applications should not be scanned in production during times that would impact business continuity, for example, the semester startup period, which typically consists of the first two weeks of the fall or spring semesters. Application scanning should also take other critical processing periods into account prior to the launch of a scan. 4.7 Responsibility for Security Issues A web site's steward has primary responsibility for the security of the web site. This includes the responsibility to timely address all security issues within a reasonable time. Suggested workflows and timelines for addressing discovered issues can be found in the Web Application Security Testing Guidelines. Teams may adopt these guidelines, or develop their own. (See Section 5.) Unless a team has established its own guidelines, approved by ISO, the Web Application Security Testing Guidelines apply. When a web site is developed and/or hosted by a third party, to avoid a conflict of interest an independent entity should evaluate the third party's work. The independent entity may be an ASU employee or a separate third party. This separate evaluation should be submitted to InfoSec@asu.edu. 5 GUIDELINES Project or product teams may define procedures to implement the standards above. Such procedures should be submitted for approval to the Information Security Office, who in turn will review supplied procedures periodically. Web Application Security Testing Guidelines can be used as a reference for departments and teams to establish their own procedures. 6 ENFORCEMENT If a Web application does not comply with this standard and a waiver or extension has not been granted, the Information Security Office may escalate the matter through the appropriate management channels up to the executive level. Furthermore, applications may be shut down until the matter is resolved. Violations of this standard may lead to disciplinary actions. In some circumstances, compliance may not be immediately possible. Under those circumstances, academic or business units should confer with the Information Security Office to develop a plan for moving into compliance with this standard within a reasonable amount of time.

8 If a department or entity does not agree with this standard, a formal document should be submitted to the Information Security Office via infosec@asu.edu describing the concern. The concern or issue will be raised to the executive level for resolution. 8 7 STANDARD REVISION This standard is subject to review and revision at the direction and approval of the Chief Information Security Officer. To offer suggestions and/or recommendations, contact the Information Security Office at infosec@asu.edu.