Фраза дня: раскрытие уязвимости
Что такое раскрытие уязвимости?
Раскрытие уязвимостей - это практика сообщения о недостатках безопасности в компьютерном программном или аппаратном обеспечении. Исследователи безопасности, группы ИТ-безопасности, внутренние разработчики, сторонние разработчики и другие лица, работающие с уязвимыми системами, могут сообщать об уязвимостях непосредственно сторонам, ответственным за неисправные системы.
Решающее значение имеет обеспечение того, чтобы поставщики программного или аппаратного обеспечения могли устранить уязвимости до того, как злоумышленники смогут их найти и использовать. Выявление таких недостатков настолько важно, что программы вознаграждения за ошибки или программы вознаграждения за уязвимости, которые вознаграждают исследователей за обнаружение недостатков, часто инициируются вместе с внутренним аудитом кода и тестами на проникновение как часть стратегии управления уязвимостями.
Проблемы с программами раскрытия уязвимостей
Раскрытие уязвимостей может быть спорным, потому что поставщики часто предпочитают дождаться выхода исправления или другой формы смягчения, прежде чем обнародовать уязвимость. Однако исследователи, профессионалы в области кибербезопасности и предприятия, конфиденциальные данные или системы которых могут подвергаться риску, предпочитают, чтобы раскрытие информации было как можно скорее.
Вот почему заинтересованные стороны часто имеют разные приоритеты в отношении раскрытия информации об уязвимостях:
- Продавцы, разработчики или производители уязвимых систем или услуг могут предпочесть, чтобы уязвимости раскрывались только им самим и публиковались только после введения исправлений.
- Пользователи уязвимых продуктов или услуг могут предпочесть, чтобы системы, которые они используют, были исправлены как можно быстрее.
- Исследователи безопасности, обнаружившие уязвимости, могут предпочесть, чтобы исправление было выполнено быстро, чтобы они могли публиковать сведения об обнаруженных уязвимостях. Однако, если уязвимость не может быть исправлена до того, как злоумышленники начнут ее использовать, раскрытие предпочтительнее, если есть другие способы смягчения или устранения угрозы.
Типы раскрытия информации об уязвимостях
Пути к раскрытию уязвимостей, которые организация может предпринять, включают следующие.
Ответственное раскрытие информации
Ответственное раскрытие информации - это один из подходов, который поставщики и исследователи использовали на протяжении многих лет. В соответствии с протоколом ответственного раскрытия информации исследователи сообщают поставщикам системы об уязвимости и предоставляют поставщикам разумные сроки для расследования и устранения этих уязвимостей.
Затем они публично раскрывают уязвимости после их исправления. Как правило, руководящие принципы ответственного раскрытия информации позволяют поставщикам от 60 до 120 рабочих дней на исправление уязвимости. Часто поставщики договариваются с исследователями об изменении расписания, чтобы дать больше времени на исправление серьезных недостатков.
Скоординированное раскрытие уязвимостей
В 2010 году Microsoft попыталась изменить картину раскрытия информации, представив новую концепцию скоординированного раскрытия информации, известную как «Скоординированное раскрытие уязвимостей» (CVD). Агентство по кибербезопасности и безопасности инфраструктуры с тех пор приняло CVD.
В рамках CVD исследователи и поставщики совместно работают над выявлением и устранением уязвимостей и согласовывают взаимоприемлемые сроки исправления продукта и информирования общественности. Исследователи также могут сообщить об этом в группу готовности к компьютерным чрезвычайным ситуациям США (CERT), которая отчитывается перед поставщиком в частном порядке, или перед частным сторонним поставщиком, который работает с поставщиком в частном порядке.
Самораскрытие
Самораскрытие происходит, когда производители продуктов с уязвимостями обнаруживают недостатки и публикуют их, как правило, одновременно с публикацией исправлений или других исправлений.
Раскрытие информации третьими сторонами
Раскрытие информации третьими сторонами происходит, когда стороны, сообщающие об уязвимостях, не являются владельцами оборудования, программного обеспечения, систем, авторами или правообладателями.
Исследователи безопасности, которые информируют производителей об уязвимости, обычно раскрывают информацию третьими сторонами. Такое раскрытие информации может также включать CERT.
Раскрытие информации о поставщиках
Раскрытие информации о поставщиках происходит, когда исследователи сообщают об уязвимостях только поставщикам приложений, которые затем разрабатывают исправления.
Полное раскрытие информации
При полном раскрытии информации об уязвимости публикуется полностью, часто сразу после того, как становятся известны подробности уязвимости.
Рекомендации по политике раскрытия уязвимостей
Политика раскрытия уязвимостей (VDP) предоставляет простые инструкции по отправке информации об уязвимостях в организации. VDP позволяет людям сообщать об уязвимостях в продуктах или услугах компании.
Согласно Национальному управлению по телекоммуникациям и информации, ПВД должен содержать следующие компоненты:
- Обещание бренда. Это позволяет компании продемонстрировать свою приверженность обеспечению безопасности клиентам и другим лицам, которые могут быть затронуты уязвимостью, убедив пользователей и общественность в том, что безопасность и безопасность имеют важное значение. Компания описывает, какую работу она проделала, связанную с уязвимостями, и что она ожидает делать в будущем.
- Первоначальная программа и объем. Это указывает на то, какие системы и возможности являются честной игрой, а какие недоступны для людей и групп, которые находят новые уязвимости и сообщают о них. Например, компания может поощрять подачу заявок на принадлежащие ей сайты, но явно исключать любые веб-сайты клиентов, размещенные в ее инфраструктуре.
- «Мы не будем предпринимать никаких юридических действий, если». Компания информирует исследователей о действиях или действиях, которые они предпринимают, а также о том, приведут ли они к судебному преследованию или нет.
- Коммуникационные механизмы и процессы. Это позволяет компании определять, как исследователи отправляют отчеты об уязвимостях - например, с помощью защищенной веб-формы или электронной почты.
- Необязательные предпочтения и приоритеты отправки. Они устанавливают ожидания в отношении предпочтений и приоритетов в отношении того, как компания будет оценивать отчеты. Это также позволяет исследователям узнать, какие вопросы считаются важными. Обычно этот динамический документ поддерживается группой поддержки и инженеров организации.
В своих VDP компании также могут сообщать искателям, когда они могут публично говорить об уязвимостях. Например, организация может заявить, что нашедший не может публично раскрыть уязвимость при следующих условиях:
- пока не зафиксируется;
- пока не пройдет определенное время с момента первой отправки отчета;
- пока искатель не уведомит организацию за X дней; или
- за исключением взаимно согласованных сроков, которые могут быть изменены в рамках процесса с раскрывающей стороной.
Об уязвимостях, о которых сообщается в CERT Института программной инженерии Университета Карнеги-Меллона, они пересылаются пострадавшим поставщикам «в кратчайшие сроки после получения отчета».
В настоящее время исследователи безопасности не согласны с тем, что составляет «разумный промежуток времени», позволяющий поставщику исправить уязвимость до полного публичного раскрытия информации.
Большинство отраслевых поставщиков, а также команда Google Project Zero рекомендуют 90-дневный крайний срок для исправления уязвимости до полного публичного раскрытия, с семидневным требованием для критических проблем безопасности и менее семи дней для критических уязвимостей, которые активно используются.
Сроки раскрытия информации могут варьироваться в зависимости от поставщиков, исследователей и других организаций. Уязвимости, о которых сообщается в Координационный центр CERT, раскрываются общественности через 45 дней после первого сообщения, независимо от того, выпустили ли затронутые поставщики исправления или обходные пути.
Смягчающие обстоятельства, такие как «активная эксплуатация, угрозы особенно серьезного (или тривиального) характера или ситуации, требующие изменения установленного стандарта», могут повлиять на сроки CERT. В некоторых случаях координационный центр может раскрыть уязвимость программного обеспечения до или после 45-дневного периода.
Процесс раскрытия уязвимости
Хотя формального отраслевого стандарта в отношении сообщения об уязвимостях не существует, раскрытие информации обычно осуществляется в соответствии с одними и теми же основными шагами:
- Исследователь обнаруживает уязвимость системы безопасности и определяет ее потенциальное воздействие. Затем поисковик документирует местоположение уязвимости с помощью фрагментов кода или снимков экрана.
- Исследователь составляет консультативный отчет об уязвимостях с подробным описанием уязвимости, включая подтверждающие доказательства и график полного раскрытия информации. Затем исследователь безопасно отправляет этот отчет поставщику.
- Исследователь обычно дает поставщику разумный период для расследования и исправления уязвимости в соответствии с рекомендуемым сроком полного раскрытия информации.
- После того, как исправление доступно или истек срок раскрытия информации - и любых расширений, исследователь публикует полный анализ уязвимости эксплойта, включая подробное объяснение уязвимости, ее воздействия и решения.
Фирменные уязвимости
Исследователи безопасности начали брендировать свои раскрытия уязвимостей, создавая запоминающиеся названия уязвимостей, специальные веб-сайты и учетные записи в социальных сетях с информацией об уязвимостях. К ним часто относятся научные статьи с описанием уязвимостей и даже специально разработанные логотипы.
Наиболее известные уязвимости последних лет включают следующее:
- ImageTragick, имя, применяемое к набору уязвимостей в библиотеке ImageMagick с открытым исходным кодом для обработки изображений;
- Badlock - недостаток, затронувший почти все версии Windows;
- HTTPoxy, группа уязвимостей в приложениях, использующих прокси-сервер Hypertext Transfer Protocol; а также
- KRACK, атака на аутентификацию Wi-Fi Protected Access 2.
Сообщество по информационной безопасности разделяется во мнениях относительно целесообразности таких усилий. Исследователи, продвигающие брендовые уязвимости, могут рассматриваться как пытающиеся продвинуть свои исследования вне зависимости от того, серьезны ли уязвимости.
У других возникают проблемы с брендингом, когда хорошо поддерживаемые усилия по связям с общественностью об уязвимости отвлекают общественность от других уязвимостей, которые были обнародованы без обширных рекламных кампаний.