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 our applications, 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 products.
Built with security in mind
Blackboard is committed to providing our clients secure applications. Blackboard develops our products 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 our products and programs. 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 10 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 2013.
|A1: Injection (SQL/DOM/LDAP injection)||Our coding standard is to use bind variables and avoid literals transcribed into SQL statements. LDAP functionality is restricted to authentication.|
|A2: Broken Authentication and Session Management||Blackboard products only run under TLS, so all cookies are encrypted.|
|A3: Cross-site Scripting (XSS)||Cross-site scripting is mitigated through the use of shared libraries such as ESAPI and development standards. All end 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.|
|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 cases where this standard fails to be correctly enforced, remediation is simple, since all protected data entities in the system map to a security context (course or domain).
|A5: Security Misconfiguration||Blackboard 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 when one is available and relevant to your specific Blackboard product.
Information Leakage and Error Handling
|A6: Sensitive Data Exposure||Blackboard’s standard is to hash and salt user passwords with SHA-160.
Blackboard products support running under TLS; however, it is the responsibility of the deployer to properly configure TLS when their product is self-hosted.
|A7: Missing Function Level Access Control||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.|
|A8: 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.|
|A9: Using Components with Known Vulnerabilities||This is mitigated by conducting regular vulnerability scans of both our infrastructure and the third-party software packages to identify components with known vulnerabilities and to develop a roadmap to upgrade those with available patches.|
|A10: Unvalidated Redirects and Forwards||The Blackboard Secure Coding Standard requires redirects and forwards to verify they are local addresses. This vulnerability is regularly tested.|
Any statements about future expectations, plans, and prospects for Blackboard represent the Company’s current views. 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.