Security

Terra Dotta Software Security Model

Terra Dotta web applications deliver information through both public and private interfaces. This document explains how Terra Dotta manages data security through various protocols and user authorization.

Secure Communications

Terra Dotta software is designed for use with SSL encryption for communications over the Internet. When configured to use SSL, the application enforces secure communications in all private areas of the website (all areas that require user authentication) by disallowing nonsecure HTTP requests and redirecting the browser to the secure protocol.

SSL requires the purchase of a security certificate through a certificate authority service, which must be done by the customer and requires annual renewal. Selection of a certificate authority and the maintenance of the certificate are at the customer's discretion.

Database Security

When Terra Dotta software is installed on the customer network/servers, database security is managed by the policies and practices of institutional customer IT administration, governed by user permissions, firewalls and network access lists. Terra Dotta does not instruct on best practices for database security at the server level.

For Hosted & SaaS customers, Terra Dotta provides hardened, redundant database servers at a top-tier, SAS 70 Type II certified datacenter. The database and application are configured in separate tiers of the physical systems, with strict firewall rules partitioning the servers.

At the application level, Terra Dotta systems minimize the possibility of attacks such as SQL injection, a known area of vulnerability for web applications, by using low-level bindings on all its native queries. For additional security in campus data integration, Terra Dotta software supports the use of stored procedures for data retrieval.

FERPA/HIPAA Considerations

Terra Dotta software is configured to collect and manage student personal information protected under the Family Educational Rights and Privacy Act (FERPA) and other privacy legislations, such as Health Insurance Portability and Accountability Act (HIPAA). The application provides controls to restrict access to specific elements student data to only those individuals or groups explicitly authorized to access them. The institution must ensure those controls are properly applied. For example, all health information can be grouped for restriction to a custom user policy group called "HIPAA Authorization," restricting all other users from viewing that information.

Frontiers with other systems, including personal workstations, are a point of security where customers must apply diligence to ensure that data otherwise protected in the application is not improperly moved to a location that is not protected. Shared Reports are an example of where digital security and user responsibility intersect. Terra Dotta software allows authorized users to generate reports that incorporate personal data elements. A report is secure and accessible only to the author of the report - unless the author shares it with others. The author may select other Staff and Reviewers with whom to share the report, which thereby overrides the underlying data access restrictions - similar to if they shared photocopies of a printed report.

User Authentication and Authorizations

On university campuses and other network environments Terra Dotta web applications can integrate with any existing campus identity system to authenticate users by their universal network login. The authentication routine can be customized to retrieve the unique ID by which a person's identity is matched with data fetched from campus data systems (i.e., student information system and HR directory). Such authentication and integration can be done whether the software is hosted on campus or on Terra Dotta servers.

In conjunction with or in lieu of institutional authentication systems, Terra Dotta applications provide native user authentication based on e-mail address and a user-supplied password. Upon user request, the application sends a temporary, expiring password via e-mail to be reset by the user to a permanent one. Users are required to provide answers to personal security questions in order to reset their passwords. Passwords are stored in the database as an MD5 hash (salted/peppered), making them impossible to discover. Settings are available for password strength and expiration, as well as for protection against brute-force password guessing.

The authorization of users in Terra Dotta software for specific administrative and data-access permissions is managed through permissions that are established by administrative assignments (authorized administrators assigning permissions) or by user interaction (e.g., students logging in to apply to a program, faculty being requested to access and provide a recommendation/referral). There are system user groups that establish default permissions for certain user roles. Additionally, any number of custom user groups can be created as permission profiles/policies for specific user roles (e.g., Website Editors, Application Readonly). Permissions can also be assigned at the individual user level to supersede the group permissions of any user, either for inclusion or exclusion. Example: an individual user in a user policy group that has all Website Admin permissions can have the permission to edit or delete posted announcements overridden (excluded) in their user-level security profile, while the rest of the group members inherit that permission by default from the group.

Permissions are grouped into categories, which are then subdivided into areas of the administrative interfaces, and permissions within those areas. Example: Student Admin: Application admin: materials (edit). These granular permissions number in the hundreds.

Additionally, access can be restricted by Data Access Object permissions. At the time of this writing, the available object-level restrictions are on Programs, Program Groups, Program Sponsors, Home Institutions, Student Parameters, and Course Categories. The various object-level restrictions have specific effects on data access:

Programs, Program Groups and Sponsors: These restrictions limit access to the administration and display of designated programs and their applicants. Searches, displays and administrative interfaces for non-designated programs are suppressed from view and access.

Institution: This selection restricts access to the administration and display of designated applicants originating from specified home institutions. Searches, displays and administrative interfaces for non-designated applicants are suppressed from view and access.

Student Parameters: This is an inclusion list for parameters to make accessible to the specified group or individual. In order for the restriction to be effective in preventing access to non-designees, the System User Groups must have a restriction including only those available by default. Example: Assign access to Facilitators and Reviewers groups for "Major" parameter only, and assign health data access to a specific Group.

Course Categories (Subject Area and Competency by default): The effect of this restriction is to show only the Credit Equivalency Requests submitted in the specified categories. The purpose of these restrictions is for ease of distributed access to targeted credit evaluators.

User Groups

There are both standard, built-in System User Groups and user-defined User Groups. The System User Groups are as follows:

Staff Group: Administrative users who are assigned permissions as primary administrative end-users. No permissions by default.

Reviewers Group: Adjunct administrative users whose function in the system is typically to administer segments of the applicant or program population (program groups, applicants from certain home institutions, specific sponsored programs, etc.). No permissions by default.

Recommender Group: Individuals typically prompted by the applicant to provide a recommendation or referral. By adjustable default, recommenders only have access to the applicant's name and intended program of study, plus information volunteered (hand-typed) by the student in the request message. A special facet to recommender permissions is an optional feature to distribute a one-use key code for providing recommendation responses without a login. If this feature is disabled, recommenders simply access their pending recommendations requests using the standard login options.

Maintenance Group: The Maintenance User Group by default has all permissions in the Maintenance category of permissions, except for the Super User permission, which permits unlimited access to the system. Maintenance-category permissions include those that involve the server setup, scheduled tasks, logs, integration, system tests and utilities for data manipulation.

Default permissions can be adjusted on all of the above System Groups, and an unlimited number of additional custom User Groups can be configured for specific policy needs.

Security Testing

Terra Dotta performs regular security testing on our applications, both manual and automated. This testing is performed in all major and minor (maintenance) releases.

Our Development and Quality-assurance processes follow the guidelines of the OWASP Top Ten list of security vulnerabilities.

Additionally, we contract with WhiteHat Security for continuous scanning of our application using their Sentinel Premium Edition scanning system, which combines automated testing and manual testing and analysis, continually combining the OWASP Top Ten with emerging vulnerabilities.

Further information about the Sentinel service is available at http://whitehatsec.com.

Terra Dotta's US-based data center is protected by Alert Logic Threat Manager IDS, through which we also perform regular SAINT scans for vulnerability detection on our hosting systems.