Команда реагирования на инциденты, которая знает, когда вам звонить

Инциденты безопасности являются самым дорогим, разрушительным и унизительным способом обнаружить уязвимость в приложении. Инцидент безопасности означает, что приложение подверглось атаке, которая могла повлечь за собой утечку данных, отказ либо недоступность систем, нарушение целостности данных, несанкционированный доступ или любые другие негативные последствия. Мы как IТ-специалисты должны сделать все возможное для предотвращения всех видов инцидентов, связанных с IТ-безопасностью. Необходимо также быть готовыми к реагированию на инциденты, если к нам обратятся за помощью. Ответные меры в связи с инцидентом безопасности называются реагированием на инцидент (англ. incident response, IR) и включают в себя управление ситуацией и коммуникацией между отделами, расследование произошедшего, снижение ущерба и затрат, устранение проблемы и восстановление систем и данных. Также сюда входят вскрытие инцидента и документирование произошедшего в соответствующем отчете.

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

ЗНАНИЕ ЛУЧШЕ НЕЗНАНИЯ

Алиса вспоминает, как она впервые наняла в отдел информационных технологий студента, который был помешан на безопасности. Он был сыном друга, и его взяли на работу в качестве одолжения. В итоге в первый же месяц он сообщил о шести инцидентах безопасности, что расстроило многих сотрудников IТ-отдела. Алиса отвела молодого человека в сторону и сказала ему: «Пока ТЫ не пришел, у нас никогда не было никаких инцидентов, связанных с безопасностью!» В ответ она услышала следующее: «Они происходили месяцами, а вы попросту о них не знали. Теперь их можно предотвратить. Мы будем в большей безопасности, потому что знаем, что происходит». Алиса была поражена. В начале разговора она собиралась приказать ему прекратить поиски, но поняла свою неправоту. Ведь и правда гораздо лучше знать о чем-то, чем не знать.

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

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

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

В идеальном мире приложения должны регистрировать происходящие события, связанные с безопасностью (предполагаемые инциденты безопасности), и своевременно оповещать о них. По крайней мере один человек должен регулярно просматривать эти сообщения. При наличии операционного центра безопасности (англ. Security Operations Center, SOC) и системы управления информацией о безопасности и событиями безопасности (англ. Security information and event management, SIEM) или другого мониторингового инструмента было бы полезным, чтобы журналы приложений поступали в эту систему. Необходимо объяснить сотрудникам центра, какие оповещения вас интересуют. Нет никакой пользы от оповещений, если их никто не просматривает. Принимать уведомления лучше даже при работе с простым бессерверным приложением, которое запускает электронное письмо, получаемое на следующее утро.

Постоянное совершенствование программы на основе показателей, экспериментов и обратной связи

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

Рассмотрим немного подробнее данную цель.

Метрики

Метрики – это метод измерения чего-либо или полученные результаты измерений.

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

Измерения можно проводить различными способами: использовать систему управления уязвимостями, базу данных, SaaS для бизнес-аналитики или даже обычную таблицу MS Excel.

Вот что следует учесть при сборе метрик.

• Измерения должны проводиться регулярно. Нельзя просто делать это «время от времени»: данные будут неполными.

• Нужно применять метод измерения последовательно. При использовании инструментов DAST и SAST следует использовать оба во всех приложениях. Нельзя применить DAST в одной половине приложений, а SAST – в другой, если хотите иметь возможность сравнить результаты всех приложений и команды. Можно проводить частичные измерения (например, когда измеряется степень покрытия с помощью определенного инструмента, то есть 20 % с помощью SAST и 80 % с помощью DAST), но только если вы учитываете это условие при анализе данных. В этом примере имеется в виду сравнение всех результатов SAST отдельно от результатов DAST или использование статистики охвата для корректировки их значений в наборе данных.

• Шкала измерений также должна быть последовательной. Нельзя сопоставлять яблоки и апельсины. Если один инструмент оценивает уязвимости от 1 до 10, а другой использует значения «низкий», «средний», «высокий» и «критический уровень», то необходимо определить, как перевести одно из измерений в форму другого измерения. Например, низкий уровень – это 2, средний – 4, высокий – 8, критический – 10.

• Необходимо измерять показатели, которые важны, а не метрики тщеславия.

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

Вот примеры показателей, которые могут быть важны для вас.

• Повторяются ли инциденты (по одной и той же причине)?

• Сколько времени требуется для устранения уязвимостей (откат, исправление или устранение)?

• Сколько времени требуется для выявления инцидентов?

• Сколько произошло случаев несоблюдения политики?

• Есть ли ошибки в обработке инцидентов?

• Насколько вы близки к достижению цели по обеспечению безопасности?

• Выполняет ли команда безопасности свои обязанности, определенные соглашением об уровне обслуживания, или другие команды постоянно находятся в ожидании?

• Если проводилось обучение по конкретным уязвимостям, уменьшилось ли их количество?

• Всегда ли соблюдается процедура реагирования на инциденты?

• Стало ли больше сообщений об уязвимостях? Причина в том, что у вас появился новый инструмент (и это хорошо), или в том, что у вас новые сотрудники, которые не прошли обучение (и это плохо)?

Список того, что можно измерить, очень велик. Следует выбирать те метрики, которые помогут достичь целей программы, а не те, которые пускают пыль в глаза.

НАПРАВЬТЕ СВОИ УСИЛИЯ В НУЖНОЕ РУСЛО

Много лет назад, когда Алиса занималась разработкой контента, она пришла в компанию, где измеряли все: каждый клик, каждый пост в социальных сетях, эффективность работы каждого сотрудника. Алиса отвечала за написание статей, которые помогали людям лучше использовать их продукты, и ей нравилась ее работа. Она создавала в два раза больше контента, чем все остальные. Она знала это, поскольку у них были панели мониторинга, где она могла видеть результаты работы всех сотрудников, что одновременно и ободряло, и держало в напряжении. Алиса всегда хотела быть «лучшей» во всем, что делает. Она заметила, что ее коллега получал около 5000 кликов по каждой ссылке, которую он размещал в социальных сетях, а она – в среднем лишь 300–400. Алиса не понимала, что делает не так, – ведь она старалась. Она решила провести еще несколько собственных измерений: в том числе сколько времени люди оставались на странице. Оказалось, что читатели ее коллеги в среднем тратили одну-две секунды на клик, то есть никто не читал ни одной его статьи. Читатели Алисы задерживались в среднем на полторы минуты! Это означало, что почти всегда они читали статью целиком. Воодушевленная Алиса сообщила о результатах своему начальнику, вследствие чего способ публикации контента и место его размещения были изменены, чтобы ее коллега смог привлечь людей, которые будут читать статьи целиком, а у Алисы прибавилось читателей. Беспроигрышный вариант, и все благодаря важным метрикам!