Облака и безопасность: дружба против киберугроз

Слушайте выпуск на подкаст-площадках

Сергей Зинкевич. Насколько дружны ИТ-безопасность и облака?

Андрей Макаренко. Некоторые предпочитают не замечать существование облаков и уверены, что безопасности в облаках нет. Такие люди, несмотря на любые доказательства, остаются при своем мнении и ни при каких обстоятельствах не придут в облако. Другие загружают свои информационные системы в облако, и в какой-то момент там появляется безопасность.

Сергей Зинкевич. Но на первом этапе о безопасности забывают?

Андрей Макаренко. Так часто случается. Возможно тому есть «правильные» причины, связанные с квалификацией сотрудников и нехваткой безопасности в компании, но в облаках безопасность появляется либо в конце, либо, в лучшем случае, во время реализации проекта.

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

Однако это не так. Недавно мы принимали участие в урегулировании инцидента, когда компания, использующая 1С, выставила веб-часть системы «наружу» без Anti-DDoS, WAF и других средств защиты. Разумеется, систему очень быстро сломали, что стало сюрпризом для компании, которая была уверена, что, если у облачной платформы есть сертификаты и средства защиты, систему на этой платформе невозможно сломать.

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

Сергей Зинкевич. Что можно добавить о «дружбе» ИТ-безопасности и облака и о последних тенденциях в этой сфере?

Тимофей Минин. Безопасность всегда идет вместе с ИТ или, по крайней мере, догоняет. Когда бизнес со своими задачами переходит в облако или стремится к переходу в облако и ИТ это поддерживает, очень важно подключать безопасность на ранних этапах. Отвечая на вопрос о том, дружит ли безопасность с облаками, можно сказать, что варианта не дружить просто нет.

Петр Богданов. Я бы еще обратил внимание на распределение ответственности в разных облачных форматах. Например, в IaaS ответственность пользователя за обеспечение безопасности больше, чем в SaaS или в PaaS. Подразумевается, что в SaaS бОльшая ответственность за закрытие возможных рисков лежит на провайдере.

Сергей Зинкевич. Да, чем более высокого уровня сервис мы получаем, тем больше передаем на аутсорс нашему партнеру. Безопасность — это, в том числе, вопрос доверия. Меня как представителя облачного провайдера постоянно атакуют вопросами про безопасность. Однако в какой-то момент заказчик должен начать доверять облачному провайдеру или партнерство обречено.

Почему безопасники боятся и даже сопротивляются переезду в облака?

Андрей Макаренко. Безопасники не боятся идти в облака, но у них нет понимания, как облачная платформа устроена с точки зрения обеспечения безопасности. Это серьезный вопрос, в котором надо разбираться. Кроме того, некоторые провайдеры об этом не рассказывают. Нужно объяснять коллегам, как устроены S3-хранилища и IAM (Identity and Access Management), где хранятся секреты и т. д., потому что это увеличивает доверие к платформе.

В свете последних событий можно особо отметить тенденцию к локализации, когда головная компания отрезает российский офис от ИТ-инфраструктуры, и ему приходится выстраивать комплекс систем безопасности, включая процессы и сервисы. Такие компании приходят в облако, уже понимая, что им необходимо. Они приходят с определенными метриками, например, на базе NIST или ISO 27 серии, и просят реализовать их в облаке. Им больше нужны процессы, чем средства защиты информации, потому что наличие таких средств еще не гарантирует, что система будет защищена. Таких проектов много, и можно отметить, что процессы ИТ-безопасности в облаке на российском рынке начинают развиваться.

Сергей Зинкевич. Бизнес в России сталкивается с огромным количеством кибератак. Если раньше можно было ограничиться установкой Anti-DDoS, WAF и усложнением паролей, то сейчас мы вынуждены уделять защите больше внимания.

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

Сергей Зинкевич. В последние два года в облаках очень сильно растет спрос на услуги по защите процессов разработки — DevSecOps.

По результатам опроса о передаче сервисов защиты на аутсорс половина нашей аудитории этого не делает, около 30% передают частично.

Тимофей Минин. Это вполне логичные результаты. Облака — это сервисная модель, поэтому компании, которые используют облако в качестве ИТ-платформы, чаще обращаются к облаку для получения сервисов, в том числе сервисов защиты.

Сергей Зинкевич. Это связано с дефицитом кадров.

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

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

Андрей Макаренко. Как театр начинается с вешалки, так и система начинается с кода. От выстроенного процесса безопасной разработки никуда не деться, то есть необходимо научить человека, который пишет код, хранить план в секрете и не выкладывать его куда-либо. Это первый этап. На этот процесс «накручивается» security pipeline, система проходит тестирование, после чего все выкладывается в prod.

