Follett is committed to data security and supporting our customers’ data privacy needs. As student data collection evolves, Follett continues to provide and enhance the necessary levels of security to ensure your student information is secure and private in our learning management and educational systems.
Protection of individual sensitive and personally identifiable information (i.e. PII) is a priority for Follett. To ensure compliance with all applicable privacy legislation Follett has established policies and processes that focus on the protection of all potentially sensitive customer data. Follett has invested in technologies that support the protection and provide security of data while in transit or at-rest.
Follett’s Pledge of Student Privacy
Follett is proud to be one of the first signers of the national Student Privacy Pledge regarding the collection, maintenance, and use of student personal information. The pledge states: “School service providers take responsibility to both support the effective use of student information and safeguard student privacy and information security.”
Follett takes the Student Privacy Pledge seriously and strives to go above and beyond the privacy constructs defined within.
Aspen provides several levels of security that control access to your system from people external to your organization, internal to your organization, and even among other Follett products that you are using.
We built Aspen to include security as a core component of its design. This design includes a strict adherence to the separation of different layers within the application. Users interact with a presentation layer that is strictly HTML. All business logic operates on the application server in a business layer that is isolated from both the presentation and the database access.
All data is securely transmitted over the HTTPS protocol. This includes page content, images, fonts, and user data. Finally, all database access is handled by a third and isolated persistence layer. Thus, between the end user and the actual storage of sensitive data, there are three independent layers in the Aspen application that all play important roles in ensuring only the appropriate data gets to the each user.
The Aspen data model consists of a single database, meaning that data does not need to be replicated to other data stores. Security rules are applied universally to each database instance when it is created, and the database is not accessible from outside the data center firewall. Each Aspen customer has a separate logical database, and each Aspen instance only has the user account of the database for that instance.
Our approach to security at the design level means that typical hacking techniques such as SQL injection and Cross-Site Scripting (XSS) are blocked, not by patches and fixes to vulnerabilities that come out on a periodic basis, but by the basic design of the application and encapsulation of each layer.
Security and penetration tests are routinely run on Aspen to verify that our security is intact. This testing allows us to verify that the security measures we’ve developed—such as the cross-site scripting protection layer that prevents database access via SQL injection—are working to prevent known attack vectors.
All access to the database is managed through the application, and the data is only visible to users with specific rights and permissions. To accomplish this you can apply your data security in a number of ways including; field-level, component-level, record-level or scoping, and navigation security.
User Group Profile and Maintenance
Aspen provides role-based security. Roles are defined and granted privileges to create, read, update, delete, or mass-update (CRUD-M) records in a particular table. There are also business privileges for special operations like archiving a student or accessing teachers’ grade books. Roles are then assigned to users. Aspen allows users to be associated with multiple roles and with multiple schools. A user gets the cumulative privileges allowed by those roles.
Audit Reporting of System and Application Access
Aspen has auditing abilities that allow you to review and confirm that your policies are working the way you intended. Aspen includes an audit trail component that can be enabled for any table and field in the Data Dictionary. For each record modified, the audit trail shows who made the change, what was changed (both the original and new values), and when the change was made. Only users with the appropriate privileges to view a record’s audit trail history can do so.
Aspen also makes use of security roles to restrict users from intentionally deleting data, alerts and prompts to prevent users from accidentally deleting data, and the audit trail to record what data may have been lost.
The Family Educational Rights and Privacy Act (FERPA) business rules are built into system so that guidelines (for example, teachers can only access student data for students that they teach) is automatically enforced. System-wide searches only show directory info that is within the FERPA guidelines and can be disabled at the discretion of the district. The comparable Canadian privacy act, Freedom of Information and Protection of Privacy Act (FOIPPA), is also supported.
Student-identifiable information is not shared or uploaded to any other systems from Aspen—including other Follett Software Solutions. The ability to share patron data with Destiny exists, but must be explicitly and proactively configured. Student-identifiable information that would not otherwise be stored in Destiny is not shared.
The Follett Destiny® suite shares many of the same security attributes as Aspen — including multiple levels of support data security.
- The Destiny data model consists of a single database; data does not need to be replicated to other data stores
- Each Destiny district has a separate physical database file
- Security rules are applied universally to each database instance
- For Follett hosted customers, all data is securely transmitted over the HTTPS protocol. For customers who host Destiny on-premise, HTTPS is supported and works with the SSL certificate, provided by the customer, that matches the on- premise domain. This secure transmission includes page content, images, fonts, and user data.
- The database is not accessible from outside the data center firewall in case the Destiny product is housed at the Follett-managed data center
- The database is not directly accessible via the public internet
- All access to the database is managed through the application, and data is only visible to users with specific rights and permissions
- Destiny is routinely tested against attacks using automated acceptance testing, such as exercises and sample data intended to uncover SQL injection vulnerabilities. Authentication methods are exercised through automated unit tests to validate that data access is restricted to users with the appropriate permissions.
Follett's dedication to data security best practices applies to our eBook products and eReader platform, as well.
All data is securely transmitted over the HTTPS protocol. This includes page content, images, fonts, and user data. All data is then stored into an encrypted data store on the local machine, inside a directory that only that user (and root) has access to. The encryption key to unlock the data is generated locally at the time of the data store creation and stored in the system user’s encrypted local store (ELS).
Only a combination of our application and that user has access to the encryption key in the ELS. Each book’s data is contained in its own secure data store, separate from the main encrypted data store, with its own encryption key stored in the ELS. When the book is removed by the user via Follett Digital reader, its data store is deleted from the local file system, which includes all content, imagery, and fonts.
We encrypt each book with 128bit AES encryption, and every book has its own unique key. In addition to encrypting the book, we have a voucher mechanism that is also encrypted using 128bit AES encryption and ensures the content is locked to the specific machine it was downloaded to.
Follett uses a proprietary conversion and encryption process that our Follett eReader platform has been designed specifically to utilize.
Our Data Center
The Data Center where Follett houses and manages its servers is an approximately 3,000 square-foot, raised-floor facility. Physical access to the data center is controlled by a card proximity reader. Only individuals with a role that requires access to the data center are permitted in the raised floor area. Access to the mechanical space is similarly controlled. A camera system has been installed at the doors to the data center to record entrance and exit to the raised floor and mechanical space. Procedures are in place to log the access to the data center.
Data Center-contained server access is similarly controlled with secured access by Follett employees as well as approved designated third party vendors and systems — including development consultants, hardware vendors, SIF agents, and more.
Follett is committed to helping our customers demonstrate the privacy and security of their student data. Our security features are designed to provide physical and digital security and empower districts to develop, enact, and enforce their privacy policies. For more information about our data security, please contact us.