Application Service Provider (ASP) Security Standards for Duke University
This document defines the minimum security criteria that an Application Service Provider (ASP) must meet in
order to be considered for use by Duke University to host an application. As part of the ASP selection process,
the ASP Vendor must demonstrate compliance with the Standards listed below by responding in writing to
EVERY statement and question in the six categories. The University IT Security Office (ITSO) will closely
review the vendor responses, and will suggest remediation measures in any areas that fall short of the minimum
security criteria. ITSO approval of any given ASP resides largely on the vendor's response to this document.
These Standards are subject to additions and changes without warning by ITSO.
This document can be provided to ASPs that are either being considered for use by Duke, or have already been
selected for use.
3.0 Responding to These Standards
ITSO is looking for explicitly detailed, technical responses to the following statements and questions. ASPs
should format their responses directly beneath the Standards (both questions and requirements) listed below. In
addition, please include any security whitepapers, technical documents, or policies that you may have. Answers
to each Guideline should be specific and avoid generalities, e.g.:
Bad: "We have hardened our hosts against attack."
Good: "We have applied all security patches for Windows 2000 as of 8/31/2000 to our servers. Our
Administrator is tasked with keeping up-to-date on current vulnerabilities that may affect our environment, and
our policy is to apply new patches during our maintenance period (2300hrs, Saturday) every week. Critical
updates are implemented within 24 hours. A complete list of applied patches is available to Duke."
Bad: "We use encryption."
Good: "All communications between our site and Duke will be protected by IPSec ESP Tunnel mode using
168-bit TripleDES encryption, SHA-1 authentication. We exchange authentication material via either out-of-
band shared secret, or PKI certificates."
4.1 General Security
1. Duke reserves the right to periodically audit the Duke application infrastructure to ensure compliance with
the ASP Policy and these Standards. Non-intrusive network audits (basic portscans, etc.) may be done
randomly, without prior notice. More intrusive network and physical audits may be conducted on site with 24
2. The ASP must provide a proposed architecture document that includes a full network diagram of the
Duke Application Environment, illustrating the relationship between the Environment and any other relevant
networks, with a full data flowchart that details where Duke data resides, the applications that manipulate it, and
the security thereof.
3. The ASP must be able to immediately disable all or part of the functionality of the application should a
security issue be identified.
4.2 Physical Security
1. The equipment hosting the application for Duke must be located in a physically secure facility, which
requires badge access at a minimum.
2. The infrastructure (hosts, network equipment, etc.) hosting the Duke application must be located in a locked
3. Duke shall have final say on who is authorized to enter any locked physical environment, as well as access
the Duke Application Infrastructure.
4. The ASP must disclose who amongst their personnel will have access to the environment hosting the
application for Duke.
5. Duke requires that the ASP disclose their ASP background check procedures and results prior to ITSO
granting approval for use of an ASP.
4.3 Network Security
1. The network hosting the application must be air-gapped from any other network or customer that the ASP
may have. This means the Duke application environment must use separate hosts, and separate infrastructure.
2. How will data travel between Duke and the ASP? Keep in mind the following two things:
a. If Duke will be connecting to the ASP via a private circuit (such as frame relay, etc.), then that circuit
must terminate on the Duke extranet, and the operation of that circuit will come under the procedures
and policies that govern Duke’s network partners.
b. If, on the other hand, the data between Duke and the ASP will go over a public network such as the
Internet, appropriate firewalling technology must be deployed by the ASP, and the traffic between Duke
and the ASP must be protected and authenticated by cryptographic technology (See Cryptography
3. Does the system use SSL or other form of encryption to connect? How is user session-state maintained? Is
state information on the client side encrypted? Are there protections in place to guard against replay attacks? Is
the session information validated on each client request? Is there a method for logging out? Is there an idle time
out? If so, how long?
4.4 Host Security
1. The ASP must disclose how and to what extent the hosts (Unix, NT, etc.) comprising the Duke application
infrastructure have been hardened against attack. If the ASP has hardening documentation for the Duke
application infrastructure, provide that as well.
2. The ASP must provide a listing of current patches on hosts, including host OS patches, web servers,
databases, and any other material application.
3. Information on how and when security patches will be applied must be provided. How does the ASP keep up
on security vulnerabilities, and what is the policy for applying security patches?
4. The ASP must disclose their processes for monitoring the integrity and availability of those hosts.
5. The ASP must provide information on their password policy for the Duke application infrastructure,
including minimum password length, password generation guidelines, and how often passwords are changed.
6. Duke cannot provide internal usernames/passwords for account generation, as the company is not
comfortable with internal passwords being in the hands of third parties. With that restriction, how will the ASP
authenticate users? (e.g., Kerberos, LDAP, Shibboleth, WebAuth, Client certificates.)
7. The ASP must provide information on the account generation, maintenance and termination process, for both
maintenance as well as user accounts. Include information as to how an account is created, how account
information is transmitted back to the user, and how accounts are terminated when no longer needed.
8. The ASP must confirm that group accounts are not used, that role-based authorization is used, and describe
how the authorization system restricts access.
9. What system and network events are logged? (e.g. normal system access, abnormal events, IP addresses for
such events, etc.) What facilities exist to alert operators to abnormal events? How long are logs kept? Is any
sensitive information stored in the logs?
4.5 Web Security
1. At Duke's discretion, the ASP may be required to disclose the specific configuration files for any web servers
and associated support functions (such as search engines or databases).
server page) technology.
3. What language is the application back-end written in? (C, Perl, Python, VBScript, etc.)
4. Please describe the ASP process for doing security Quality Assurance testing for the application. For
example, testing of authentication, authorization, and accounting functions, as well as any other activity
designed to validate the security architecture.
5. Has the ASP done web code review, including CGI, Java, etc, for the explicit purposes of finding and
remediating security vulnerabilities? If so, who did the review, what were the results, and what remediation
activity has taken place? If not, when is such an activity planned? Has the system met the industry standard
requirements for it's type? (e.g. Visa's CISP) How many security vulnerabilities have been found in the
software in the past year?
1. The Duke application infrastructure cannot utilize any "homegrown" cryptography – any symmetric,
asymmetric or hashing algorithm utilized by the Duke application infrastructure must utilize algorithms that
have been published and evaluated by the general cryptographic community.
2. Encryption algorithms must be of sufficient strength to equate to 168-bit TripleDES.
3. Preferred hashing functions are SHA-1 and MD-5.
4. Connections to the ASP utilizing the Internet must be protected using any of the following cryptographic
technologies: IPSec, SSL, SSH/SCP, PGP.
5. If the Duke application infrastructure requires PKI, please contact Duke’s University IT Security Office for
4.7 Data Stewardship
1. Will sensitive information be stored on or transmitted by the system? (“Sensitive information” is currently
defined in Appendix A, and in the future will be defined by the Duke University Information Classification
Framework, posted on http://security.duke.edu.) If so, which sensitive data elements will be stored or
2. Is the data in the application subject to any regulations or legislation (e.g. FERPA, HIPAA, the NC Identity
Theft Protection Act, or others)?
3. Does the system encrypt sensitive data on disk? What data is encrypted? What type of encryption is used?
4. Is sensitive data encrypted in transit? Between application tiers? Between server(s) and users? What data is
encrypted? What type of encryption is used?
5. Are database connections authenticated? Are database connections encrypted? Is access to the database
restricted in any manner? (e.g. by IP address, by username, etc.) What protections are in place to prevent
database password snooping? How long does it (generally) take the vendor to verify that it's application works
with a new version (or security release) of a database?
6. How is data ownership documented?
Last updated: March, 2009
Restricted and Sensitive data as defined by Duke University’s Human Resources department includes:
Social Security Number
Date of birth
Home telephone number
Places lived/Prior addresses
Employee and Occupational Health (EOHW) files
Personally-identifiable health information
Worker’s compensation claim
Worker’s compensation diagnosis
Worker’s compensation treatment
Driver’s license number
Personal Assistance Services (PAS) use
Number of dependents
Performance improvement plan
Harassment or discrimination claims
Reason for separation/termination
Health plan details
Benefit plan enrollment
Direct deposit information
Reference check data
FMLA or other LOA effective date
RIF information (including severance)
Number of exemptions
Additional exemption amounts
In the NC Identity Theft Protection Act of 2005, "personal information" is defined as a person's first name (or
first initial) AND last name, combined with any of the following:
Social Security number
Driver's license number, state id card number, or passport number
Checking or savings account numbers
Credit or debit card numbers
EINs, email names/addresses, "Internet account numbers" or "Internet identification names" (Duke Unique IDs
and Duke NetIDs may qualify)
Any other numbers or info that can be used to access financial resources
Biometric data, including fingerprints
Parent's legal name prior to marriage