Дальше систему необходимо защищать, поэтому на границе появляется сетевой экран, сервис сканирования вложений (если есть почта), песочница, где все «взрывается» и триггерит. После этого необходимо обратить внимание на уровень операционной системы и обеспечить защиту СУБД. Таким способом создается эшелонированная оборона. Кроме того, все это должно поддерживаться правильно выстроенной стратегией мониторинга критичных для бизнеса активов и событий безопасности с использованием систем SIEM или SOC.

Сергей Зинкевич. Что можно сказать о процессах безопасной разработки?

Петр Богданов. На рынке есть популярные методологии безопасной разработки. Если организация только начинает подход к этому снаряду, можно рассмотреть такие методологии, как PSIM (Physical Security Information Management) или OWASP SAMM, которые включают в себя четыре основных домена: управление (governance), выстраивание SSDL, встраивание различных контролей, intelligence. Эти 4 домена можно разложить на 122 активности. В случае PSIM, пообщавшись с внутренними командами и тимлидами, можно примерно понять, насколько мы соответствуем тем или иным «представлениям о прекрасном», насколько соблюдаются эти контроли, а также понять уровень зрелости (всего 3 maturity level) и, возможно, запланировать какие-либо шаги, чтобы к определенному году достичь нужного результата, в том числе продумать меры или создание документации, чтобы закрыть те или иные риски, которые будут выявлены после применения данного подхода.

Можно использовать еще один подход — CCM Matrix. Это более актуально для облачных провайдеров, которые могут представить результаты соответствующего аудита и подтвердить выполнение определенных процессов. Однако и организация может оценить предлагаемые процессы, например, подход к SDLC, и соответствие собственным процессам.

В дальнейшем можно пытаться выстраивать те или иные методы защиты в соответствии с определенной методологией.

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

Сергей Зинкевич. На рынке уже много зрелых облаков, но до сих пор больше всего аварий случается по вине сотрудников. Получается, что люди — самый опасный фактор. Правильно ли я понимаю, что эти методологии защищают нас в том числе от нас самих?

Петр Богданов. Да, конечно. Помимо технологий они подразумевают ряд активностей по работе с персоналом и обеспечению awareness.

Тимофей Минин. Повышение уровня знаний и осознанности сотрудников очень важно. Для этого есть курсы и программы, которые облачные провайдеры должны активно пропагандировать.

Андрей Макаренко. Важно добавить, что обучение внутри команды основам безопасности должно проводиться как для облачных сред, так и для on premise. Например, сотрудники должны знать, что нельзя разрешить бакету S3 анонимно «смотреть» в Интернет. Такие истории случаются.

Петр Богданов. Чтобы ответить на этот вопрос, я продолжу рассказывать про методологию. После проведения внутренней оценки (assessment), в рамках которой мы затронули SSDL и touchpoint-ы, в том числе компенсирующие меры, для выстраивания полноценного процесса DevSecOps необходимо использовать решения по анализу кода — SAST, OSA, SCA, DAST и др. Для микросервисной разработки можно включить решение container security. То есть это не одна «волшебная пилюля», а комплекс мер и средств, позволяющий закрывать определенные риски.

Андрей Макаренко. Security By Design — это то, к чему все
стремятся. Это не только security pipeline для безопасной разработки. Аналогичным образом процесс выстроен в облаках, когда нужно правильно спроектировать инфраструктуру, разграничить зоны безопасности, «нарезать» сетевые доступы, раздать доступ внутри инфраструктуры и доступ к информационной системе, потому что управление доступом является одним из самых главных процессов по управлению ИТ-безопасностью.

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

Сергей Зинкевич. Можно ли сказать, что это доверенный образ?

Андрей Макаренко. Это не доверенный образ, потому что, в любом случае, придется все дополнительно настраивать. Не стоит думать, что кто-то в облаке все продумает и придумает, а вам останется только нажать волшебную кнопку. Работать приходится постоянно.

Тимофей Минин. Все сказано очень правильно и возвращает нас к вопросу распределения зон ответственности между заказчиком и облачным провайдером.

Сергей Зинкевич. Много ли «Лаборатория Касперского» помогает облачным провайдерам в обеспечении безопасности сервисов?

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

Петр Богданов. Мы общаемся с облачными провайдерами в том числе по отдельным продуктам, которые помогут обеспечить Security by Design.

Тимофей Минин. Мы с Петром отвечаем за развитие продуктов «Лаборатории Касперского» не только в России, но и во всем мире, и поэтому часто ориентируемся на аналитику глобального рынка. В таком анализе используются понятия Cloud Workout Security или Cloud Workout Protection. Это класс решений, созданный для обеспечения безопасности в облаке, который включает защиту виртуальных сред, контейнерных сред и Cloud Security Posture Management. Это основное направление, в рамках которого «Лаборатория Касперского» рассматривает варианты коллаборации и встраивания в облака.

