PREVIOUS VERSION
This site is the documentation for a Scholar Snapp Austin (v3.0), a previous version of the Scholar Snapp Technology Suite.
The Snapp solution is currently backward-compatible with v3.0, but all new development projects should leverage Scholar Snapp Technology Suite Berkeley (v4.0).
Scholar Snapp Security & Infrastructure Overview
- Ian Christopher (Deactivated)
Introduction
This documentation provides an overview of the Scholar Snapp technology and online applications. It includes general information as well as specific certifications and compliance information. Prospective and current scholarship application integrators with specific questions are encouraged to send an e-mail to ContactUs@ScholarSnapp.org.
Contents
Data Center Security
The Snapp Central API, underlying database, and web application are hosted on the Heroku platform, which itself is hosted and managed within the physical infrastructure and secure environment used for Amazon Web Services (AWS).
Amazon's data centers have the following accreditations:
- ISO 27001
- SOC 1 and SOC 2/SSAE 16/ISAE 3402 (Previously SAS 70 Type II)
- PCI Level 1
- FISMA Moderate
- Sarbanes-Oxley (SOX)
Physical Security
Heroku uses the ISO 27001-certified and FISMA-certified data centers managed by Amazon for AWS. AWS data centers are housed in secure facilities, and critical facilities have extensive setback and military-grade perimeter control berms as well as other natural boundary protection.
Physical access is strictly controlled both at the perimeter and at building ingress points by professional security staff utilizing video surveillance, state of the art intrusion detection systems, and other electronic means. Authorized staff must pass two-factor authentication no fewer than three times to access data center floors. All visitors and contractors are required to present identification and are signed in and continually escorted by authorized staff.
Redundancy
The Heroku platform maintains redundancy to prevent single points of failure, will replace failed components, and uses multiple data centers designed for resiliency. In the case of an outage, Heroku is deployed across multiple data centers using current system images – and data is restored from backups.
The Heroku data center power systems are designed to be fully redundant and maintainable without impact to operations, 24 hours a day, seven days a week. Uninterruptible Power Supply units provide back-up power in the event of an electrical failure for critical and essential loads in the facility. Data centers use generators to provide backup power for the entire facility.
Data Center Management
Amazon data center staff monitor electrical and mechanical equipment so issues can be immediately identified. Preventative maintenance is performed to maintain proper equipment function.
The information in this section is based on the Heroku documentation on security here and the AWS security information here, and is periodically reviewed for accuracy.
Application Security
Snapp leverages secure, standard, proven technologies.
SSL & HTTPS
All network traffic, including administrative access to our server infrastructure, is handled over SSL and HTTPS.
OAuth2
Authentication for the Snapp data exchange is implemented as 3-Legged OAuth2. This means that only specifically approved systems can connect to our servers, and only the scholar that creates an account can access his or her personal data.
Application Lockout
The online application, including our administrative functions, lock out users after a number of failed login attempts. We periodically monitor our server logs to ensure that we don't see an untoward number of failed login attempts.
Student Data Privacy
This section outlines student data privacy concerns.
Data Classification
The Snapp program deals with various kinds of information ranging from the very sensitive (like applicant data) to the publicly available (like NCES codes and CIP codes). To promote appropriate handling of all information, we have the following classifications for data:
- Confidential. Confidential information includes personally identifying information (PII) related to applicants and application data in general. It also includes information such as API keys/secrets that would provide an attacker with information necessary to access applicant information.
- Sensitive / Internal Use Only. Sensitive information is information that is not necessarily confidential, but still deserving of special treatment, such as material provided to Snapp in confidence from implementation partners, draft policies, security and thread analysis, contact information for mailing lists, and similar.
- Public. Public information is such information intended for general public consumption (e.g., web page content or a press release).
Confidential information is treated with the greatest care. This specifically includes applicant data in our production databases, backups of production database with real data, XML or other physical data files containing application data (e.g., received from implementation partners), and API keys and secrets.
FERPA
We adhere to the spirit of FERPA. Snapp was designed from the ground up to be secure, and we keep all data private. Further, we require our partners keep applicant data private.
So, there’s a high degree of overlap between FERPA requirements and Snapp because we share the same concerns. But, because Scholar Snapp is not a federally funded institution, or a program administered by the U.S. Department of Education, FERPA is not applicable, strictly speaking. There's no formal specification we can follow to claim FERPA compliance.
HIPPA
Same deal as FERPA: Snapp technology was designed to keep data secure, and our policies are written to keep data private, so Snapp is aligned with HIPPA. However, we are not a HIPPA "covered entity" so we cannot claim to be compliant in a formal sense.
Security Audits & Testing
This section outlines basic information about how we ensure our security policies and practices are effective.
Annual Audit
All Snapp applications and related systems are audited every year by an external company specializing in application security. Activities include:
- Black box threat analysis (i.e., simulated hacking attempts)
- White box code review and analysis (i.e., reviewing code, platforms, and configurations to look for possible weaknesses)
- Remediation
- Process and policy updates
We generally hold our annual security training for team members in conjunction with the annual audit to ensure any policy updates are put into practice immediately.
Monthly Audit
All Snapp applications and platforms are audited monthly. Activities include:
- Access log analysis
- Error log review
- Account access review (i.e., ensuring only current team members have access to resources)
- Policy updates (i.e., ensuring documented processes are current and complete)
The above is, of course, just a summary. We do many other scheduled and ad hoc activities such as incident drills, peer reviews, and more to ensure that the data in our systems remains secure.
Security Principles & Practices
This section outlines general principles and practices that guide our work.
Development Lifecycle
Our core responsibility is to create a safe and secure platform. We consider the security implications of any change we make.
Continuous Improvement
We are committed to continuous improvement in all facets of our technology work, including security. Our software team holds development retrospectives on a regular basis. We do frequent application health and security checks. When issues are found, we address the problem and update our processes to prevent the problem in the future.
Policy Documentation
Our security policies are documented. We have incident management checklists for rare-but-possible occurrences such as a security breach. We review our documentation after every incident and make small improvements – and do an annual review of all policies and documentation to ensure we're following the latest guidance and best-practices.
Staff & Developer Training
All development team members and technical support staff receive security and data handling training when they join the team, and at least annually thereafter.
System Access
We limit access to all Snapp resources, including servers, source control, deployment, and so forth. We provide the minimum access necessary for developers and support staff to do their job. Access to the production server where live student data is stored is very strictly limited. We keep an access control log showing the access granted to each team member. The access control log is audited monthly to ensure that only currently assigned personnel have access to Snapp systems.
Contractors
All contractors assigned to the Snapp program receive the same training as in-house staff, and follow the same processes and practices. Contractors are individually identified (i.e., we don't provide access to a company as a whole – rather we identify individuals and provide access to resources in accordance with their specific role on the project).
Similarly, contractors take part in our periodic security audits, incident drills, and training.