Skip navigation

STANFORD UNIVERSITY

INTERNAL AUDIT & INSTITUTIONAL COMPLIANCE

Information Security Guidelines for Outsourced Technology Solutions

Overall Perspective

Over the past decade, Stanford has embarked on a course of migrating the University’s administrative applications from mainframe proprietary systems to a large variety of commercial and custom systems.  Stanford has implemented several vendor-developed information systems, both within and external to the University’s central IT organizations Administrative Systems and IT Services. The scope of these projects ranges from University-wide ERP applications to departmental solutions. The increasing array and complexity of technological solutions to support the vast myriad of Stanford’s administrative functions has created a marketplace of specialized systems available to the University’s departments and schools, as well as its central IT organizations. Many of these niche market solutions require unique expertise and knowledge of the functional business requirements and the specific application.

The current economic climate and limited University system development resources have led to an increasing reliance on outsourced solutions to augment the University’s system and application implementation efforts. The increased complexity and specialization of the applications and systems required to meet the University’s business needs further points to the use of outsourced solutions. Many of these new applications contain restrictive, sensitive and private information, which the University needs to protect, and University managers are required to ensure that all solutions properly mitigitate information security risks, regardless of physical location of the solution.

  • Examples of ASP Solutions at Stanford include:
    • The University’s Undergraduate and Graduate ApplyYourself student application submission,
    • DAPER’s Paciolan Ticket Office application,
    • Student Financial Services’ ePay Payment System, and
    • Verisign Pay-Flow Link, electronic payment processing.
  • Examples of outsourced system development projects are:
    • Administrative Systems' PeopleSoft & Oracle Financials ERP applications
    • Facilities’ FAMIS, facilities management system, and
    • Research Compliance’s eProtocol system.
When IT functions are outsourced, through either ASP or custom developed solutions, Stanford may lose its ability to ensure tight controls over the production and development environments and the information contained in these systems. In addition, many of these external systems require connectivity or interfaces to other Stanford systems. These factors increase the risk of potentially embarrassing and costly violations of laws and regulations regarding the privacy and security of data, particularly when Prohibited or Restricted Data is involved.

The outsourcing of IT development activities to international markets, commonly known as off-shoring, introduces additional risks to Stanford’s sensitive information assets. The United States’ information privacy laws and regulations do not extend across international borders. This leaves Stanford with little recourse to recoup costs due to violations of information privacy and security laws and regulations, except the limited liability afforded by contractual agreements with the off-shore vendor. The greater the distance to the geographic location of the outsourced IT functions, the ability of Stanford to monitor the existence of appropriate information security controls decreases and the costs to monitor outsourced activities increases.

Best industry practice in such situations involves implementing strong controls on information used in development environments, either by creation of simulated data or by de-identifying Prohibited, Restricted and Sensitive data.

For additional information, see http://securecomputing.stanford.edu

<top>

Information Security Requirements

Stanford is committed to protecting its information resources from accidental or intentional intrusion or damage and is equally committed to preserving and nurturing the open, information-sharing requirements of its academic culture. Protecting information assets is driven by a variety of considerations including legal, academic, financial and other business requirements.

  • Legal - There are laws, both federal (e.g., HIPAA, FERPA, GLBA) and state (e.g., social security number use, credit card exposure), that affect the level of protection Stanford is required to provide. Stanford also has many contractual relationships around the protection of data that is licensed from other sources.
  • Academic - Stanford both produces and owns intellectual capital, which needs to be protected against premature disclosure, or unauthorized tampering.
  • Financial - There are costs directly related to the protection of information assets. Similarly, there are costs directly related to the control and repair of damage to information resources that have been compromised.
  • Other business requirements - While Stanford, as a part of its fundamental mission, wants to make sure that many information resources are widely available it also wants to keep private things private. Moreover, in addition to the direct costs related to damage control, Stanford's reputation as a world-class institution is something that, if damaged, can have both direct and indirect costs.

<top>

Relevant University Policies

University Management has established security policies and procedures to safeguard essential Stanford services, protect the privacy of students, faculty and staff, and comply with contractual requirements and legislation. The relevant Administrative Guide Memos are:

  • Administrative Guide Memo #61, Administrative Computing Systems, the University designated the central IT organizations, together with the Information Security Office and Internal Audit Department the responsibility for the development of all Information Technology Solutions, whether or not implemented by the central IT organizations.
  • Administrative Guide Memo #63, Information Security, the University defined a data classification schema based on institutional risk, data privacy, and data sensitivity.  Under the data classification guidelines, HIPAA data, FERPA-protected student data, Human Resources/personnel information, eCommerce transactions, and certain financial data are considered “Prohibited and Restricted Data,” signifying data that is most sensitive, constituting highest institutional risk, which must be protected most diligently.

