Blackboard has a robust security program that not only acts to prevent security issues from appearing, but also roots them out. Blackboard performs continuous internal security testing at the code-level (static analysis) and application-level (dynamic analysis) to ensure it meets both Blackboard and our customer’s expectations. Furthermore, to regularly get fresh eyes on the application, Blackboard obtains security penetration testing from third party security vendors. Any identified issues are quickly slated for repair.
It is important to realize Blackboard's security program is a growing and maturing practice. We operate under continuous improvement to push the bar on security features and robustness in Blackboard Learn.
Built with Security in Mind
Blackboard is committed to providing our clients secure applications. Blackboard develops Blackboard Learn according to a set of security engineering guidelines derived from many organizations such as the Open Web Application Security Project (OWASP), including specific countermeasures for OWASP Top Ten vulnerabilities. Blackboard incorporates these security practices in all phases of the software development lifecycle (SDLC).
Blackboard utilizes several methods to protect our applications including "top-down" security assessments through Threat Modeling and analysis as well as "bottom-up" code-level threat detection through static analysis, dynamic analysis, and manual penetration testing.
Blackboard follows best practice guidance from many organizations to help strengthen the security of Blackboard Learn's product and program. A few organizations are noted here:
- National Institute of Standards and Technology (NIST)
- European Network and Information Security Agency (ENISA)
- SANS Institute
- Open Web Application Security Project (OWASP)
- Cloud Security Alliance (CSA)
As new features are developed, the Security Team assesses the requirements and system design to help mitigate risks by performing Threat Modeling. Threat Modeling is a structured process where security threats pertinent to the feature under review are identified so that appropriate security countermeasures may be identified and applied.
Secure Coding and the OWASP Top Ten Vulnerabilities
Blackboard Products are developed according to a set of development guidelines that are derived from OWASP, including specific countermeasures for OWASP Top Ten vulnerabilities for 2010.
|A1: Injection (SQL/DOM/LDAP injection)||Our coding standard is to use bind variables and avoid literals transcribed into SQL statements. Xpath is not used anywhere in the application; LDAP functionality is restricted to authentication.|
|A2: Cross-site Scripting (XSS)||Cross-site scripting is mitigated through the use of shared libraries such as ESAPI and development standards. All user-submitted text input is expected to be passed through sanitizer methods; any other kinds of input (dates, select/option values) are expected to be generated from typed domain objects, rather than transcribed directly from user input.|
|A3: Broken Authentication and Session Management||We take multiple measures to avoid compromising session cookies. We use distinct cookies under HTTP and HTTPS, so that knowledge of the HTTP cookie does not compromise the HTTPS cookie when running under conditions that switch back and forth from HTTP to HTTPS. In addition, we attempt to detect unexpected changes in client state (like a session coming from unexpected IP addresses). Session Management related cookies are set to HttpOnly (note: JSESSIONID is not used for session management and thus is intended to not have the HttpOnly flag). Session Management cookies related to an SSL-enabled instance of Blackboard Learn also have the Secure flag set.|
|A4: Insecure Direct Object References||All application objects are referenced via “ids” that usually map to the primary key. However, all objects map to and all security checks are performed against a “context”. For example, a request might reference a “message id” that is a discussion board post for a course. The Blackboard standard is to perform the authorization check for the privilege attached to a user’s role in the course. |
In cases where this standard fails to be incorrectly enforced, remediation is simple, since all protected data entities in the system map to a security context (course or domain).
|A5: Cross-site Request Forgery (CSRF)||Our security framework follows OWASP recommendations for per-request nonce values and POST-only semantics. AJAX requests use per-session nonce values. DWR uses double cookie submit of a per-session nonce value.|
|A6: Security Misconfiguration||Blackboard Learn follows a secure-by-default policy with Release Notes and Documentation leveraged when special System Administrator consideration is required. Blackboard encourages customers to follow its Secure Configuration best practices guide. |
Customers are encouraged to use Apache 2.x with documented recommendations on only allowing high-strength ciphers for transport layer protection. Blackboard regularly reviews security advisories related to the infrastructure Blackboard Learn ships with to ensure they are protected from security issues.
Security Events are logged in one of three security-specific logs. The Security Event Framework provides a set of standard event codes, standard log format, field verbosity, and accountability. The set of events logged into each event code is ever-expanding.
On installation, System Administrators are required to set passwords.
Information Leakage and Error Handling
Standard error handling is applied to all pages (via a standard page template and tag library), resulting in a standard output for all errors, especially unrecognized errors. The standard output does include a stack trace (minor information leakage), but none of the data that was being processed when the request failed and is only visible to those with administrator-level access. Unprivileged users (e.g. students) are not able to see detailed stack traces.
|A7: Insecure Cryptographic Storage||User passwords are hashed, not encrypted. Beginning in Blackboard Learn, Release 9.1 Service Pack 12, user passwords are hashed and salted by default with SHA-512. The Blackboard Learn Product Security Roadmap has plans for handling system passwords used for application start-up that are by default protected by operating system and filesystem access control.|
|A8: Failure to Restrict URL Access||This is managed at two levels – requiring that business logic enforce authorization checks, and by ensuring that QA test cases cover authorization requirements for different screens. All screens/links are potentially rendered; there are no “hidden” URLs that require manual entry. As a result, the application is expected to screen access to URLs before attempting to render them.|
|A9: Insufficient Transport Layer Protection||Blackboard Learn supports running under SSL; however, it is the responsibility of the deployer to properly configure SSL. SSL Offloading is also supported by Blackboard Learn, Release 9.1 Service Pack 8 and greater.|
|A10: Unvalidated Redirects and Forwards||The Blackboard Learn Secure Coding Standard requires redirects and forwards to verify they are local addresses. This vulnerability is regularly tested.|
Other Previous Vulnerability Categories in the OWASP Top Ten:
|Malicious File Execution||Files uploaded by non-privileged end users are never used as executables. Privileged users (i.e., System Administrators), may, however, upload executable packages called Building Blocks that extend the functionality of the system. It is assumed, that System Administrators understand the risks and follow sound vendor review and change management practices around the installation of any third party Building Blocks.|
Any statements about future expectations, plans and prospects for Blackboard represent the Company’s views as of January 1, 2013. Actual results may differ materially as a result of various important factors. The Company anticipates that subsequent events and developments will cause the Company’s views to change. However, while the Company may elect to update these statements at some point in the future, the Company specifically disclaims any obligation to do so.