Настоящий CTO: думай как технический директор - Алан Уильямсон

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

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

• Отключение сетевого доступа к серверу/компьютеру или подсети.

• Выключение ресурса (или приостановка, если он виртуальный).

Самое важное во время атаки – это ограничить возможный урон. Это необязательно означает останов всех систем в ущерб бизнесу. Если есть возможность, изолируйте атакуемую область, используя заранее предусмотренные аварийные выключатели, но если такой возможности нет, то безопаснее на какое-то время полностью отключить систему, особенно если вы подозреваете, что скомпрометированы конфиденциальные данные пользователей.

12.8.2. Коммуникация

Коммуникация важна. Если ваше руководство будет знать, что происходит, это обеспечит вам их поддержку и пространство для маневра. Может показаться, что такая коммуникация будет отвлекать, но, как говорилось выше, периодические новости-об-отсутствии-новостей будут держать всех в курсе, а ваша команда сможет сосредоточиться на проблеме.

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

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

Только когда вы определите, каким образом взломщики получили доступ, и устраните слабые места, вы можете быть уверены в том, что после восстановления все не начнется сначала. Иначе вы будете играть в «ударь крота» («whack-a-mole»), думая, что решили проблему, но, как только вы отвлечетесь, она повторится.

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

12.8.3. Устранение последствий нарушения безопасности

Еще одна область, с которой вам, возможно, придется столкнуться, – это последствия нарушения безопасности или кражи данных. В этой ситуации вы должны определить, что было украдено. В отличие от физических активов – похищение которых очевидно, потому что они будут отсутствовать, – цифровые активы можно скопировать, не оставив следов. Будем надеяться, что вы записываете достаточно событий, чтобы следы остались в журналах; иначе как бы вы вообще узнали о краже? В таких случаях часто проводят компьютерно-техническую экспертизу.

Самое безопасное здесь – считать, что злоумышленники забрали все, что было им доступно. После того как вы составили список украденного, определите следующее:

• Кого необходимо уведомить?

• Что сделать, чтобы снизить ущерб от похищения или ценность данных?

• Какие меры безопасности предпринять, чтобы предотвратить дальнейшие кражи?

• Влечет ли кража юридические последствия?

Мой совет – не пытайтесь сделать все самостоятельно. Подключите руководство компании, проконсультируйтесь с юристом и воспользуйтесь услугами сторонних специалистов.

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

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

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

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

Проведите тщательное расследование и представьте его результаты так, чтобы они были понятны нетехническим специалистам. Рассмотрим простую структуру отчета об инциденте из четырех частей: инцидент, выявление, влияние, устранение (IIIR – issue, identify, impact, remedy):

• Инцидент – что произошло и как это произошло.

• Выявление – как вы узнали о проблеме.

• Влияние – последствия инцидента.

• Устранение – действия для прекращения инцидента и устранения последствий.

Отчет IIIR может выглядеть, например, следующим образом:

• Проблема. Через форму на сайте, используемую для изменения адреса пользователя, любой зарегистрированный пользователь мог увидеть адрес любого другого пользователя, просто изменяя через консоль разработчика в браузере значение ID при выполнении запроса к API.

• Выявление. Команда системных администраторов обратила внимание на увеличение количества запросов к API, в итоге они выявили подозрительные запросы к API работы с адресом, выполняемые с одного и того же IP.

• Влияние. С одного IP-адреса, предположительно принадлежащего одному пользователю, была получена информация о примерно 1000 адресов пользователей, прежде чем системные администраторы заблокировали доступ для него. Конкретного пользователя идентифицировать невозможно, потому что в журнале аутентификации пользователей не сохраняется информация о их IP-адресе.

• Устранение. API было доработано, теперь оно возвращает только адрес текущего пользователя, доработка выложена на продакшен. Все остальные API проверяются на наличие аналогичных проблем и дорабатываются. При регистрации событий сеанса пользователя теперь сохраняется IP-адрес. Составлен список всех учетных записей, чьи адреса были просмотрены.

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

12.9. Руководитель направления информационной безопасности (CISO)

Организации растут и расширяются, и в конце концов задачи обеспечения безопасности, организации мониторинга и соответствия требованиям