Блог

Data breach или что делать если грянул гром?

В одной из предыдущих статей мы уже писали о том, что утечка данных в 21-м веке стала, практически, обычным явлением. Однако, параллельно с «недремлющими» хакерами, продумывающими все новые и новые виды атак, стремительно развиваются направления и меры, которые могут если не ликвидировать, то достойно противостоять «разбою» в интернете. И владельцам онлайн бизнеса стоит об этом знать.

В этой статье Екатерина Мищенко, специалист по защите персональных данных в компании AVITAR, на примере недавнего инцидента об утечке данных компании SoftServ, расскажет о следующем:
- Почему соответствие требованиям законодательства нужно воспринимать не только как конечный результат, но и как процесс?
- Какую роль в ликвидации последствий утечки данных играет Disaster recovery plan (План по ликвидации последствий катастрофы)?
- Что обязаны сделать владельцы информации сразу после «утечки» данных?
- Как проверить, достаточно ли проработан Disaster recovery plan в компании (чек-лист)


Итак,

Гром грянул

1-го сентября произошел дата breach в компании SoftServe. Компания подверглась хакерской атаке, в результате которой были слиты не только клиентские данные, но и персональные данные более 200 сотрудников.


Что делать?

Нужно понимать, что утечка данных, пусть чувствительных и в огромных объемах, - это только вершина айсберга. И, чтобы справиться с последствиями, нужны две вещи: 1. признать, что сама утечка - это не единственная проблема и 2. выявить «первоисточник».


Чем руководствоваться?

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

Самое главное происходит не в момент утечки, а после нее, - в момент, когда владелец данных начинает реагировать на происшествие.

Как реагировать?

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

Компания, которая пытается справиться с последствиями утечки, должна руководствоваться тремя целями: смягчить, расследовать и предотвратить.

Итак, что же обязаны сделать владельцы информации?
  1. Незамедлительно проинформировать пострадавших. Для этого необходимо выяснить степень повреждения систем, какие данные были потеряны, какие есть риски и объяснить, что может произойти.
  2. Предоставить информацию отдельным лицам, а также дать советы или алгоритм действий, чтобы помочь субъектам персональных данных защитить себя от последствий утечки.
Такие советы могут включать в себя:
● Совет по смене паролей
● Совет обратиться в банк с сообщением о том, что пользователь стал жертвой кражи персональных данных, для размещения предупреждение о мошенничестве в личном деле.
● Блокировка банковских счетов и т.д.

Другими словами, советы могут включать в себя любую информацию, которая поможет избежать тех потенциальных проблем, которые выявила компания.
  3. Сообщить подробности.
Первым шагом - объяснить, почему возникла ситуация. Затем признать, была ли вина на стороне компании, и принять на себя ответственность. Компании необходимо смягчить ситуацию и описать решения для пострадавших пользователей.
  4. Объяснять, обучать, приглашать к диалогу
Объясните вашим пользователям, как предотвратить подобные проблемы в будущем. Для этого следует привлечь независимых экспертов не только на этапе расследования, но и в других моментах. Советуем привлечь своих клиентов, отраслевых экспертов, аналитиков, представителей СМИ для более широкого обсуждения источника проблемы.

Остается только надеяться?

Анализируя действия компании SoftServe, можно сказать, что из четырех вышеперечисленных пунктов выполнен только один, да и то – с опозданием (инцидент произошел 1 сентября, официальное заявление компании появилось гораздо позже). До этого, как пострадавшие, так и «вольные слушатели» вынуждены были довольствоваться домыслами и гипотезами.
Кроме этого, в официальных заявлениях нет ничего, что бы прояснило происходящее, или помогло бы их пользователям/сотрудникам. Радует тот факт, что SoftServe привлек третью сторону для расследования инцидента.
Остается надеяться, что внутренняя часть работы с утечкой проходит четко и по требованиям законодательства, и совсем скоро мы узнаем подробности.

Что поможет? «Пройдись» по чек-листу.

Анализируя инцидент, можно сказать: проблемы и утечки происходят у всех, это просто вопрос времени. Главное - оперативная и правильная реакция, ну а чтобы понять проработан ли Disaster recovery plan и поможет ли он в трудную минуту, рекомендуем пройтись по этому чек-листу.
  • У нас есть процесс оценки вероятного риска для отдельных лиц в результате нарушения.
  • Мы знаем, кто является соответствующим надзирательным органом в отношении нашей деятельности по обработке данных.
  • У нас есть процесс информирования затронутых лиц о нарушении, когда это может привести к высокому риску для их прав и свобод.
  • Мы знаем, что должны незамедлительно проинформировать пострадавших.
  • Мы знаем, какую информацию о взломе мы должны предоставить отдельным лицам, и что мы должны давать советы, чтобы помочь им защитить себя от его последствий.
  • Мы документируем все нарушения, даже если о них не нужно сообщать.

Таким образом, если на все пункты вы можете дать утвердительный ответ, можно сказать, что ваш Disaster recovery plan – это не заметка, написанная «для того, чтобы было в наличии», а реальный документ риск-менеджмента, который определяет поведение компании в случае возникновения любых угроз, в том числе, и утечки данных.

Екатерина Мищенко,
специалист по защите персональных данных в компании AVITAR


Статьи по теме:
Risk Management и утечка данных
Утечка данных – «чума» 21 века
Data breach или что делать если грянул гром?
Классификация хакеров
Made on
Tilda