Rambler's Top100
Блоги Алексей ЛУКАЦКИЙ

Утечка из Marriott/Starwood или 10 ошибок при уведомлении об инциденте

  25 декабря 2018 Страница персоны
30 ноября Marriott International анонсировала, что неизвестные хакеры (позже появилась информация, что следу ведут в Китай, в государственные шпионские структуры) смогли взломать систему резервирования сети отелей Starwood, принадлежащей Marriott, и в течение 4 лет (еще до поглощения сети Starwood сетью Marriott) смогли украсть данные около полумиллиарда постояльцев, что может обойтись компании в десятки миллиардов долларов потерь. Цифра эта взята не с потолка. Marriott пообещала компенсировать смену паспорта тем, чьи паспортные данные могли утечь, а это без малого 327 миллионов постояльцев. При стоимости замены паспорта в 100$ компенсация может составить около 30 миллиардов долларов. Стоимость акций Marriott за последние две недели упала с 122 до 104 долларов, что тоже не самым лучшим образом сказывается на финансовом положении Marriott, которая вынуждена расплачиваться за проблемы Starwood, которую взломали еще до слияния с Marriott (тут, кстати, встает вопрос качестве Due Dilligence и делался ли при покупке аудит безопасности).

Как частый путешественник я тоже пользовался сетью Starwood и допускаю, что мои данные тоже попали в список утекших. Точного ответа на этот вопрос у меня нет. Все, что я пока имею, это письмо от пострадавшей компании, в котором описан инцидент. Судя по нему, а также по специально созданному для этого инцидента сайту, компания, которая еще 8 сентября узнала об инциденте до сих пор не может понять, чьи данные пострадали, так как украденный массив данных был зашифрован и Marriott пытается его расшифровать, чтобы понять, что все-таки утекло (только ли контактная информация и номера кредитных карт или еще и данные по проживанию). Получил я уведомление об инциденте 12 декабря, спустя две недели после анонса со стороны Marriott. Понимаю, что отправить 500 миллионов сообщений - задача непростая, но, как клиент Marriott, мне бы хотелось, чтобы гостиничная сеть была более оперативной. Две недели неведения - не самое лучшее время.

