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)

Threat modeling

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.

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. Security Auditing Security Events are logged in security-specific logs. 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 may 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 (such as students) are not able to see detailed stack traces.
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.

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.

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 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.

Vulnerability Management Commitment and Disclosure Policy

Blackboard's vulnerability management program is governed by this public-facing Vulnerability Management Commitment and Disclosure Policy below. No software vendor is perfect - in the event a security vulnerability is identified in a released product, Blackboard's Security Team is ready to respond.

For help logging in, you need to contact your institution’s IT help desk. Blackboard doesn't have access to your institution's account information, web sites, or content. If you don’t know how to contact the help desk, try searching the web for your institution’s name + help desk, or check your login page for a support link or contact information.

Blackboard is committed to resolving security vulnerabilities quickly and carefully. Such resolutions may lead to the release of a Security Advisory and/or any needed product update for our customers. In order to protect our customers and their data, we request that vulnerabilities be responsibly and confidentially reported to us so that we may investigate and respond.

Blackboard’s products are complex. They run on diverse hardware and software configurations, and are connected to many third party applications. All software modifications—big or small—require thorough analysis, as well as development and implementation across multiple product lines and versions. The software must also undergo localization, accessibility, and testing appropriate to its scope, complexity, and severity. Given the critical importance of our products to our customers, Blackboard must ensure that they run correctly not only in our testing facilities, but also in customer environments. Accordingly, Blackboard can't provide product updates according to a set timeline, but we are committed to working expeditiously.

Malicious parties often exploit software vulnerabilities by reverse engineering published security advisories and product updates. It's important for customers to update software promptly and use our severity rating system as a guide to better schedule upgrades.

Testing for security vulnerabilities

You should conduct all vulnerability testing against non-production instances of our products to minimize the risk to data and services.

How to report a vulnerability

Confidentially share details of the potential vulnerability by filling out a vulnerability submission form.

Provide details of the potential vulnerability so the Blackboard security team may validate and reproduce the issue quickly. Without the above information, it may be difficult if not impossible to address the potential vulnerability. Reports listing numerous potential vulnerabilities without detail won't be addressed without further clarification. Details should include:

Type of vulnerability;
Whether the information has been published or shared with other parties;
Affected products and versions;
Affected configurations; and
Step-by-step instructions or proof-of-concept code to reproduce the issue.

Blackboard security commitment

To all vulnerability reporters who follow this Policy, Blackboard will attempt to do the following:

Acknowledge the receipt of your report;
Investigate in a timely manner, confirming where possible the potential vulnerability;
Provide a plan and timeframe for addressing the vulnerability if appropriate; and
Notify the vulnerability reporter when the vulnerability has been resolved.