Бизнес заинтересован в снижении рисков информационной безопасности. О том, как это сделать, какова роль внутреннего аудита в снижении подобных рисков, как оценить эффективность процессов информационной безопасности, рассказывает Наиль Айнетдинов, руководитель направления по аудиту информационной безопасности, Tele2 Россия, член Ассоциации «Институт внутренних аудиторов»1.
Большинство руководителей компаний в той или иной мере сегодня осведомлено о рисках и угрозах информационной безопасности (ИБ). В результате бюджеты на нее растут, а в организационной структуре появляются новые подразделения информационной безопасности: центры кибербезопасности, ситуационные центры, продуктовая безопасность и т.д. Тем не менее эти инвестиции не всегда имеют отдачу. Иногда неочевидно, что положить на другую чашу весов возросшим затратам. Полное отсутствие инцидентов — это, скорее, плохой знак, под которым может скрываться слепота подразделений мониторинга и реагирования. Отчет об отбитых атаках умалчивает, что под ними имеются в виду безобидные сканирования роботов или багхантеров. Однако даже в хорошо защищенных инфраструктурах случаются инциденты и сложные атаки, которым нечего противопоставить.
Данная ситуация вовсе не означает, что оценить эффективность процессов информационной безопасности невозможно, как раз наоборот.
В настоящее время, когда новости про очередные кибератаки и утечки данных появляются практически ежедневно, любой компании как никогда важно уделить должное внимание вопросам ИБ. Начинать следует с понимания, на каком этапе развития она находится и насколько организация устойчива перед современными угрозами.
ИБ в организационной структуре
Сегодня можно встретить разные варианты подчинения подразделений ИБ. И учитывая, что вопросы ИБ могут порождать внутренние конфликты интересов в составе практически любого подразделения (наиболее ярко выражено в ИТ-подразделениях), консенсус заключается в выделении независимого подразделения ИБ, которое напрямую подчинялось бы C-level руководителю2. К сожалению, на практике такое встречается нечасто. Среди негативных эффектов зависимости от других функций может быть как замалчивание проблем безопасности, так и принесение в жертву безопасности ради других показателей — Time To Market3, сроков решения заявок на изменение и т.д.
Проблему зависимости подразделений ИБ можно частично решить усилиями внутреннего аудита.
Рассмотрим вариант выноса части функционала, который традиционно принадлежит подразделениям ИБ, в подразделение внутреннего аудита. Речь пойдет о тестах на проникновение и выборочном анализе безопасности приложений, систем, процессов и сервисов.
Аудит информационной безопасности
В сфере ИБ слово «аудит» встречается часто и в совершенно разных контекстах. Например, аудитом могут называть настройки журналирования событий в какой-либо системе или под аудитом безопасности подразумевать оценку защищенности (vulnerability assessment) и другие контроли ИБ.
Тем не менее чаще всего под аудитом ИБ понимают проверку соответствия системы управления ИБ стандарту/законодательству/отраслевым требованиям, иногда включая работы по тестированию на проникновение (далее — Pentest). И если с «бумажной» частью аудита ИБ все более-менее ясно, то с Pentest не все так однозначно.
Исторически сложилось, что Pentest обычно проводится по инициативе подразделений, отвечающих за обеспечение ИБ, или под их контролем. Это стало следствием того, что Pentest рассматривается как отдельный контроль ИБ, относящийся или к постоянной оценке защищенности (как часть контролей Security Assessment), или к оценке рисков и угроз ИБ (как часть Risk Assessment), или как регулярный мониторинг (например, требование 11 стандарта PCI DSS). Все перечисленное относится к операционным задачам подразделений ИБ и не может рассматриваться как полноценный аудит ИБ. А Pentest, который является наиболее действенным инструментом для оценки эффективности ИБ, остается в руках подразделений, которые этот процесс обеспечивают.
Технические проверки безопасности и Pentest
В большинстве случаев Pentest заканчивается полным захватом инфраструктуры и внушительным отчетом, в котором подробно рассказывается, какие проблемы безопасности были использованы пентестерами (white hat хакерами) для взлома. Что происходит дальше? Подразделение ИБ идет пугать бизнес фактами из отчета, а стандартный вывод — подразделению ИБ нужны дополнительные бюджеты, люди, технические средства защиты и т.д. И часто умалчивает, что внедренные в прошлые годы системы защиты и выстроенные процессы сработали неэффективно. Не редкость, что отчеты по Pentest просто идут в стол, потому что выставляют заказчика в невыгодном свете. И далее, пентестеры приходят ровно через год, так как бизнесу нужен сертификат PCI DSS, а ничего принципиально не изменилось. Пентестер просто берет прошлогодний отчет и немного обновляет его.
Таким образом, Pentest, являясь по сути проверкой эффективности процессов ИБ, чаще всего проводится самим проверяемым подразделением или под его контролем. Фактически подразделение ИБ проверяет свою же работу, а результатами проверки распоряжается по своему усмотрению.
В тоже время внутренний аудит в своих проверках ИБ, которые чаще всего проводятся направлением ИТ-аудита, испытывает недостаток технической информации. По результатам интервью и анализа документации внутренний аудитор может получить информацию немного в приукрашенном виде, которая больше отражает картину «как надо», чем реальное положение дел. Свидетельства аудита (переписка, скриншоты, файлы и т.д.) подкрепляют убеждение о хорошо работающем процессе ИБ или технических средствах защиты, но не учитывают идеальность условий в момент наблюдения. Во время компьютерных атак не бывает идеальных условий, а люди или системы срабатывают не так, как ожидалось. По этой причине результаты аудита следует подкреплять техническими проверками безопасности для получения объективных результатов с однозначной оценкой уровня защищенности объекта аудита.
В качестве технических проверок безопасности могут использоваться как простые инструментальные проверки, так и элементы Pentest или выборочная эксплуатация уязвимостей. Это, безусловно, требует от внутреннего аудитора определенных навыков и погруженности в практические аспекты ИБ. Учитывая, что даже внутри узких направлений ИБ существуют отдельные специализации, внутренний аудитор ИБ вряд ли сможет выполнять все технические проверки самостоятельно. Для узких задач можно привлекать внешних консультантов и восполнять недостаток внутренних компетенций.
Таким образом, ИТ-аудит не обеспечивает нужную глубину исследования объектов с точки зрения ИБ, а для проведения полноценных проверок ИБ желательно выделить отдельных внутренних аудиторов ИБ, обладающих необходимым опытом в практической безопасности. Внутренние аудиторы должны не только обладать широким кругозором в области ИБ и знать современные технологии защиты, но и обладать базовыми навыками взлома и эксплуатации уязвимостей.
Подведем итоги по двум пунктам.
Проведение Pentest и технических проверок ИБ под контролем подразделений ИБ может приводить к замалчиванию проблем и искаженным представлениям топ-менеджмента о реальной защищенности компании.
Во внутреннем аудите при проверках ИБ часто наблюдается недостаток объективной информации о защищенности компании, что может быть восполнено техническими проверками безопасности и Pentest.
Если проводить аудит информационной безопасности, включая Pentest и анализ безопасности приложений/систем/процессов, силами внутреннего аудита, открываются следующие возможности:
1. Топ-менеджмент на периодической основе получает объективную информацию об уровне защищенности как компании в целом, так и выборочных систем/процессов.
2. У заинтересованных подразделений (ИТ, ИБ и бизнес) отсутствует возможность повлиять на результаты проверок, преуменьшить или замолчать выявленные проблемы.
3. Выявленные проблемы безопасности обсуждаются на высоком уровне и приводят к системным решениям, которые трудно было бы инициировать на уровнях ниже.
А что на практике?
Опытные пентестеры, у которых за спиной множество взломанных инфраструктур крупных заказчиков, иногда выгорают и меняют сферу деятельности, потому что каждый новый Pentest похож на предыдущий, проблемы у заказчиков одни и те же, а раздел с рекомендациями можно вообще не переписывать годами. Но больше всего их расстраивает ситуация, если по результатам их работы ничего не изменилось в лучшую сторону и безопасность осталась на таком же уровне.
Почему такое происходит? Можно ли улучшить ситуацию по классическим проблемам ИБ с позиции внутреннего аудита? Определенно — да. Приведем несколько примеров.
Проблемы сетевой безопасности
Сегодня практически нет организаций, в которых не использовалось бы сетевое оборудование.
Если на вопрос «У вас есть сеть?» ответ утвердительный, то, скорее всего, у вас проблемы с сетевой безопасностью. Они могут быть некритичными, но они есть.
Основные принципы сетевой безопасности упрощенно можно сформулировать так:
1. Каждый узел сети должен иметь минимально необходимый сетевой доступ, использующийся для выполнения своего функционала.
2. Сеть должна быть разделена на изолированные друг от друга сегменты, а любые взаимодействия между сегментами ограничены с соблюдением подхода «запрещено все, что не разрешено».
3. В сети должны использоваться безопасные протоколы, а риск использования небезопасных протоколов купироваться компенсационными мерами.
Практически в любой инфраструктуре можно найти несоответствия перечисленным выше принципам. И без технической экспертизы выявить их непросто.
Администратор межсетевого экрана заверит внутреннего аудитора, что ACL4 (списки доступа) выверены и периодически пересматриваются. Но если подробно проанализировать ACL, то, скорее всего, там найдутся неактуальные или слишком широкие правила: например, «разрешить все входящие подключения по HTTP», хотя такие подключения нужны для 1% узлов выбранного сегмента.
Не будет лишним и просканировать выбранный сегмент, когда вас заверяют, что «он изолирован и не доступен из офисной сети». Результаты могут удивить и сетевого инженера.
Еще одним эффективным средством является анализ сетевого трафика. Тем более если сетевые инженеры нарисовали схему и карту сетевых потоков, несложно проверить на реальном трафике, соответствуют ли они действительности.
Вышеперечисленные недостатки желательно подкрепить демонстрацией успешной атаки с использованием найденных проблем. Моделирование атак полезно и внутреннему аудитору, чтобы сосредоточиться на реально важных проблемах, и владельцу объекта, чтобы понять серьезность и практическое влияние выявленного недостатка.
В целом вопросы сетевой безопасности имеют огромное влияние на общее состояние безопасности. Практически все атаки так или иначе проводятся по сети. Посредством сетевого оборудования можно как крупно ошибиться (например, по ошибке опубликовать уязвимый внутренний сервис в интернет), так и эффективно противостоять серьезной атаке (например, вовремя распознать атаку и изолировать ее источник).
Проблемы управления доступом
Аналогично предыдущей проблеме проблемы управления доступом практически неискоренимы в сложных инфраструктурах.
Хорошо, если вопросом озаботились заранее и новые бизнес-системы проектируются с учетом единых архитектурных требований, а затем интегрируются в систему управления доступом. Но даже в таком случае найдется «наследие» и системы, в которых отдельно живет локальная база пользователей и используются собственные механизмы управления доступом со сложными матрицами полномочий и ролевыми моделями.
Плюс к этим сложностям: назначенные права доступа быстро теряют актуальность — люди переходят в другие подразделения, увольняются, болеют, уходят в декрет и т.д. Иногда доступ просто становится не нужен, потому что изменились задачи и функционал сотрудника.
И никто не отменял любовь администраторов к обезличенным учетным записям, избыточные права тестовым или сервисным учетным записям и т.п. А если затронуть проблему безопасности аутентификации и парольной защиты…
В чем тут могут помочь технические проверки и Pentest, если, кажется, достаточно проанализировать выгрузку пользователей, ролевую модель, проверить наличие соответствующих заявок и т.д.?
Пример: при поверхностном взгляде на бизнес-систему все выглядит неплохо — доступы выдаются по заявке с соответствующими согласованиями, отзываются автоматически при увольнении или смене должности, а выданная роль не содержит избыточных прав. У администраторов тоже вроде все в порядке — заходят под именной учетной записью администратора, все входы логируются и т.д.
Но в ходе Pentest взламывается всеми забытый тестовый сервер системы, оттуда извлекаются реквизиты администратора тестовой среды. И внезапно оказывается, что извлеченные реквизиты доступа подходят к продуктивной среде и дают привилегированный доступ. Хотя администраторы убеждены в изолированности тестовой и продуктивной среды.
Проблемы продуктовой безопасности
Продуктовая безопасность — относительно новое направление ИБ для большинства компаний, которые ранее не разрабатывали цифровые сервисы и программные продукты для массового рынка. Но с появлением собственных разработок приходит понимание (иногда уже после инцидента), что для обеспечения безопасности продукта или сервиса требуются серьезные усилия, а пользователи становятся все более требовательными и не терпят ошибок — утечек данных, кражи денежных средств и т.д.
Тем не менее продуктовая безопасность во многих бизнесах отсутствует, и как результат мы наблюдаем на рынке массу небезопасных цифровых сервисов (уязвимые мобильные приложения, интернет-магазины, системы оплаты и т.д.). Внутренние аудиторы ИБ, обладая компетенциями по безопасности приложений, могут помочь улучшить эту ситуацию и привлечь к проблемам продуктовой безопасности дополнительное внимание.
Аудиторы ИБ вполне могут выступать консультантами при проектировании и разработке новых цифровых продуктов, что позволит избежать хотя бы самых грубых ошибок в части информационной безопасности.
С другой стороны, аудит ИБ может проводить выборочные проверки собственных цифровых продуктов, например мобильного приложения, что может помочь выявить системные проблемы безопасности в процессах разработки или во взаимоотношениях с внешней компанией-разработчиком.
Проблемы патч-менеджмента
К упомянутым выше рекомендациям можно смело отнести совершенствование процесса установки обновлений программного обеспечения. В том или ином виде этот процесс присутствует везде, и все знают, что нужно устанавливать обновления безопасности. Но не все осознают, насколько сложно выполнять обновление в большой инфраструктуре.
Простая установка обновлений кажется пустяковым делом. С помощью готовых инструментов, которые автоматически скачивают новые пакеты и управляют их версиями, нужно установить обновления сначала на тестовых серверах, а если ничего не сломалось — на продуктивных. Что может быть проще?
Но этот процесс в крупной инфраструктуре сложен: какие-то серверы настолько старые, что не переживут новых обновлений, какие-то прикладные системы ломаются от обновлений и требуют доработок, какие-то системы просто нельзя останавливать, а следующая технологическая пауза через год. На это все накладываются проблемы управляемости, что администратор не может просто установить обновление и перезагрузить сервер, владелец системы должен быть уведомлен об этом, а администраторы прикладной системы — проконтролировать, что ничего не сломалось.
В ходе практически любой проверки аудита ИБ выявляются те или иные проблемы патч-менеджмента. Главное, чтобы затем администраторам стало понятнее, зачем их заставляют устанавливать обновления. Одно дело, когда аргументируют «потому что это лучшие практики», другое дело, когда продемонстрировали получение полного доступа к серверу в пару действий.
Таким образом, периодические аудиты ИБ постоянно напоминают руководителям ИТ о важности патч-менеджмента и необходимости системно и с полным охватом решать эту проблему.
Проблемы процессов ИБ
Возвращаясь к вопросу о трудностях оценки эффективности подразделений ИБ: ничто так наглядно не демонстрирует эффективность защиты, как противостояние настоящей атаке. Крайне желательно подкреплять результаты проверок аудита ИБ практической стороной вопроса, то есть моделированием атак.
Скрывать факт проведения Pentest для эффекта неожиданности совсем необязательно, эффективное противодействие защитников легко отличить от «палок в колеса». Тем более что в здоровой ситуации защитники сами заинтересованы опробовать в действии то, что строили в предыдущие годы.
Одна из популярных проблем — неэффективное использование внедренных средств защиты. Такую проблему можно выявить и по результатам интервью, когда инженер ИБ еле вспомнил пароль от консоли управления, а после входа написано «последний вход совершен 365 дней назад». Но намного красноречивее эта проблема может проявиться в ходе Pentest, когда атака не обнаружена, а если обнаружена — ее не могут отбить. И главный ожидаемый эффект по результатам аудита ИБ — осознание подразделением ИБ выявленных проблем и работа над ошибками.
С другой стороны, положительные результаты Pentest тоже не редкость. Можно с гордостью заявить, что подразделение ИБ год работало над улучшением сетевой безопасности и пентестеры несколько дней потратили на обход этой защиты, когда раньше этого совсем не требовалось. Или инвестиции в мониторинг и реагирование явно дали результаты, потому что подразделение ИБ фиксировало практически каждое действие пентестера и быстро определило его местоположение в офисе.
Таким образом, практические проверки аудита ИБ вносят значительный вклад в непрерывное улучшение процессов ИБ, потому что на практике демонстрируют угрозы безопасности и как им противостоять. И если эти работы проводятся независимым и непредвзятым подразделением внутреннего аудита, это минимизирует риски манипуляции результатами, искажения или замалчивания проблем, а высшее руководство получает достоверную и объективную информацию о состоянии ИБ.
Резюме
Мы рассмотрели плюсы подхода, в котором деятельность по аудиту ИБ, включая Pentest и анализ безопасности приложений/систем/процессов, выполняется силами внутреннего аудита. Минусы тоже могут быть, если внутренние аудиторы не придерживаются конструктивного подхода и не стремятся помочь бизнесу и подразделениям ИБ, но это касается любого аудита. Важно отметить, что для эффективного аудита ИБ требуются компетенции в самых разнообразных областях, преимущественно технических. Внутреннему аудитору ИБ приходится разбираться в конфигурациях сетевого оборудования, уязвимостях веб-приложений, архитектуре сложных систем и приложений, обладать навыками Pentest и прочее. Недостаток некоторых компетенций можно компенсировать с помощью внешних консультантов, но определенно аудитор ИБ должен быть опытным практиком в области ИТ и ИБ.
1 Ассоциация «Институт внутренних аудиторов» (Ассоциация «ИВА»), зарегистрированная в 2000 г., является профессиональным объединением более чем 4000 внутренних аудиторов, внутренних контролеров и работников других контрольных подразделений российских компаний и организаций. Подробности на сайте www.iia-ru.ru.
2 Первые лица компании: топ-менеджмент, члены совета директоров и т.п.
3 Время от начала разработки идеи до ее конечной реализации, когда вы продаете ее клиенту. То есть Time To Market — это «время до выхода на рынок».
4 ACL (Access Control List) — список управления доступом.