<top>

Recommendations

University Departments using outsourced solutions should observe the following recommendations:

  1. All University IT Projects Should Coordinate with the Central IT Organizations - For administrative systems, external to the University’s central IT organizations, that  process, store or have access to Prohibited or Restricted Data, the implementation and enhancement project teams should have a “Central IT Liaison,” a defined contact within the IT Services, or Administrative Systems Program Management Offices, to assist in the coordinating communications and development efforts with the relevant departments and units of the central IT organizations that will be responsible for implementing and supporting their systems. Alternatively, the central IT liaison role could be fulfilled by an assigned IT Services Technical Account Manager (TAM).
  2. Apply Uniform Information Security Policies and Guidelines - The system and application development processes of administrative systems that process, store or have access to Prohibited or Restricted Data, must not only follow relevant University Policies (especially AGM #61 & #63), but the development processes must also be based on an industry best practices and have information security included throughout the System Development Life Cycle (SDLC) process. The connectivity between Stanford and the outsourced vendor over a public network such as the Internet must deploy an appropriate technical infrastructure, including firewalling and encryption and authentication technologies. This technical infrastructure is subject to an information security review by a team comprised of Information Security Office, Internal Audit and Project Management Office, at a minimum.
  3. Use Simulated Data in Non-Production Environments - System implementation and enhancement project teams should first consider the creation and use of simulated data during the development process.  In many circumstances the use of simulated data is sufficient for development, with the use of “real” data deferred until acceptance testing phases of the development lifecycle.
  4. Implement a Multi-Tiered Architecture - Whenever possible, University applications that access Prohibited or Restricted Data should implement an n-tier architecture (n ≥ 3) to provide an adequate level of data security. Under ideal circumstances, the SDLC utilizes separate environments for system development, testing and production. Each of these environments should replicate the multi-tier architecture, and be segregated from other application’s architectures.
  5. Develop a Common Data Scrambling/Obfuscation Strategy - Effective and consistent data obfuscation methodology is a highly-specialized expertise within the information security realm.  The University should develop consistent processes to scramble or obfuscate sensitive data in development environments for all system implementation and enhancement projects containing sensitive data.  We have noted that both the PeopleSoft, Version 8 implementation team and the Oracle Financials Enhancements teams independently undertook data scrambling efforts.  A common methodology for protecting sensitive data will benefit future system development projects, especially in applications where common data exists.
  6. Limit Developers’ Access to Sensitive Data - The number of individuals with access to development environments is typically much smaller than those with access to production systems.  However, users/developers of the development environments often have greater data access privileges than the typical system end users.  The only non-production environments that require undisguised data are User Testing and “Fix.”  The developers should not have privileged access to the User Acceptance Testing (UAT), Fix and Production data sets.
  7. Identification of Sensitive Data Is the Responsibility of the System Owners - Under the guidelines established in Administrative Guide Memo #61, Administrative Computing Systems and #63, Information Security, the System Owners are responsible for ensuring the security and privacy of sensitive data.  System development project teams should obtain the informed approval of the System Owners regarding the methodology and thoroughness of the data obfuscation processes.
  8. Information Security Assessments - Under Administrative Guide Memo #63, Information Security, Business and Data owners are responsible for proactively identifying and mitigating risks by requesting an information security assessment of all systems containing Prohibited or Restricted Data. This review of the application and technical infrastructure is to be performed by a team comprised of Information Security Office and Internal Audit Department, at a minimum.

<top>

Conclusion

The University’s expanded utilization of outsourced solutions for system implementation and enhancement projects increases the risks regarding breach of security and privacy of any sensitive information used in these projects.  This prompts our recommendations to adopt industry best practices to mitigate the risk of compromise or exposure of sensitive data in all production and development environments.  These recommendations are independent of the physical location and management of the systems. We believe these recommendations will result in more effective and systematic controls on the security of Prohibited, Restricted and Sensitive data.

<top>


Last modified
Tuesday, 28-Apr-2009 05:22:21 PM


 For more information, please contact:
  Eric Nakagawa, Senior Audit Manager in Stanford University's  Internal Audit & Institutional Compliance Department
(650/736-2247) or eric dot nakagawa at stanford dot edu



Stanford University Home Page