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

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

Опубликовано

Никто не захочет тратить миллионы долларов на защиту компании, если ущерб в случае инцидента не превысит несколько тысяч. Столь же глупо экономить сотню долларов, если в случае утечки данных счет пойдет на сотни тысяч. Но на основании какой информации можно рассчитать примерный ущерб, который понесет компания в результате киберинцидента? А также саму вероятность такого инцидента?
На конференции 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

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

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



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

    • DOorDIE
      Автор DOorDIE
    • Гоменюк Антон
      Автор Гоменюк Антон
      Доброго дня, при попытки установить антивирус Касперского выскакивает неизвестная ошибка.
      kavremvr 2024-01-07 23-23-14 (pid 20384).log kavremvr-srvc 2024-01-07 23-23-16 (pid 10796).log
    • Staryu
      Автор Staryu
      Сидел я около компьютера и тут он резко выключился. Потом включился и вошел в режим выбора запуска, я загрузился в безопасном с поддержкой сети. Не могу понять это майнер или просто ошибка какая-то, т.к. вроде видел майнер с таким именем. Вот коды ошибки.
      Имя журнала: System Источник: klbackupdisk.K4W-21-16 Дата: 10.02.2024 15:23:15 Код события: 0 Категория задачи:Отсутствует Уровень: Ошибка Ключевые слова:Классический Пользователь: Н/Д Компьютер: Yana-DNS Описание: Не удается найти описание для идентификатора события 0 из источника klbackupdisk.K4W-21-16. Вызывающий данное событие компонент не установлен на этом локальном компьютере или поврежден. Установите или восстановите компонент на локальном компьютере. Если событие возникло на другом компьютере, возможно, потребуется сохранить отображаемые сведения вместе с событием. К событию были добавлены следующие сведения: Driver initialization has failed Xml события: <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> <System> <Provider Name="klbackupdisk.K4W-21-16" /> <EventID Qualifiers="0">0</EventID> <Level>2</Level> <Task>0</Task> <Keywords>0x80000000000000</Keywords> <TimeCreated SystemTime="2024-02-10T08:23:15.116009900Z" /> <EventRecordID>571759</EventRecordID> <Channel>System</Channel> <Computer>Yana-DNS</Computer> <Security /> </System> <EventData> <Data> </Data> <Data>Driver initialization has failed</Data> <Binary>00000000020028000000000000000000000000005F0300C000000000000000000000000000000000</Binary> </EventData> </Event>  
       
       
      Имя журнала: System Источник: Microsoft-Windows-Kernel-Power Дата: 10.02.2024 15:23:16 Код события: 41 Категория задачи:(63) Уровень: Критический Ключевые слова:(2) Пользователь: система Компьютер: Yana-DNS Описание: Система перезагрузилась, не завершив полностью работу. Эта ошибка может быть результатом того, что система перестала отвечать, произошел критический сбой, или неожиданно отключилось питание. Xml события: <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> <System> <Provider Name="Microsoft-Windows-Kernel-Power" Guid="{331C3B3A-2005-44C2-AC5E-77220C37D6B4}" /> <EventID>41</EventID> <Version>2</Version> <Level>1</Level> <Task>63</Task> <Opcode>0</Opcode> <Keywords>0x8000000000000002</Keywords> <TimeCreated SystemTime="2024-02-10T08:23:16.176811800Z" /> <EventRecordID>571760</EventRecordID> <Correlation /> <Execution ProcessID="4" ThreadID="8" /> <Channel>System</Channel> <Computer>Yana-DNS</Computer> <Security UserID="S-1-5-18" /> </System> <EventData> <Data Name="BugcheckCode">0</Data> <Data Name="BugcheckParameter1">0x0</Data> <Data Name="BugcheckParameter2">0x0</Data> <Data Name="BugcheckParameter3">0x0</Data> <Data Name="BugcheckParameter4">0x0</Data> <Data Name="SleepInProgress">false</Data> <Data Name="PowerButtonTimestamp">0</Data> </EventData> </Event>  
       
       
      Имя журнала: System Источник: EventLog Дата: 10.02.2024 15:23:22 Код события: 6008 Категория задачи:Отсутствует Уровень: Ошибка Ключевые слова:Классический Пользователь: Н/Д Компьютер: Yana-DNS Описание: Предыдущее завершение работы системы в 15:22:07 на ‎10.‎02.‎2024 было неожиданным. Xml события: <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> <System> <Provider Name="EventLog" /> <EventID Qualifiers="32768">6008</EventID> <Level>2</Level> <Task>0</Task> <Keywords>0x80000000000000</Keywords> <TimeCreated SystemTime="2024-02-10T08:23:22.000000000Z" /> <EventRecordID>571761</EventRecordID> <Channel>System</Channel> <Computer>Yana-DNS</Computer> <Security /> </System> <EventData> <Data>15:22:07</Data> <Data>‎10.‎02.‎2024</Data> <Data> </Data> <Data> </Data> <Data>17918</Data> <Data> </Data> <Data> </Data> <Binary>E807020006000A000F00160007005B01E807020006000A000800160007005B01600900003C000000010000006009000000000000B00400000100000000000000</Binary> </EventData> </Event>  
    • Hares
      Автор Hares
      Доброго дня скачал avbr потому что не устанавливал я касперский запускал из всех режимов не помогло скачал FSRT64 логи создались
      FRST.txt Addition.txt
    • ежице
      Автор ежице
      здравствуйте, хочу поинтересоваться. После полной проверки мне выдало, что все нормально, но при просмотре отчета были 5 файлов с ошибкой обработки. С этим надо что-то делать?
×
×
  • Создать...