Сергей Зинкевич. Мы считаем этот вопрос очень важным. КРОК Облачные сервисы заботится о предоставлении заказчикам Security By Design и, если мы видим узкие зоны, стараемся помогать заказчикам решать такие вопросы.

Петр Богданов. Когда мы говорим про IaaS-платформу, риски в большей степени несет пользователь. Продвигаясь в сторону PaaS, мы балансируем эти риски, а уже на SaaS-платформе риски в большей степени лежат на облачном провайдере.

Андрей Макаренко. Нам приходится выполнять много требований, в том числе ГОСТ 57580 и Приказ 21. После аттестации по УЗ-1 или ГОСТ облачному провайдеру присваивается определенный уровень защищенности и класс соответствия. Аттестующий предлагает заполнить матрицу разграничения ответственности между провайдером и заказчиком. Эта матрица, как правило, доступна для ознакомления, и заказчик может сопоставить ее со своей инфраструктурой, оценить меры, которые выполняются на стороне облака, и расписать эти меры со своей стороны. Это позволяет понять, что и какими способами реализовано в инфраструктуре заказчика.

Петр Богданов. Все известные нам провайдеры предлагают такую матрицу.

Андрей Макаренко. За последние пару лет у нас было только два или три кейса, когда заказчик просил включить матрицу разграничения зон ответственности в договор, потому что, как правило, зоны ответственности формулируются не очень четко. Я рекомендую всем заказчикам не стесняться и просить включить матрицу в договор с облачным провайдером. Это спасет как провайдера, так и заказчика в случае возникновения инцидентов.

Сергей Зинкевич. Я поддерживаю мысль, что матрица распределения зон ответственности должна быть частью договора. Обычно мы ее называем RACI-матрицей (Responsible, Accountable, Consulted, Informed). Люди приходят и уходят, поэтому, чтобы избежать неоднозначностей, проще фиксировать все в договоре.

Андрей Макаренко. Само определение матрицы разграничения зон ответственности наводит на мысль, что за что-то отвечает кто-то другой. На самом деле это не так. Заказчик должен подружиться с облачным провайдером, а провайдер — с заказчиком. Это совместная работа, где заказчик должен совместно с провайдером построить свою правильную систему защиты. Результат можно получить, только работая вместе.

Сергей Зинкевич. Вокруг нас много регуляторов и требований, но есть и реальная жизнь. Насколько далеки друг от друга «бумажная» и реальная безопасность и когда они наконец сойдутся?

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

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

Поэтому я считаю, что надо прекращать ориентироваться только на «бумажную» безопасность. Надо реально оценивать риски и векторы атак и максимально плотно защищать свою информационную систему.

Взломы, DDoS-ы и проникновения в периметр за последние пару лет очень сильно ударили по российскому бизнесу, а количество утечек выросло в разы. В такой ситуации не стоит подходить к безопасности только с точки зрения выполнения комплаенса. Но это вопрос к самим безопасникам — мы помогаем бизнесу зарабатывать деньги и делаем ему комфортно или просто прикрываемся бумагами?

Тимофей Минин. А я задумался, какой KPI у условного CISO в компании? Этот вопрос сразу отпадает, если есть тесная взаимосвязь между блоком безопасности и бизнесом, и безопасники отвечают за реальные деньги, вернее, за отсутствие потерь этих денег при взломах или утечке данных. В таком случае речь идет не о бумажках, а о реальной безопасности.

Андрей Макаренко. Я даже знаю компанию, в которой для CIO есть такой KPI, как отсутствие потерь из-за киберинцидентов. Безопасность в этой компании не «бумажная». Например, на несложном производстве киберинцидент может привести к задержке в логистике или отгрузке и, соответственно, к потере больших денег. 

По результатам опроса, только «бумажная» безопасность беспокоит всего 6% аудитории подкаста, а реальная — примерно 30% (при этом 30% аудитории отдает ИТ-безопасность на аутсорсинг). Около половины аудитории беспокоит как «бумажная», так и реальная безопасность.

Андрей Макаренко. От «бумажной» безопасности уйти не удастся. В любом случае 99% компаний обрабатывают персональные данные и должны выполнять Приказ 21, то есть требования «бумажной» безопасности. Можно также отметить финсектор, который регулируется, в том числе, ГОСТ 57580.

Сергей Зинкевич. Мы уже не первый раз упоминаем ГОСТ 57580.1-2017. О чем он?

Андрей Макаренко. Этот документ оговаривает требования к финансовым организациям по обеспечению безопасности. Регулятор жестко следит за их выполнением.

Сергей Зинкевич. «Лаборатория Касперского» помогает выполнять требования регулятора? Или вы занимаетесь только реальной безопасностью?

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

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

Андрей Макаренко. Да, в том числе вы предоставляете продукты для построения эшелонированной обороны.