А пока я жду хоть какой-то ясности, я решил составит перечень типовых ошибок, которые делают компании, которые сталкиваются с инцидентом ИБ. Кстати, эта тема хорошо ложится на тему штабных киберучений, в рамках которых можно прекрасно отработать навыки коммуникаций во время серьезного инцидента ИБ. Итак, на мой взгляд, перечень типовых ошибок выглядит следующим образом:
  1. Скрытие инцидента. "Про то, что нас взломали, никто не узнает. Поэтому скроем это от всех". Это реально одно из самых типовых заблуждений, которое я нередко слышу во время киберучения или при встречах с заказчиками. Но, как показывает опыт, в последнее время с инцидентами сталкиваются все и поэтому глупо рассчитывать на то, что это удастся оставить в секрете. Вспоминая высказывание гендиректора Cisco Джона Чемберса (хотя это говорили многие): "Есть два типа компаний - те, кого уже взломали, и те, кто еще об этом не знает".
  2. Рассмотрение инцидента как ИТ-проблемы. "Это не проблема ИБ - это сбой в ИТ-системе". "Наш сайт не работает не из-за DDoS-атаки, а из-за блокировки Роскомнадзора". "У нас плановое обновление ПО". "У нас регламентные работы и поэтому система не позволяет переводить денежные средства". После скрытия инцидента, это вторая по популярности ошибка, которую допускают многие.
  3. Атака русских|китайских|иранских|северокорейских хакеров. Я не понимаю, чем это отмазка лучше других, но и она нередко звучит, когда надо переложить ответственность на кого-то, снимая ее с себя. Кто бы вас не атаковал, выстраивание системы защиты - это ваша обязанность и при моделировании угроз и нарушителей надо предусматривать такие вещи. Тем более, что используют и государственные, и обычные хакеры типовые методы. Миф о каких-то секретных знаниях "хакеров в погонах" сильно преувеличены, судя по всем обвинениям, которые сыпатся в последнее время против России, Китая, Северной Кореи или Ирана.
  4. Отсутствие плана. Самое худшее, чтобы понять как реагировать на инцидент, выяснять это во время инцидента. Когда проводятся киберучения - основная их задача - подготовиться к плохому и нештатному. И все это надо внести в план, в котором надо ответить на 4 ключевых вопроса - кто будет сообщать об инциденте, какую информацию, кому и когда. Клиенты? Подрядчики и партнеры? Правоохранительные органы? СМИ? Уполномоченные органы по защите прав субъектов ПДн (в письме Starwood указаны адреса всех европейских DPA, что является требованием GDPR, но, кстати, нет РКН)? Кто должен входить в команду, отвечающую за сообщение об инциденте? Маркетинг, PR, юристы…
  5. Преуменьшение инцидента. Не пытайтесь скрывать инцидент или вводить аудиторию в заблуждение. Мало того, что это не удастся, так это еще может быть и незаконно в разных странах мира (если у вас клиенты не только в России). Сокрытие может повлечь за собой дополнительные иски и ущерб репутации. Тот же Marriott поступил достаточно честно, сразу уточнив, что речь идет о 500 миллионов гостей Starwood. Да, это неприятно, но зато честно. А если бы они сообщили об утечек 50 миллионов и потом всплыли факты про еще 450 миллионов, то это было бы крайне негативно воспринято всеми. Можно попробовать заявить, что масштаб инцидента не понятен, но кто знает, как это обернется в будущем. Хотя тот же Facebook, когда у него утекло вроде как данные 50 миллионов учетных записей, заявил, что они не знают о реальном масштабе бедствия. 
  6. Задержка с уведомлением. Equifax и Marriott сообщили об инциденте спустя два-три месяца с момента его обнаружения. Вообще затягивать с этим не стоит. Скорость и четкость при инциденте имеют важнейшее значение. Часто задержка связана с тем, что жертва просто не понимает, что у нее пострадало; она не знает свой бизнес, свою инфраструктуру; а инвентаризацию проводило очень давно. Иногда это происходит потому, что службы ИБ или ИТ тратит много времени на расследование, не сообщая об инциденте руководству компании и не следуя плану реагирования и уведомления (если план вообще есть). В любом случае любая задержка должна быть обоснована и обусловлена требованиями правоохранительных органов (если вы обращаетесь к ним) или иными юридическими требованиями. Понятно, что и бежать в тот же день раскрывать все карты не стоит - нужно собрать достаточно информации, чтобы не выглядеть попкой, непонимающим, что происходит. Кстати, с уведомлением тоже есть отдельные нюансы. Marriott о своем взломе сообщил 30-го ноября, а я получил от них письмо только 12-го декабря. С чем это может быть связано? Представьте, что вам надо направить 500 миллионов уведомлений! Вы же сразу попадете во всем спам-базы и вас будут блокировать все средства защиты. Поэтому надо либо отправлять небольшими порциями, либо договариваться с владельцами соответствующи сервисов, чтобы вас не блокировали на время массовой рассылки. 
  7. Распространение слишком малого объема информации. Цель публичного уведомления об инциденте - не покаяться, а помочь клиентам защитить себя. Поэтому делитесь тем, что им поможет в этом. Если вас уведомили об инциденте, но не сказали, что делать, вы будете разочарованы. Marriott в своем письме предложил вот такой перечень (помимо контактов с DPA, правоохранителями, бесплатного доступа к WebWatcher /если вы гражданин США, Канады и Великобритании/ и компенсации замены паспорта):
  8. Распространение слишком большого объема информации. Мало информации - плохо. Много информации... Тоже плохо. Нужно найти баланс и раскрыть только то, что принесет пользу вам, вашим клиентам и акционерам. Не надо раскрывать то, что может навредить другим компаниям. Например, Equifax сразу раскрыла, что это кредитное бюро взломали через уязвимость в Apache Struts. Это заставило многих компаний понервничать, так как у них тоже была эта уязвимость и она не была устранена. Это давало хакерам преимущество. Вообще кейс с Equifax на сегодняшний день уже стал хрестоматийным - немалое количество отчетов на десятки страниц посвящено этой утечке. В разрабатываемом плане коммуникаций по результатам инцидентов надо указать, кому и в каком объеме должна быть представена информации. Понятно, что правоохранительным органам надо представить информации больше, чем для прессы. Клиентам нужны рекомендации по снижению ущерба, а агентству по расследованию инцидентов (Marriott, например, пригласил Kroll) эта информация без надобности. 
  9. Невзаимодействие с правоохранительными органами. В России не так уж и принято взаимодействовать с органами внутренних дел в случае того или иного инцидента. Недоверие к полиции и неверие в ее компетентность приводят к тому, что все пытаются с инцидентами бороться самостоятельно (исключая те случаи, в которых может понадобиться решение суда). На Западе ситуация иная - поэтому там как раз рекомендуется активно взаимодействовать с правоохранительными органами. И они во многих случаях сами расскажут, что раскрывать, а что нет, чтобы не навредить следствию. У вас всего один шанс, показать, что вы сделали все, что нужно для защиты себя и своих клиентов. Обращение в правоохранительные органы (как и привлечение какой-либо известной компании для расследования) - хороший тон и демонстрация того, что вы ответственно действуете в соответствие с лучшими практиками.
  10. Отсутствие киберучений :-) Да, это не совсем связано с уведомлением об инциденте ИБ, но именно отсутствие киберучений часто приводит к тому, что описанные выше девять ошибок совершаются. В процессе имитации реальных кейсов проявляются все подводные камни и формируются пункты будущего плана реагирования на инциденты и плана коммуникаций в случае их наступления.
ЗЫ. Почти три года назад я уже обращался к теме коммуникаций с внешним миром. Правда, тогда, я проводил аналогии с допинговыми скандалами в российском спорте. И как показали прошедшие годы я был прав. Шарапова вернулась в спорт, а остальные участники, описанные в заметке, - похоже нет. Так что даже в случае с произошедшем инцидентов можно извлеь правильные уроки и повернуть историю себе во благо. Было бы желание.

Поделиться:

Оставить свой комментарий:

Для комментирования необходимо авторизоваться!

Комментарии по материалу

Данный материал еще не комментировался.