Перейти к содержанию

Типичные ошибки при оценке киберрисков


Рекомендуемые сообщения

Никто не захочет тратить миллионы долларов на защиту компании, если ущерб в случае инцидента не превысит несколько тысяч. Столь же глупо экономить сотню долларов, если в случае утечки данных счет пойдет на сотни тысяч. Но на основании какой информации можно рассчитать примерный ущерб, который понесет компания в результате киберинцидента? А также саму вероятность такого инцидента?
На конференции Black Hat 2020 двое исследователей — профессор Вейд Бейкер из Политехнического университета Виргинии и Дэвид Северский, старший аналитик в Cyentia Institute, представили свое видение проблемы оценки рисков. Мы решили, что их аргументы достойны внимания.

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

Показательно ли среднее арифметическое?

Многие компании, работающие в сфере информационной безопасности (и мы тут не исключение), время от времени проводят исследования ущерба в результате инцидентов, связанных с потерей данных. В «ключевые находки» обычно попадают средние цифры — потери компаний сопоставимого размера суммируются, а затем делятся на количество учтенных инцидентов. Математически это абсолютно верно, и для громкого заголовка в прессе эта цифра вполне подходит. Но можно ли опираться на нее для расчета рисков?

Если те же данные представить в виде графика, где по горизонтальной оси учитываются суммы потерь, а по вертикальной — количество инцидентов, то становится очевидно, что среднее арифметическое тут вовсе не показатель. В результате 90% инцидентов компании теряют значительно меньше, чем показывает это самое среднее арифметическое.

Если говорить о потерях, которые понесет среднестатистический бизнес, то скорее имеет смысл смотреть на другие показатели — медиану (число, разделяющее выборку на две равные части так, чтобы половина элементов была выше этого числа, а вторая половина — ниже), а также среднее геометрическое (оно же среднее пропорциональное). Большая часть компаний несет именно такие потери. А вот среднее арифметическое может сильно сбивать с толку из-за небольшого количества инцидентов с аномально большими потерями.

Распределение потерь от инцидентов, связанных с утечками данных.

Распределение потерь от инцидентов, связанных с утечками данных. Источник

Средняя стоимость утекшей записи

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

Некоторое время назад по многим сайтам с аналитикой прошла новость о том, что неправильно сконфигурированные облачные сервисы стоили компаниям почти 5 триллионов долларов. Если изучить, откуда взялась такая астрономическая сумма, то становится понятно, что люди, насчитавшие 5 триллионов, просто перемножили количество «утекших» записей и средний ущерб от потери одной записи, полученный в результате исследования Cost of a Data Breach Study 2019, проведенного Ponemon Institute, — 150 долларов.

Но в этом исследовании, во-первых, учитывались далеко не все инциденты, а во-вторых, даже на этой выборке среднее арифметическое не дает четкого представления о потерях, поскольку там учитывались случаи с записями, потеря которых наносила ущерб и в 10 000 долларов, и в 1 цент. Более того, в методологии этого исследования подчеркивалось, что данное среднее значение неверно для инцидентов, в которых было затронуто более 100 тысяч записей. Поэтому перемножать количество всех записей, утекших из-за некорректно сконфигурированных облачных сервисов, на 150 было в корне неправильно.

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

ALT/caption: Зависимость вероятности потерь от количества затронутых в инциденте записей.

ALT/caption: Зависимость вероятности потерь от количества затронутых в инциденте записей. Источник

Эффект «кругов по воде»

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

А количество таких инцидентов с каждым годом увеличивается, поскольку всеобщая «цифровизация экономики» ведет к увеличению взаимной зависимости бизнес-процессов разных компаний. Согласно результатам исследования Ripples Across the Risk Surface, проведенного совместными усилиями RiskRecon и Cyentia Institute, 813 инцидентов такого рода привели к потерям у 5437 организаций. То есть на каждую компанию, допустившую утечку данных, в среднем приходится более четырех компаний, пострадавших от этого инцидента.

Практические советы

Так что экспертам, работающим в сфере оценки киберрисков, имеет смысл прислушаться к следующим советам:

  • Не стоит доверять громким новостным заголовкам: даже если какие-то данные перепечатываются множеством сайтов, это не обязательно значит, что они не ошибочны. Стоит всегда искать источник и анализировать методологию исследователей.
  • Не используйте в оценке рисков результаты исследований, которые вы не понимаете.
  • Не забывайте, что инцидент в вашей компании может повлечь за собой потерю данных и у других организаций. Если утечка произойдет по вашей вине, то они наверняка предъявят претензии, что увеличит ущерб от инцидента.
  • Точно так же не следует забывать, что и ваши данные могут утечь у партнеров и подрядчиков (то есть в инцидентах, на которые вы никак не можете повлиять).

View the full article

Ссылка на комментарий
Поделиться на другие сайты

Пожалуйста, войдите, чтобы комментировать

Вы сможете оставить комментарий после входа в



