Details of the Application Security Testing Program

Overview

Any UC Berkeley application handling UC P4 data, including California State Law "Notice-Triggering" information, must pass an annual application security assessment to remain in compliance with the UC Berkeley Minimum Security Standard for Electronic Information (MSSEI).

The Application Security Testing Program (ASTP) performs application security assessments for campus applications as required by MSSEI 6.2.

Assessment standards are designed to reduce security risk for the campus in a manner that is reasonable and attainable for Resource Custodians and Resource Proprietors.

Process

An application security assessment is divided into the following ordered phases:

Phase	Activities	Estimated Time Required
Pre-engagement Interactions	Kick-off meeting via phone or in-person will be performed to discuss ASTP process and onboard the application owner Scheduling -- establish rough timelines for testing window and define scope	~30-60 min
Threat Modeling	Meeting between the Information Security Office (ISO) and application stakeholders Stakeholders for this meeting include: Functional owners that can help illustrate application use cases Technical personnel such as developers, system administrators, application administrators, and vendors if necessary Primarily a whiteboarding session to diagram the application, related systems, and data flow in order to identify high risk areas for testing Stakeholders will be questioned in detail about the application in attempt to "follow the UC P4"	~2-4 hours
Application Security Testing	Hands-on and automated testing of the application and related systems executed by the Information Security Office	~2-3 weeks
Report Generation	A comprehensive report is written and issued with the following sections: Executive Summary Application Grade Scope Findings Action Plan (remediation/mitigation plan)	~1 week
Assessment Debriefing	In-person meeting to discuss the report findings and remediation timelines Q&A session for any items in the report	~30-60 min
Application Re-testing	Hands-on re-testing to verify any fixes or mitigation of vulnerabilities in the application	Ongoing until issues are resolved, typically it is a fast process to verify fixes or mitigation

Methodology

Security Testing

Testing methodology is based upon the OWASP Testing Framework and A Web Application Hacker's Methodology.

Test coverage may include, but is not limited to the following areas:

Information Gathering & Reconnaissance
Authentication
Session Handling
Access Controls & Authorization
Data Input Validation
Application Logic
Application Hosting
Web Services
Desktop Client Software
Thick and Thin client components
Server Software

Web applications will be tested for each of the OWASP 2017 Top Ten Application Security Risks:

Injection
Broken Authentication & Session Management
Sensitive Data Exposure
XML External Entities (XXE)
Broken Access Control
Security Misconfiguration
Cross-Site Scripting (XSS)
Cross Site Request Forgery (CSRF)
Insecure Deserialization
Using Components with Known Vulnerabilities

Risk Rating

The risk of application security vulnerabilities discovered during an assessment will be rated according to a custom-tailored version the OWASP Risk Rating Methodology. Risk severity is determined based on the estimated technical and business impact of the vulnerability, and on the estimated likelihood of the vulnerability being exploited:

ASTP Risk Rating

Below is a table summarizing factors by which a vulnerability may be classified. Please note that only the most common vulnerability characteristics are listed, and these ratings do not completely account for your application's environment:

Severity Level	Characteristics
Critical	Exploits targeting this vulnerability are widely available and can be easily executed Exploitation leads to application and/or system compromise with super-user level privileges Exploitation leads to an immediate leak of UC P4 data
High	Exploits targeting this vulnerability are available and can be executed with minimal effort Exploitation leads to application and/or system compromise with remote user access Exploitation leads to an immediate leak of UC P2/P3 data or has the potential to indirectly lead to a leak of UC P4 data (formely UCB PL2/PL3)
Medium	Exploits targeting this vulnerability are available and can only be executed with specialized tools or additional access Exploitation leads to application and/or system compromise with remote user access Exploitation leads to an immediate leak of P2/P3 data or has the potential to indirectly lead to a leak of UC P2/P3 data
Low	Information on how to exploit this vulnerability is not publicly available Exploitation requires local or physical access Exploitation leads to a leak of application, host, or network information that may be used to find other vulnerabilities Exploitation has the potential to indirectly lead to a leak of UC P2/P3 data
Informational	Exploitation leads to a leak of non-sensitive information related to the application, host, or network

Application Grading

Applications undergoing an assessment receive a Pass or Fail grade based on their ability to adequately secure UC P4 data. A Fail grade is issued when an application contains vulnerabilities or exposures that when exploited, directly lead to a confidentiality breach of covered data.

The following vulnerabilities will result in an automatic Fail grade for any application:

Any Critical or High risk vulnerabilities as rated by the ASTP. These vulnerabilities are deemed to have a high likelihood of being found and exploited, and a high business impact for the university.
Multiple Medium or Low risk vulnerabilities that create a Critical or High risk when leveraged together by attackers.

Applications with a Fail grade must address all Critical and High risk vulnerabilities in a time frame agreed upon with the Information Security Office. Timely remediation is a campus requirement for the system to remain in operation.

Exception Requests

Applications that receive a Fail grade will be issued timeline requirements by which vulnerabilities must be fixed. Remediation due dates will be prioritized and issued by the Information Security Office based on risk. The due dates are presented under the Action Plan section at the end of the final ASTP report.

When remediation is complete, vulnerabilities causing the original Fail grade will be re-tested by the Information Security Office. If all pertinent vulnerabilities have been addressed, a Pass grade may be issued for the application.

If remediation due dates cannot be met or if there is a disagreement over the dates, Resource Proprietors and Resource Custodians of applications that receive a Fail grade may file an Exception Request with the Information Security Office (security@berkeley.edu) asking for additional time to complete remediation.

Frequently Asked Questions

Application Security Testing Program FAQs