Security

SECURITY FEATURES

Physical Security

Student Explorer and AbroadOffice are hosted on the Amazon Web Services (AWS) platform, the most sophisticated enterprise hosting platform in the world.

AWS maintains extremely thorough security procedures for access control and security that are consistent with the standards for most major security certifications including: SOC 1/SSAE 16/ISAE 3402 (formerly SAS 70 Type II); SOC 2; SOC 3; FISMA, DIACAP, and FedRAMP; PCI DSS Level 1; ISO 27001; ITAR; FIPS 140-2; HIPAA.

An overview of AWS’s general security architecture can be found at the URL below.   

http://media.amazonwebservices.com/pdf/AWS_Security_Whitepaper.pdf

Our engineering team has built four separate software platforms on AWS since 2007 and has deep experience with scaling and securing enterprise applications on this platform.

Application Architecture

Student Explorer and AbroadOffice are on a LEMP stack (Linux, Nginx, MySQL, and PhP).    

The MySQL database is hosted with AWS’s Relational Database Service (RDS), a service that provides automatic patching and warm-standby redundancy.    The RDS is held within a Virtual Private Cloud (VPC), a logically isolated area within the AWS cloud with only limited external accessibility.  More information about these services can be found here.

http://aws.amazon.com/rds/
http://aws.amazon.com/vpc/

Student Explorer and AbroadOffice front-end/user interfaces are on AWS’s Elastic Computing Cloud (EC2) and services are progress within a load-balanced cluster of Linux servers, protected by firewalls and access controls.

http://aws.amazon.com/ec2/

All site data is backed up daily to Amazon S3 (a highly redundant and secure storage service) and periodic records are retained on a long-term basis on Amazon Glacier (a highly redundant and secure long-term storage service).  In both cases, the backups are encrypted at rest and access to the backups is logged.

http://aws.amazon.com/s3/
http://aws.amazon.com/glacier/

API access is strictly limited via secret codes that are unique per university user.

Passwords

Student Explorer and AbroadOffice follow best-practice password management approaches.

All system passwords are salted and hashed with bcrypt.

Administrators must have complex passwords.

IT Processes and Procedures

A limited number of people have access to the Student Explorer and AbroadOffice hardware environments, through carefully configured roles and permissions via AWS’s Identity and Access Management feature (IAM).

http://aws.amazon.com/iam/

Roles and responsibilities are isolated to specific individuals for systems administration, database administration and application management.

All releases undergo extensive Quality Assurance, including: development, testing on testing services, testing on staging servers and testing on production servers.

The team practices weekly code reviews to identify areas of improvement and has a series of internal practices to reduce the risk of application security flaws.

The team conducts bi-annual internal security audits using a specialized internal audit security team.    

All university users of AbroadOffice would be informed within 24 hours of a known security breach (there have been none to-date).
 

UPTIME & REDUNDANCY

Overall Uptime

The application platforms have been running continuously since October 2006.  Uptime has been 99.9% or above every year since 2006. Planned maintenance tends to be measured in minutes per month.

Monitoring

Student Explorer and AbroadOffice have three levels of monitoring in place.   All of these generate notifications to relevant IT staff on a 24/7/365 basis.

  • Site24x7 for application uptime and performance

  • AWS Cloud-watch for hardware uptime and performance

  • AWS RDS Monitoring Plan and Performance Insights for database monitoring

Redundancy

AWS provides extensive redundancy and uptime capabilities and Student Explorer and AbroadOffice use several of these capabilities.

  • DNS for Student Explorer and AbroadOffice is hosted at AWS’s Route 53, a highly distributed DNS service with over 30 data centers - http://aws.amazon.com/route53/

  • RDS provides warm stand-by and fail-over capabilities for the application database (across availability zones / data centers)

  • EC2-hosted front-end application services have load-balancing and auto-scaling (across availability zones / data centers), providing both performance stability and uptime. It is anticipated that all front-end services will be implemented in this format in 2014.

  • S3 / Glacier that is used as the platform for backups and archives (respectively) and has 99.999999999% annual object durability.

Backup

The database is backed up daily.    Restores are tested on a regular basis

DATA

Data Ownership

The home university maintains ownership of all student data.

In the event that the home university would like to discontinue use of Student Explorer and AbroadOffice, we will provide a CSV export of student and program data at no charge.

We will retain a copy of this data for backup and retention purposes only.

Use of Data

Student data in Student Explorer and AbroadOffice is only accessible to a select group of Student Explorer/AbroadOffice/UNGS staff. All staff who have access to student data have signed confidentiality / non-disclosure agreements.

Specifically, the Student Explorer/AbroadOffice/UNGS staff who have access to this system are:

  • The IT development team

  • Institutional Relations staff responsible for the implementation of AbroadOffice and training of home institution staff, along with their support staff

  • Certain senior executives

Student data in Student Explorer and AbroadOffice is not used to contact students in order to market UNGS programs. The UNGS student advising team only has access to the records of students who have applied for a UNGS program.

The student data in the system is not sold, leased or rented to third-parties.

We do not collect credit card or banking information in Student Explorer and AbroadOffice.

FERPA

We do not publicly disclose any student-level information, including directory information.

Home university study abroad administrators control the disclosure of student information to their staff and host institutions abroad. Home university is in control of authorized users with access to student records. This is an allowed usage of student data under FERPA.

Students can inspect and change their information through their account on Student Explorer and AbroadOffice.

We might, from time to time, publish aggregate, non-personally identifiable information (e.g. “23 home institutions and 1,000 students are using Student Explorer/AbroadOffice”)

Student Explorer and AbroadOffice are web-based systems that are accessible from any web browser. As such, universities that use Student Explorer and AbroadOffice need to have appropriate training and procedures for how their staff uses student data if they are to maintain FERPA compliance.  

A non-exhaustive set of areas that universities should review when using Student Explorer and AbroadOffice are:

  • Who has been given administrative account access to Student Explorer and AbroadOffice and what level of access they have been given

  • What training processes and procedures about data security and dissemination are in place

  • What is the allowed usage of data once it has been copied, printed, emailed or downloaded outside of Student Explorer and AbroadOffice

HIPAA

To the best of our knowledge, Student Explorer and AbroadOffice itself are not Covered Entities under HIPAA and neither are many study abroad offices.

http://www.cms.gov/Regulations-and-Guidance/HIPAA-Administrative-Simplification/HIPAAGenInfo/AreYouaCoveredEntity.html

Nonetheless, the general security practices of Student Explorer and AbroadOffice would not typically preclude them from being part of an overall HIPAA compliant process.

Student Explorer and AbroadOffice have a feature that allows any form to be designated as a form that contains private information.  Once this feature is enabled, a privacy screen is enabled before any user access to the form and all access to this form is logged.   The logs include the date, time, reason and user who accessed the form.   This feature should be enabled for any forms that contain medical data to provide the appropriate audit/access logs.