В Blackboard есть надежная защита, которая не просто предотвращает проблемы с безопасностью, но и полностью устраняет их. Blackboard проводит постоянные внутренние проверки защиты на уровне кода (статический анализ) и приложения (динамический анализ), чтобы обеспечить соответствие как ожиданиям клиентов, так и ожиданиям Blackboard. К тому же, Blackboard заказывает тестирование на взлом у сторонних поставщиков услуг по обеспечению безопасности. Так мы уверены, что на наши приложения посмотрят свежим взглядом. Мы сразу же принимаемся за устранение всех выявленных проблем.

Важно понимать, что Blackboard постоянно развивает свои программы защиты. Мы все время работаем над улучшением, чтобы поднять планку надежности и безопасности продуктов Blackboard еще выше.


Мы позаботились о безопасности

Безопасность приложений клиентов — один из основных приоритетов Blackboard. При разработке продуктов Blackboard придерживается целого ряда руководств по безопасному программированию, основанных на опыте таких организаций, как сообщество OWASP (Open Web Application Security Project — открытый проект обеспечения безопасности веб-приложений), включая конкретные профилактические меры для 10 главных уязвимостей по версии OWASP. Blackboard применяет эти методы обеспечения безопасности на всех этапах разработки программного обеспечения (SDLC).

Blackboard использует несколько методов защиты приложений, включая нисходящую оценку безопасности с помощью моделирования угроз и анализа, а также восходящего выявления угроз на уровне кода через статический и динамический анализ, а также ручное тестирование на взлом.

Blackboard опирается на передовые наработки многих организаций, чтобы повысить защиту продуктов и программ. Несколько организаций перечислены ниже:

  • Национальный институт стандартов и технологии (NIST)
  • Европейское агентство по сетевой и информационной безопасности (ENISA)
  • Институт SANS
  • Проект по обеспечению безопасности открытых веб-приложений (OWASP)
  • Альянс за безопасность в облачной среде (CSA)

Моделирование угроз

При разработке новых функций команда безопасности оценивает требования и архитектуру системы, чтобы снизить риски с помощью моделирования угроз. Моделирование угроз — это структурированный процесс, при котором определяются возможные угрозы. Зная их, можно выработать и применить эффективные профилактические меры.


Безопасное программирование и 10 главных уязвимостей по версии OWASP

Продукты Blackboard разрабатываются согласно ряду руководств, основанных на опыте OWASP, включая конкретные профилактические меры для 10 главных уязвимостей по версии OWASP за 2013 г.

A1. Инъекции (SQL/DOM/LDAP-инъекции)Наши стандарты написания кода предполагают использование переменных связывания и отказ от использования буквенных констант, преобразованных в SQL-операторы. LDAP используется только для проверки подлинности.
A2. Ошибки проверки подлинности и управления сеансомПродукты Blackboard работают только по протоколу TLS, поэтому все файлы cookie зашифрованы.
A3. Межсайтовое выполнение сценариев (XSS)Чтобы предотвратить межсайтовое выполнение сценариев, используются совместные библиотеки, такие как ESAPI, и стандарты разработки. Из всех текстовых данных, введенных конечными пользователями, удаляются персональные данные. Остальные входящие данные (значения дат или выборы) создаются на типизированных объектах домена, а не преобразовываются напрямую из данных, введенных пользователем.
A4. Незащищенные прямые ссылки на объектыДля ссылки на все объекты приложения используется идентификатор, обычно указывающий на первичный ключ. Однако все объекты размечаются в контексте, в нем же происходят все проверки безопасности. Например, запрос может вести к идентификатору сообщения, которое является записью на доске обсуждений курса. Согласно стандартам Blackboard, закрепленные за ролью пользователя права подтверждаются через проверку подлинности.
В случае ее неудачи решение проблемы не вызывает сложностей, поскольку все защищенные данные системы размечены в рамках контекста безопасность (курса или домена).
A5. Неправильная конфигурация системы безопасностиЕсли требуется консультация системного администратора, Blackboard следует политике изначальной защиты, а также добавляет заметки к выпуску и документацию. Blackboard поощряет клиентов следовать руководству по передовым практикам конфигурации систем безопасности, если оно доступно и применимо к конкретному продукту Blackboard.

Контроль безопасности
Все события, влияющие на безопасность, записываются в отдельный журнал безопасности.

Устранение ошибок и утечки данных
Для всех страниц используется стандартное устранение ошибок (через стандартный шаблон страницы и библиотеку тегов), в результате чего выводимые данные стандартны для всех ошибок, особенно для неопределенных. Стандартные выводимые данные видны только пользователям с правами доступа администратора. Они могут включать в себя трассировку стека (мелкая утечка данных), но к ним не относятся данные, которые обрабатывались во время ошибки запроса. Развернутая трассировка данных недоступна для пользователей без привилегий (например, учащихся).

A6. Уязвимость конфиденциальных данныхСогласно стандартам Blackboard, пароли хешируются с солью SHA-160.

Продукты Blackboard поддерживают протокол TLS. Однако если продукт развернут на собственном сервере, то правильная настройка TLS становится обязанностью администратора развертывания.

A7. Управление доступом на уровне отсутствующей функцииЭта проблема решается на двух уровнях: обязательная проверка подлинности в функциональном коде и проверка требований к авторизации на разных экранах во время проверки качества.
A8. Межсайтовая подделка запроса (CSRF)Наша инфраструктура безопасности следует рекомендациям OWASP для временных значений на запрос и для семантики только POST-запросов. AJAX-запросы требуют временные значения на сессию.
A9. Использование компонентов с выявленными уязвимостямиЭта проблема нейтрализуется благодаря регулярному сканированию уязвимостей как в нашей инфраструктуре, так и в программном обеспечении сторонних разработчиков, чтобы выявить уязвимости и разработать план их устранения с помощью доступных исправлений.
A10. Неутвержденные переадресации и пересылкиСтандарт безопасного программирования Blackboard требует подтверждения локального адреса для переадресаций и пересылок. Эту уязвимость постоянно проверяют.

Любые заявления относительно планов, перспектив или ожиданий Blackboard отражают текущую позицию компании. Фактические результаты могут значительно отличатся от них в силу различных важных факторов. Компания ожидает, что последующие действия и обстоятельства вызовут изменения этой позиции. Однако хотя заявления и могут быть обновлены в будущем, компания не несет никаких обязательств по их изменению.