Войти
  • Похожий контент

    • mamruc
      От mamruc
      Здравствуйте!
      Физически помер сервер с установленным KSC14, есть бекап сервера. На новом сервере устанавливал  KSC с новой базой, при подключении через Веб морду ничего не отображает, через MMC пишет:
      «Операция не может быть выполнена, так как программа инициализируется или деинициализируется»
      Такой статус еже несколько часов.
    • SDDdo
      От SDDdo
      Здравствуйте! Есть внешний HDD диск. Во время загрузки файлов на этот диск произошло непреднамеренное отключение диска из USB разъема. При повторном подключении диска, система не видит диск в проводнике, в диспетчере устройств диск отображается, но с другим именем. В управлении дисками при попытке инициализировать диск выдает ошибку CRC. Возможно ли решить данную проблему своими силами?


    • Austria.unvorsatzlich
      От Austria.unvorsatzlich
      Доброго времени суток,столкнулся с проблемой ошибки подключения Agenta версии 14 к Центру, операционная система на которой стоит агент Линукс а Центр где стоит сервер Виндовс при попытки подключения выдает данное сообщение:
      [root@localhost user]# sudo systemctl status klnagent
      ● klnagent64.service - LSB: Kaspersky Network Agent
           Loaded: loaded (/etc/rc.d/init.d/klnagent64; generated)
           Active: active (running) since Tue 2024-12-10 10:35:07 MSK; 51min ago
             Docs: man:systemd-sysv-generator(8)
          Process: 5100 ExecStart=/etc/rc.d/init.d/klnagent64 start (code=exited, status=0/SUCCESS)
            Tasks: 26 (limit: 9182)
           Memory: 20.6M
              CPU: 36.805s
           CGroup: /system.slice/klnagent64.service
                   ├─5106 /opt/kaspersky/klnagent64/sbin/klnagent
                   ├─5108 /bin/sh /var/opt/kaspersky/klnagent/tmp/klsc-85F0189814E85A37/B48BDCEEFFC7AD12707F1E74F6D09C48
                   └─5109 /opt/kaspersky/klnagent64/sbin/klnagent -d -from_wd
      Dec 10 10:35:07 localhost.localdomain systemd[1]: Starting klnagent64.service - LSB: Kaspersky Network Agent...
      Dec 10 10:35:07 localhost.localdomain klnagent64[5100]: klnagent started
      Dec 10 10:35:07 localhost.localdomain systemd[1]: Started klnagent64.service - LSB: Kaspersky Network Agent.
      Dec 10 10:35:10 localhost.localdomain klnagent[5109]: Product 'Kaspersky Endpoint Security 11.3.0 для Linux' has started    (5B4B4C434F4E4E415050494E53545D202F686F6D6>
      Dec 10 10:35:10 localhost.localdomain klnagent[5109]: Product 'Kaspersky Endpoint Security 11.3.0 для Linux' has started    (5B4B4C434F4E4E415050494E53545D202F686F6D6>
      Dec 10 10:35:10 localhost.localdomain klnagent[5109]: Kaspersky Network Agent 14.0.0.4646 started    (5B4B4C4E41475D202F686F6D652F6275696C6465722F612F632F645F30303030>
      Dec 10 10:35:16 localhost.localdomain klnagent[5109]: Transport level error while connecting to http://192.168.7.9:13291: general error 0x4F8 (Connection has been bro>
                                                            #1272 Transport level error while connecting to http://192.168.7.9:13291: general error 0x4F8 (Connection has be>
    • ГГеоргий
      От ГГеоргий
      в процессе установки на РедОС возникает следующая ошибка

    • ГГеоргий
      От ГГеоргий
      Добрый день!

      Проводим переезд KSC на новую бд
      для этого полностью удалили KSC и ставим с нуля
      KSC будет на WINserv2016
      BD - PostgreSQL 15 на Rocky linux 9 (До этого стояла на WinServ 2016, что не подходило под требования CIS)
      предварительные настройки на стороне BD выполнены
      (а именно: создана бд и учетка к ней, изменен конфигурационный файл и созданы юзеры в смой системе)

      при установке возникает такая проблема

      В процессе установки произошла ошибка: Generic db error: "[42501]`ОШИБКА: нет доступа к схеме public `, LastStatement=`CREATE PROCEDURE "AK_RAISERROR"( ) LANGUAGE plpgsql

      судя по объяснению, проблема в том что у пользователя, под которым я выполняю установку KSC, нет необходимых прав доступа к схеме public в базе данных PostgreSQL.
      однако это не так
      я выполнил создание бд и пользователя:
      CREATE USER "KSCAdmin" WITH PASSWORD 'testpass@123';
      CREATE DATABASE "KAV" ENCODING 'UTF8';
      GRANT ALL PRIVILEGES ON DATABASE "KAV" TO "KSCAdmin";
      затем перешел в саму БД KAV и выполнил:
      GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA "public" TO "KSCAdmin";
      GRANT ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA "public" TO "KSCAdmin";

      вывод терминала:

      [admin@localhost ~]$ sudo psql -U KSCAdmin KAV
      [sudo] пароль для admin:
      Пароль пользователя KSCAdmin:
      psql (15.8)
      Введите "help", чтобы получить справку.

      KAV=> GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA "public" TO "KSCAdmin";
      GRANT
      KAV=> GRANT ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA "public" TO "KSCAdmin";
      GRANT
×
×
  • Создать...