Список слабых паролей, устаревшего программного обеспечения и непроверенных резервных копий еще не объясняет, что компания может потерять. Оценка рисков кибербезопасности связывает эти факты с бизнес-процессами: прерванная продажа, недоступные документы, утечка данных или ошибочная оплата. Руководство нуждается в результатах для выбора действий и распределения ресурсов.
Полезная оценка позволяет создать реестр рисков, согласованные критерии и список решений. Каждая запись должна иметь владельца, подтвержденные входные данные, следующий шаг и дату проверки. Этот процесс может применяться к одному сервису, отделу или всей компании.
Согласуйте цель, объем и участников
Сначала определите решение, которое будет поддерживаться оценкой. Например, оцените готовность к переносу клиентской документации в облако или выявите риски для надежной работы продаж. Укажите системы, данные, сайты и поставщиков, которые подпадают под оценку. Запишите исключения и внешние зависимости отдельно. Исключенная услуга все равно может остановить включенную.
Назначьте координатора оценки и ответственных за процесс. IT подтверждает проект системы и статус безопасности. Сотрудники объясняют, как происходит работа и какие обходные пути они уже используют. Менеджер процесса оценивает последствия и принимает решения в пределах своей компетенции. Если риск превышает эту компетенцию, определите, кто должен его утвердить. Подрядчик может помочь собрать доказательства, но не может заменить владельца бизнес-решения.
Выберите четкий метод оценки и задокументируйте его до заполнения реестра. Руководство NIST помогает организовать подготовку, проведение и обслуживание оценки. Требования отрасли и контракты могут содержать обязательные проверки и доказательства. Простое заполнение шаблона не доказывает, что все применимые требования выполнены.
Собирайте факты и описывайте сценарии
Начните с процессов и связанных с ними активов
Используйте существующий инвентарь оборудования, программного обеспечения и услуг. Достаточно идентификатора актива, его цели, владельца, важных данных и связей с бизнес-процессами для проведения оценки. Добавьте внешние услуги, сотрудников с особыми привилегиями и ручные операции, где результат зависит от них. Не создавайте параллельную копию каждого записи об активе. Свяжитесь с проверенной записью вместо повторного ввода.
Подтвердите информацию из нескольких источников: настройки, журналы, результаты технических тестов, заявки, контракты и обсуждения с владельцами. Записывайте дату и источник каждого доказательства отдельно. Если отсутствует информация о тестировании восстановления, укажите «восстановление не подтверждено», а не «нет резервных копий». Неопределенность требует расследования, а не вымышленный факт.
Соедините угрозу, уязвимость и последствия
Опишите риск как возможное событие с причиной и бизнес-последствиями. «Фишинг» – слишком общее описание. Более полезная запись гласит, что злоумышленник использует украденные учетные данные для доступа к корпоративной электронной почте и подмены платежных данных. Это идентифицирует затронутый процесс, событие и потенциальный ущерб. Другой сценарий – ошибка администратора: удаление общего каталога может привести к простою, если восстановление не сработает.
- Учитывайте внешние атаки, ошибки сотрудников, неправильное использование доступа и ошибки конфигурации.
- Проверьте зависимости от поставщиков, облачных сервисов, электроснабжения и доступности сайта. Учитывайте их при оценке выбранного сценария киберриска.
- Определите последствия для доступности, целостности и конфиденциальности данных. Затем переведите их в виде прерванных операций, затрат, обязательств и влияния на клиентов.
- Разделите события с разными владельцами или вариантами обработки. Вы можете объединить одну и ту же уязвимость в нескольких связанных системах, сохраняя при этом список затронутых активов.
Оцените существующие меры контроля на основе доказательств.
Запишите, что уже снижает вероятность события или серьезность его последствий. Примеры включают многофакторную аутентификацию, ограниченные разрешения, обновления, обучение, сегментацию, логи и проверенные резервные копии. Важность названия меры контроля менее важна, чем ее объем и эффективность в заданном сценарии. Копия без успешного теста восстановления не доказывает, что сервис может быть восстановлен. Установленная защита не доказывает, что она работает на всех необходимых устройствах.
Запишите состояние каждой меры контроля и выявленные пробелы. Статья о приоритетных мерах контроля для регулируемых предприятий объясняет, как внедрить первоначальную защиту. Используйте результаты проверки мер контроля при выборе действий по управлению рисками.
Оцените вероятность и последствия с использованием последовательных критериев.
Три качественных уровня могут послужить отправной точкой. Согласуйте период оценки и характеристики каждого уровня. Не используйте слово «высокий» как рассчитанный процент. Если доказательства ограничены, запишите неопределенность и действие для ее устранения. Ответственный за процесс должен понимать оценку, а не просто считать, что цветная диаграмма убедительна.
|
Уровень |
Вероятность в выбранный период |
Последствия для выбранного процесса |
|---|---|---|
|
Низкий |
Неизвестный доступный путь к событию; проверены ограничения. Оставшаяся неопределенность зафиксирована. |
Работа продолжается с использованием приемлемого обходного пути; влияние остается в пределах согласованных ограничений. |
|
Средний |
Сценарий реалистичен, но зависит от дополнительных условий или частично ограничен контролями. |
Необходимы дополнительные ресурсы или временный альтернативный способ работы; некоторые операции затронуты. |
|
Высокий |
Существует доступный путь, повторяющиеся события или значительные уязвимости в безопасности. |
Критическая операция останавливается, возможны значительные потери данных или финансовых средств, или угрожает выполнение обязательств. |
Эти критерии являются примером, а не универсальным стандартом. Компания должна определить свои критические операции и допустимые потери. Используйте собственные цифры для финансовых сумм, времени простоя и контрактных ограничений. Матрица вероятности и последствий помогает согласовать приоритеты, но одинаковые оценки не делают два риска идентичными. Учитывайте зависимости, масштаб и степень уверенности в доказательствах.
Разделите внутренние, текущие и ожидаемые риски
Если для принятия решения требуется сравнение, оцените сценарий без защитных контролей и отдельно с теми контролями, которые действительно работают. Второй рейтинг можно назвать текущим остаточным риском. Зафиксируйте ожидаемый риск после запланированных изменений отдельно: план не снижает текущий рейтинг. После внедрения и тестирования изменений, переоцените остаточный риск, используя новые доказательства. Не обязательно использовать все три рейтинга для каждой записи. Четко укажите, какие контроли, предположения и факты включены в оценку.
Заполните реестр и выберите следующие действия
Пример обучения содержит три записи с гипотетическими ролями и оценками. Замените их данными из вашей собственной среды. Каждая строка должна описывать один управляемый сценарий, а не всю ситуацию с безопасностью компании.
|
ID и активы |
Угроза и последствия |
Существующие меры контроля |
Вероятность и влияние |
Ответственный за риск |
Следующие действия и проверка |
|---|---|---|---|---|---|
|
R001. Электронная почта для команды по обработке платежей |
Кража доступа позволяет изменить данные для оплаты в переписке; возможна ошибка при оплате. |
Многофакторная аутентификация включена для некоторых пользователей; охват других пользователей не подтвержден. |
Средняя вероятность и высокий потенциальный ущерб. Причина: процесс оплаты зависит от переписки, а объем страхового покрытия неполный. |
Руководитель финансового процесса |
Сотрудник IT проверяет соответствие страхового покрытия; владелец процесса проверяет подтверждение изменений в деталях оплаты. Согласуйте дату и ответственного за каждую задачу в плане. |
|
R002. Общие рабочие файлы |
Удаление или шифрование останавливает подготовку документов. |
Проводятся резервные копии, но успешность восстановления необходимых данных не подтверждена. |
Необходима проверка вероятности; потенциальный ущерб для выбранного критического процесса высок. Неопределенность не заменена числом. |
Владелец процесса подготовки документов |
Организуйте безопасное тестирование восстановления, определите критерий результата и дату. Используйте результат для уточнения оценки и необходимых изменений. |
|
R003. Внешняя бизнес-услуга |
Бывший подрядчик сохраняет доступ к данным и может их изменять или копировать. |
Существует список пользователей, но периодическая сверка с текущими контрактами не назначена. |
Средняя вероятность; влияние зависит от доступных данных и прав доступа. Уточните у владельца. |
Владелец сервиса |
Сопоставьте права доступа с текущими задачами, согласуйте удаление ненужных прав и запланируйте повторную проверку. |
Добавьте ссылки на доказательства, автора оценки и дату, статус, выбранное лечение, исполнителя, срок выполнения и критерий завершения в рабочую базу данных. Владелец риска принимает решение о последствиях; владелец задачи вносит конкретные изменения. Один человек может одновременно выполнять обе роли в небольшой компании, но различать их в записи. Ограничьте доступ к подробной информации о правах и уязвимостях. Предоставьте руководству соответствующий обзор.
Выберите способ управления риском и согласуйте план
- Уменьшите: измените доступ, конфигурацию или процесс, чтобы снизить вероятность или последствия.
- Избегайте: прекратите рискованную операцию или замените способ ее выполнения.
- Распределите ответственность и последствия посредством контракта или страхования, сохраняя при этом свои собственные обязательства и зависимость от поставщика.
- Примите: уполномоченный владелец явно соглашается с оставшимся риском, условиями и датой проверки. Отсутствие бюджета или исполнителя не означает автоматического согласия.
Определите приоритет, ресурсы и сроки, основываясь на последствиях, доступности пути атаки и зависимостях. Назначьте одного владельца и метод проверки для каждой задачи. Если для устранения необходимо прерывание, согласуйте временной интервал, тестирование приложения и возврат к предыдущим настройкам. Если изменение еще невозможно, запишите временный контроль, его ограничения и дату проверки. Если есть признаки того, что инцидент уже произошел, начните согласованный процесс реагирования вместо ожидания завершения оценки.
Проверьте результаты и поддерживайте базу данных
Завершите задачу после проверки ее результата, а не после получения сообщения об установке инструмента. Для риска R002 доказательством будет успешное восстановление необходимых данных в соответствии с согласованными условиями. После проверки обновите статус контроля, оценку оставшегося риска и решение владельца. Если эффект оказался слабее, чем ожидалось, повторно откройте задачу. Сохраняйте историю изменений, чтобы причина переоценки оставалась видимой.
Организуйте периодические проверки на основе критичности и применимых требований. Также необходимо пересмотреть записи после инцидента, изменения поставщика, появления новых доказательств или значительных изменений в доступе или инфраструктуре. Не существует единой обязательной частоты для каждой компании. Автоматическое обнаружение и отчетность могут помочь обновить фактические данные, но назначенные сотрудники должны согласовать последствия, предположения и принятие рисков.
Перед представлением результатов руководству убедитесь, что область охвата понятна, важные сценарии связаны с процессами, существующие меры контроля проверены, критерии последовательны, и неизвестные факторы отмечены. Каждому приоритетному риску необходимо назначить ответственного и принять решение. Каждому действию необходимо назначить исполнителя, установить сроки и критерии проверки. Затем реестр поддерживает работу, а не просто перечисляет тревожные описания.
Если оценка не содержит подтвержденных технических доказательств о состоянии безопасности, обсудите проведение проверки с ответственными лицами через страницу Оценка безопасности. Результаты могут помочь уточнить записи и выбрать обоснованные действия.
