Поскольку тема горячая, я не буду называть конкретные имена. Все персонажи вымышлены, любые совпадения случайны, за исключением самих событий.
Что случилось
В марте этого года произошел массовый сбой в инфраструктуре одного из крупнейших облачных провайдеров. Судя по открытым источникам, более 1 млн. виртуальных машин стали недоступны, клиенты потеряли доступ к сервисам, данным и резервным копиям — последние были уничтожены или зашифрованы. Авария затронула сразу три физических дата-центра — это, скажу я вам, довольно серьезно.
Что послужило причиной аварии? На этот счет успели высказаться различные эксперты: одни считают, что всему виной хакерская атака, другие ссылаются на массовый сбой в оборудовании, третьи не устают повторять о пресловутом человеческом факторе.
Люди, оборудование? Однозначно могут стать слабым звеном. Хакерская атака? Вполне — за последний год в целом возросло количество киберугроз. Хакеры активно атакуют объекты критической инфраструктуры: транспортные системы, системы связи, банки. Неудивительно, что крупные облачные провайдеры тоже становятся мишенью.
Почему мог произойти инцидент – делюсь своим непредвзятым мнением
Давайте разбираться, как компании невольно «помогают» киберпреступникам и где в целом могут прятаться потенциальные уязвимости: от аппаратного обеспечения и несвоевременных обновлений до управленческих просчетов.
Ошибки руководства
Практика показывает, что большинство инцидентов в мире зачастую связаны с проблемами безопасности. К сожалению, эти проблемы далеко не всегда решаются силами исключительно безопасников.
Серьезный инцидент редко происходит на пустом месте — как правило, ему предшествует целый ряд ошибок топ-менеджмента. То есть людей, которые, в общем-то не должны понимать в ИБ, но за которыми остается последнее слово в принятии решений. Вот несколько вариантов «классических» просчетов в оценках «топов»:
Проекционные искажения
Популярное отношение к рискам в сфере ИБ у руководства: «Если предыдущие три — пять лет нас не взламывали, значит, и сейчас не взломают». А вот и нет. С точки зрения математической логики это неверно. Наоборот, чем дольше у вас не было инцидентов, тем выше вероятность, что сейчас что-то «прилетит».
Подобный тип когнитивных искажений часто встречается среди инвесторов. Они вкладывают средства в акции определенной компании, потому что те росли и приносили прибыль в прошлом. Однако прошлый успех не гарантирует будущую прибыльность, что может приводить к убыткам — с ИБ дело обстоит примерно так же.
А я ничего не буду. Я экономить буду
Информационная безопасность — это больно (для бизнеса). Разумеется, руководство хочет сэкономить, особенно когда речь идет об «обслуживающем» направлении, которое не приносит компании денег. А стоит недешево — порой кратно дороже затрат на инфраструктуру:
Вот кейс из жизни. Приходит в одну из моих прошлых компаний клиент и говорит: «У меня небольшая информационная система, сайт. Можно мне все сделать, чтобы по 152 ФЗ?» Инфраструктура стоит меньше 20 тыс. Стоимость ИБ — 140 тыс. Поэтому, когда мы говорим, что ИБ дорогая — это объективно. В России она даже выше, чем по миру, потому что наши вендоры живут изолированно и не испытывают внешней конкуренции.
К сожалению, специалисты-безопасники не всегда могут на языке бизнеса объяснить управленцам, зачем и на что тратить такие деньги. А ведь можно показать: «Да, разница в 120 тысяч, но смотри, выручка сайта — NNN рублей в день, а тут всего 140 тыс. в месяц будем отдавать, чтобы он работал». Еще один вариант доходчиво объяснить, зачем нужно раскошелиться на ИБ — прикинуть, во сколько примерно обойдутся компании час, сутки, неделя простоя — а то и полная потеря инфраструктуры. Конечно, в обоих случаях безопаснику придется провести подсчеты, пусть и грубые, возможно — пообщаться с экономистами, но в целях защиты своей позиции оно того стоит. Кстати, отсюда вытекает и следующий просчет:
Если что, во всем виноват безопасник
Это популярная позиция в компаниях, причем как в России, так и за рубежом. Только вот проблема не в том, что директор по ИБ как-то неправильно выстроил систему защиты, а в том, что он ее местами просто не смог организовать — потому что недостаточно убедительно презентовал свои идеи бизнесу. В некоторых случаях помогает образное мышление.
Недавно в разговоре с директором по персоналу речь зашла об инциденте с облачным провайдером. HR-директор явно не впечатлилась масштабом угрозы, пришлось прибегнуть к сравнению: «А вот представь, что у тебя один из инструментов — это зуб. И его сейчас не будет — из-за инцидента ИБ. Причем, скорее всего, зуб не восстановят». Потерять часть тела, даже не жизненно важную — это серьезно. И не-айтишникам из руководства такая аналогия гораздо понятнее, чем сообщение о «сферических угрозах в вакууме».
Патчи и их подводные камни
А вот распространенное заблуждение менеджеров: если вы перешли в облако, то с точки зрения ИБ все в порядке — потому что теперь это задача провайдера. Действительно, если архитектура облака выстроена разумно, можно обойтись без каких-то серьезных и узкоспециализированных инструментов защиты. Но, чтобы инфраструктура хорошо работала, нужен патчинг. А это — головная боль для любого айтишника и специалиста по ИБ.
Кто и что должен патчить?
Есть разные модели предоставления сервиса (IaaS, PaaS, SaaS), в каждой из них у провайдера своя зона ответственности, работает принцип: «Кто за что ответственный, тот и должен это обновлять». IaaS-провайдер актуализирует железо и среду виртуализации. А виртуальные клиентские машины будут уже вне зоны его ответственности. Поэтому он будет в меньшей степени обеспечивать патчинг — у него и без того задач полно.
У PaaS-провайдера уже появляется обязанность выкатывать «заплатки» для той платформы, к которой он предоставляет доступ. Например, PaaS-провайдер будет отвечать за обновление условного Kubernetes. Ну а если мы говорим про SaaS, то там провайдер должен патчить все.
Как часто патчить?
Тут мнения специалистов по ИТ и ИБ точно расходятся. Безопасник скажет: надо патчить чаще, иначе быть беде, 95% инцидентов ИБ не было бы, если бы все патчились вовремя. И будет прав: согласно данным аналитиков, значительная часть облачных активов провайдеров и клиентов обновляется лишь раз в полгода. Уязвимости долгое время остаются неисправленными, что отражается на безопасности инфраструктуры и ведет к взломам.
ИТ-спец возразит: работает — не трогай. Во-первых, потому что патчинг решает проблему фрагментарно — закрывается один вопрос, появляются другие (одно лечим, другое калечим). Во-вторых, потому что установка обновлений — это деградация или даже прерывание сервиса.
Например, если у нас в кластере 20 хостов, и мы обновляем их по одному, все проходит незаметно для системы. Но бывает так, что один кластер состоит из 3 хостов, и если мы выводим один на обновление, то теряем треть мощности. А обновление SaaS вообще создает перерыв в работе, причем его длительность не всегда удается точно спрогнозировать — возможно, после обновления придется восстанавливать сервис. Само собой, провайдеры этого не любят — нужно уведомлять клиента, тот может быть не согласен или не готов «потянуть» сопутствующие риски.
Как найти золотую середину?
С точки зрения ИБ — отслеживать выход обновлений, не отключая критическое мышление. Всегда важно оценивать, применимо ли обновление к текущим условиям работы сервиса.
Например, недавно вышла уязвимость для коммутатора Cisco, очень критичная — в отсутствие патча можно зайти без пароля и все удалить. Стали разбираться — оказалось, что для взлома на этом коммутаторе должен быть запущен веб-сервис, чтобы к нему можно было сразу подключиться. А у нас его нет. Поэтому вместо того, чтобы сломя голову бежать за обновлением, мы можем спокойно распланировать, как и когда его провести.
И обратный пример: мы обнаружили, что наша версия почты уязвима, она есть в интернете и всем доступна. Более того, в открытом доступе существует инструмент для эксплуатации этой уязвимости. В такой ситуации счет идет на часы. И лучшая практика — не слушать никого, кто переживает, что почта не будет работать час, и проводить обновление как можно быстрее.
И еще один важный момент: у безопасника всегда должен быть план Б — что делать, если все пойдет не так, как откатываться, возвращаться к предыдущей версии.
Вызовы импортозамещения
Все, о чем мы говорили выше, работало до 2022 года. В марте 22-го безопасники на время приостановили обновления — все понимали, что могут прилететь «закладки». Их и находили, в основном в open source.
НКЦКИ (Национальный координационный центр по компьютерным инцидентам) в своем бюллетене также подчеркивал: «В связи со сложившейся обстановкой и введенными санкциями против Российской Федерации рекомендуем устанавливать обновления программного обеспечения только после оценки всех сопутствующих рисков».
А дальше накопился ворох проблем. Одно дело, если обновляешься регулярно, но когда тебе за раз надо десять патчей поставить — это страшно. Обновляться необходимо, но сейчас приходится делать это с повышенным вниманием ко всем деталям. Работать в прежнем режиме уже невозможно, и те, кто игнорирует этот факт, могут стать героями новостей об очередной атаке.
Как дела с переходом на отечественные решения
На этот счет в профессиональной среде есть несколько мнений. Два года назад во многих классах средств защиты информации (защита инфраструктуры, сети, данных, приложений, пользователей, конечных точек) доминирующую позицию занимали западные, американские вендоры, потому что их продукты были объективно лучше.
К настоящему моменту разрыв между отечественными и западными разработками уменьшился, но будем честны — за рубежом не стоят на месте. Российские компании догоняют, но в большинстве направлений все еще позади.
Здесь перед безопасниками встает непростой выбор. Можно оставлять западные системы и параллельным импортом получать на них обновления, новые сигнатуры и так далее. Да, продукт рабочий и надежный. Но в случае чего тебя по головке не погладят: например, если случится инцидент, и во время разбирательства узнают, что в компании использовалось решение западного вендора.
Можно импортозамещаться — принимая риск снижения качества средств защиты. К сожалению, многие отечественные разработчики подобных систем думают, что сейчас важнее получить сертификат ФСТЭК, нежели сокращать технологический отрыв. Их позиция понятна: сертификат дает возможность хорошо продаваться на конкурсах, получить государственное субсидирование. Но при таком подходе реальный функционал ИБ становится вторичным. И наоборот, если у компании нет сертификата, с ней могут отказаться работать — даже несмотря на высокое качество инструмента.
Почему все (пока) плохо
В РФ мало профильных разработчиков. Людям непонятно, зачем идти в сложнейшую сферу, где нужно понимать очень много предметных зон, если можно сосредоточиться на сайтах или 1С, и входить в число самых обеспеченных людей России. Да, есть вендоры, готовые нанять супер-разработчиков систем защиты информации и платить им достойные деньги, но на рынке таких специалистов нет.
А тем временем топ-вендоры из Кремниевой долины собирают команды мечты, нанимают программистов со всего мира. За счет пиара, мягкой силы они могут позволить себе привлекать топовых специалистов — например, из той же Индии, где хорошая ИТ-школа, при этом фактически нет языкового барьера, на сносном английском говорят все.
Еще один важный момент: вопрос мотивации и правильного позиционирования. Можно просто выполнять поставленную задачу, а можно работать над проектом, который реально сделает мир лучше.
На западе, например, популярны схемы с долевым участием разработчиков в бизнесе. За свой труд сотрудники получают акции, опционы или иные формы вознаграждения — согласно договору и утвержденной схеме выплат. Чем дольше человек работает в компании, тем больше вознаграждение. Многие представители Кремниевой долины предлагают получить акции уже в первый год работы. Получается, что человек не просто трудится за зарплату, а становится полноценным совладельцем проекта и может влиять на его развитие. Такой подход мотивирует не просто делать хорошо, а делать так, чтобы компания росла.
Но есть приятное обстоятельство
Ситуация, сложившаяся в настоящее время на рынке — это своего рода палка о двух концах. С одной стороны, западные вендоры действительно разрабатывают более качественные продукты. С другой, российские решения, возможно, могли бы сравниться с ними, будь у них такая же обширная пользовательская база: все пользователи отчасти участвуют в развитии продукта — дают фидбэк, ловят баги, оперативно сообщают об этом, в общем, способствуют выпуску обновлений.
В этом плане добровольно-принудительный переход на отечественное ПО дает толчок для развития продуктов. И заинтересованные вендоры в таких условиях реально могут быстрее сократить отставание от иностранных коллег.
Еще одна перемена к лучшему, случившаяся после 2022 года, — «потепление отношений» между айтишниками и безопасниками. «Опять эти душнилы не дают спокойно работать», — такого стало намного меньше. Раньше, когда безопасники предупреждали о рисках, а случаи инцидентов были единичными, айтишники смотрели на ИБ сквозь пальцы. Но за последние пару лет ситуация резко изменилась, и вопросы информационной безопасности перестали быть формальностью, так что предвзятое отношение к нашей сфере начало меняться.
Старое железо
Еще одна статья расходов, на которой компании любят экономить во вред безопасности — оборудование. С точки зрения ИБ, оборудование можно использовать, если оно поддерживается вендором: на него выходят патчи, новые фичи и так далее. Высококритичные системы по всем правилам должны размещаться на оборудовании, которое находится в процессе поддержки.
С другой стороны, если железу, условно, пять лет, но оно в рабочем состоянии, и по нему приходят обновления и сигнатуры, работать с ним будет допустимо. А вот если цикл поддержки со стороны производителя закончился — беда.
И все же, в вопросах старого оборудования даже безопасники ратуют за практичность: его можно использовать, если ограничить сферу применения. Например, можно создать отдельный дешевый кластер с низким SLM (Service Level Management). Честно сказать клиентам: да, оборудования старое, SLA «дохленький», но может подойти для тестовой среды. Еще вариант: старый, в текущих реалиях не очень быстрый SSHD. Стоят они дорого, поэтому сразу расставаться с оборудованием жалко. Но можно его поставить на бэкап.
Человеческий фактор
И все же несвоевременные патчи, «муки и радости» импортозамещения, старое железо и заблуждения руководства отходят на второй план, когда на сцене появляется человеческий фактор. Например, в прошлом году компания Toyota столкнулась с серьезной утечкой персональных данных клиентов. Специалист ИТ-отдела ошибся в конфигурации облачной среды, сделав ее общедоступной. В дополнение ко всему у компании не было механизмов, которые могли бы выявить уязвимость, поэтому проблему заметили далеко не сразу.
С похожей ситуацией столкнулись в турецкой авиакомпании Pegasus. Администратор забыл установить пароль на объектное хранилище S3, развернутое в облаке провайдера. В результате все желающие могли ознакомиться с конфиденциальными данными о полетах.
К сожалению, этот риск невозможно свести к нулю. Суперсовременные системы защиты бесполезны, если сотрудник компании добровольно открывает злоумышленникам «дверь».
Такое случается даже в сфере IaaS. В моей практике были случаи, когда клиент уровня международных компаний приходил в облако, разворачивал уже не поддерживаемый Windows и выставлял RDP наружу — после чего клиента, ожидаемо, взламывали. Все равно, что в доме с высоким забором и крутой охранной системой оставить открытой калитку — и удивляться тому, что в нее прошли посторонние.
Кейс глупый, но совершенно не уникальный. Причем это чрезвычайно заметная с точки зрения злоумышленника вещь, которая очень быстро им обнаруживается. Разверни сервер за самым современным экраном, выставь его по RDP в интернете и отсчитывай, когда к тебе зайдут «в гости». В среднем достаточно 12–14 часов.
Убрать влияние человеческого фактора невозможно, но можно его минимизировать. Вот что я предлагаю:
Использовать чек-листы
Хорошие провайдеры предоставляют своему клиенту чек-лист, чтобы убедиться, что клиент все правильно настроил. В кейсе Toyota такой мануал тоже был, но, видимо, им не стали пользоваться и допустили ошибку (человеческий фактор победил).
Толковый мануал рассказывает, как те или иные настройки сервиса влияют на безопасность и что сделать, чтобы ее повысить. Он же позволяет очертить зону ответственности клиента.
Проводить непрерывную работу с персоналом
Это могут быть, например, курсы по фишингу с отчетами руководителю: кто из сотрудников не прошел тест, повелся на атаку. Задача такого курса — не напугать, а научить.
По результатам курса формируется отчет, в нем можно посмотреть, как проявил себя тот или иной сотрудник: открыл ли человек письмо, кликнул ли по ссылке, ввел ли свой пароль. Это полезный опыт даже для «прожженных» знатоков — чтобы попасться на удочку, достаточно совсем ненадолго потерять бдительность. Например, увидеть «замануху» в новом контексте — не с рабочего компьютера, а с экрана телефона.
Такой опыт помогает сотрудникам увидеть, как на практике может выглядеть современный фишинг, столкнуться с примерами атак в разных ситуациях и сценариях — и правильно повести себя в случае реальной угрозы.
Параллельно очень важно работать над имиджем безопасников в компании (сообща — силами топ-менеджмента, HR, и, конечно, самих безопасников). Нельзя создавать ИБ-отделу репутацию репрессивного органа, задача которого — наказать нерадивых коллег. Наоборот, специалисты по ИБ — те, кто поможет не допустить атаки, либо остановить ее с минимальными потерями, так, чтобы другим сотрудникам не пришлось восстанавливать системы и утраченные данные с нуля.
Это должно быть очевидно сотрудникам — именно такое отношение помогает вовремя среагировать на атаку, если речь идет о человеческом факторе. Те же фишинговые атаки, как правило, растянуты во времени. Человек может даже не понять, что открыл дверь кому-то — злоумышленники для начала тихо проникнут в защищенный контур. Но если сотрудник проходил тесты, подозревает, что попался, и при этом доверяет своим коллегам из ИБ — он своевременно сообщит об инциденте.
Быть на связи с клиентами
Если речь идет о cloud-провайдере, то он, как центр комьюнити, должен доносить ИБ-риски до бизнеса, показывать на примерах, проводить ликбез. Важно дать понять, что на его системах и продуктах безопасность не заканчивается — нельзя лгать о том, что провайдер берет на себя все риски и задачи ИБ.
Кстати — и об этом тоже часто забывают — такая работа с клиентами должна быть непрерывной. Это не аппаратные средства защиты, которые достаточно внедрить единожды. На стороне клиента могут меняться сотрудники, может проводиться ротация кадров. Даже знакомые с вопросами ИБ коллеги порой что-то да забывают — в итоге бдительность падает. И провайдеру, и руководству клиента очень важно донести до сотрудников, что они могут стать невольными пособниками злоумышленников. А также постоянно напоминать, как избежать таких ситуаций и что делать, если они все-таки произошли.
Как выбрать адекватного провайдера
- Для начала принять как аксиому: провайдер провайдеру рознь. Если с одним случился масштабный, разрушительный инцидент, не факт, что такое произойдет с другим.
- Одних лишь сертификатов и аттестатов недостаточно. Серьезному клиенту мы бы посоветовали пообщаться с ИБ-командой провайдера. Это, кстати, чисто российская специфика — на Западе с вами никто не будет разговаривать, если вы не супер-VIP-клиент.
- Не можете пообщаться (например, вы — небольшая среднестатистическая компания, и уверены, что вас не будут слушать) — тогда изучайте репутацию провайдера на рынке. Для России сейчас это весомый показатель.
- Проверяйте, предоставляет ли провайдер услуги в сфере ИБ. Ими могут пользоваться не все — зато наличие таких услуг показывает, что провайдер реально занимается вопросами информационной безопасности.
- Помните, что DDoS-атака — это всегда форс-мажор, и по умолчанию провайдер не защищает всех клиентов от DDoS. Если для вас это актуально и критично, проверьте, что подключили услугу защиты от DDoS (при условии, что ваш провайдер ее предоставляет).
- Дополнительный плюс — наличие у провайдера чек-листов и мануалов по настройке сервисов. Это говорит о том, что на стороне провайдера проводится оценка актуальных рисков. А также о том, что у него достаточно сотрудников в ИБ-отделе, чтобы часть из них занималась методической работой.
- Следите за изменениями в политике и стандартах провайдера. Например, если в какой-то момент провайдер перестал соответствовать новым стандартам или проходить ежегодный аудит PCI DSS, — это тревожный звоночек. Возможно, сейчас у него нет ресурсов, чтобы организовать безопасность на должном уровне.
На этом все. Если у вас остались вопросы или возникли мысли по статье – пишите в комментариях, с радостью пообщаюсь.