Петр Богданов. Мы нацелены на решение реальных проблем, и семейства наших продуктов призваны в этом помогать.

Сергей Зинкевич. Мы много говорим о различных средствах защиты облака. Почему же безопасники боятся облаков?

Андрей Макаренко. Безопасники не боятся облаков, они голосуют за них «руками и ногами». Есть люди, которые в силу каких-то причин не хотят переходить в облака, но их немного. А настоящие безопасники — «за» облака.

Тимофей Минин. Мы говорили о мнимых и реальных страхах. Основная боль перехода в облако с точки зрения безопасности для внутренних команд в крупных компаниях — это необходимость перестроить процессы, выполнить определенную работу, переобучить или нанять специалистов. На входе это очень страшно, но компания в дальнейшем получает определенные выгоды. Этот путь просто нужно пройти, невзирая на трудности.

Второй страх — это делегирование ответственности провайдеру, то есть смена внутренней парадигмы.

Сергей Зинкевич. Если мы живем on premise, нам нужно заботиться о процессах разработки. Что-то меняется, если мы переезжаем в облака, или можно перевозить процессы и инструменты один к одному?

Петр Богданов. Процессы безопасной разработки в любом случае необходимо поддерживать. Если мы проверяли код, используя сканеры on premise, после перехода в облако логично продолжать их использовать. Возможно будут добавлены другие инструменты или они будут работать в другой логике. Например, CSPM (cloud security posture management) проверяет некоторые параметры облачных провайдеров на соответствие представлениям вендора о том, как они должны быть настроены.

Андрей Макаренко. Если есть ошибки в коде (не важно, где он создан, on premise или в облаке), security pipeline не будет, ошибка все равно попадет в prod и сломает систему. Если безопасности нет on premise, ее не будет и в облаке. Если нет процессов, нечего переносить в облако.

Сергей Зинкевич. Получается, что оставаться on premise не означает априори бОльшую безопасность.

Мы, как облачный провайдер, работаем в соответствии с разными стандартами, в том числе PCI DSS (Payment Card Industry Data Security Standard), который подразумевает два пентеста в год. Это означает, что в любой момент есть результаты пентеста не старше 6 месяцев. Заказчики «заезжают» в эту инфраструктуру, но продолжают беспокоиться о безопасности. При этом инфраструктура on premise не так уж часто проходит тест на проникновение.

Должна ли работа в соответствии с такими стандартами обеспечивать доверие или этого недостаточно?

Андрей Макаренко. Это создает определенное доверие. В последнее время используется подход bug bounty, и если облачная платформа открыта для таких тестов, заказчики могут увидеть и оценить найденные на ней уязвимости. Разумеется, это повышает уровень доверия. Чем более открыто ты рассказываешь о своей платформе и механизмах безопасности, тем больше клиенты будут готовы переходить в облако.

Марина Эфендиева. Почему разделение между «бумажной» и реальной безопасностью все еще существует? По идее, они должны работать вместе. Может быть, всем вам просто стоит объединиться и изменить отношение к бумагам — доказать, что они имеют отношение к реальности.

Сергей Зинкевич. Что такое «бумажная» безопасность? Происходит некое событие — его надо определить и описать, согласовать это описание со многими инстанциями, опубликовать, установить срок обеспечения соответствия требованиям. Связанная с этим процессом инерция занимает несколько лет, за которые все может существенно измениться. Поэтому «бумажная» безопасность отстает от реальной безопасности, хотя они должны сближаться и, на мой взгляд, сближаются. Регуляторы прилагают усилия для этого, и большое количество команд, таких как КРОК Облачные сервисы, «Лаборатория Касперского» и другие, им помогают. Это очень важно. Если мы будем заботиться о безопасности, использовать лучшие практики и рассказывать о них, выиграют все. 

Тимофей Минин. Мне кажется, что с точки зрения безопасности, большую роль играет awareness. А что касается «бумажной» безопасности — бумаги могут устаревать.

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

Сергей Зинкевич. Разумеется, потому что инцидент может случиться, а может и не случиться. Как можно ответить на такие возражения?

Андрей Макаренко. Рассказать заказчику о рисках. Остановка производственного процесса из-за кибератак приводит к существенным финансовым и, что немаловажно, репутационным потерям. Такие аргументы дают безопасникам большое преимущество. Однако мало кто из безопасников и ИТ-специалистов готов разговаривать с первыми лицами на понятном бизнесу языке.

Марина Эфендиева. В последнее время участились DDoS-атаки, это наша новая реальность. Что сегодня должно быть прописано в договоре между провайдером и заказчиком? Что делать, если случится неприятная ситуация, например, с моим приложением для продажи товаров, установленном в облачной инфраструктуре, которая подверглась атаке? Должны быть прописаны компенсации или возмещение? 

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

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