Обеспечение информационной безопасности развертываемых или модифицируемых информационных систем должно стать обязательной частью ИТ-проектов
Предприятия, не уделившие должного и своевременного внимания этим аспектам безопасности, рискуют в будущем столкнуться с серьезными проблемами, причина которых — плохо защищенные компоненты корпоративных ИТ.
В контуре информационной безопасности стремительно растущего бизнеса нередко остаются «белые пятна» — области, недостаточно надежно прикрытые средствами защиты. Риски, исходящие от «белых пятен», могут проявиться в «эпоху перемен», например, при смене бизнес-модели предприятия или при размещении ИТ-ресурсов в новых технологических средах, в том числе облачных, и в итоге обернуться серьезными проблемами.
Возникновение «белых пятен» в контуре информационной безопасности — ситуация весьма распространенная, считает Михаил Емельянников, независимый эксперт. Причины их появления совершенно очевидны. «Большие проекты в области ИТ всегда имеют существенные ограничения по срокам и бюджету, уложиться в них практически никогда не удается, поэтому приходится жертвовать тем, что не оказывает явного влияния на работоспособность и функциональность, — делится своими наблюдениями Емельянников. — Пока идет проект, будь это развертывание большого инфраструктурного решения или внедрение бизнес-системы корпоративного уровня, вопросы безопасности обычно не прорабатываются и не решаются. Последствия такого отношения к ИБ проявляются только потом, причем не в явной форме».
Сценарий появления «белых пятен» примерно одинаков: они возникают в результате того, что внедрение и настройка систем, призванных обезопасить корпоративные информационные ресурсы, были отложены до лучших времен или до получения ресурсов и т. д. Далее события также разворачиваются по похожему сценарию: после смены персонала о них никто, скорее всего, уже не помнит и не знает, и всплыть они могут достаточно неожиданно.
Характерный пример — внедрение системы складского учета. Возможность неконтролируемого внесения изменений в данные создает колоссальные возможности для хищений. «Правильная» система доступа к данным подразумевает надежную аутентификацию и идентификацию пользователей, ролевой принцип доступа, оценку непротиворечивости, достаточности и избыточности функций для каждой роли, возможность внесения изменений в одну запись строго одним пользователем, протоколирование действий, возможности для оперативного выявления неправомерных действий и реагирования на них. Все это дополнительные опции к основному функционалу, дорогие и сложные во внедрении, поэтому их нередко откладывают на период после завершения проекта, затем на еще более отдаленную перспективу, а потом и вовсе о них забывают. Возможно, о проблеме вспомнят после очередной инвентаризации имущества или товаров на складе.
Многие аналитические исследования полагают, что большинство проблем в области ИБ происходит из-за ошибок в конфигурации. Как правило, такие ошибки возникают вследствие отсутствия или недостаточно четкого исполнения необходимых организационных мер, строгих регламентов ИБ, в том числе при приеме сотрудников на работу и увольнении. Также очень много проблем возникает в связи с необходимостью разрешить временный доступ — на определенный период времени или на отдельный проект. Антон Разумов, консультант по безопасности компании CheckPoint Software Technologies, приводит такой пример: «Достаточно часто DLP-системы настраивают таким образом, что утечка данных фиксируется по факту, однако бывает и так, что политика настраивается на режим предотвращения атак, и, как следствие, при отправке некоторых файлов могут возникать проблемы: например, если система не позволяет топ-менеджеру выслать какой-то документ. В связи с этим для него делается исключение, затем второе, третье, постепенно такие исключения накапливаются — в конце концов, их становится так много, что система обеспечения информационной безопасности превращается в решето».
По мнению Антона Силина, эксперта по информационной безопасности, на современном уровне развития ИБ в России вопрос «белых пятен» вообще не стоит. «Нет такой проблемы, потому что есть множество всем известных “дыр”, не закрытых по политическим, финансовым соображениям или просто из-за разгильдяйства. На этом фоне наличие уязвимости, которую когда-то не закрыли, отложили на потом, а затем забыли, на мой взгляд, несущественно».
Игорь Михайлов, руководитель отдела управления рисками корпоративного центра группы «МТС», считает, что наличие наприкрытых «дыр» в безопасности часто связано с экономическими причинами. В большинстве случаев для своего развития компании используют кредиты, приходится платить проценты за пользование привлеченными средствами. Отвлечение излишних средств на гипотетический рост нагрузки, резервирование еще не ставшего критически важным ИТ-сервиса не всегда приветствуется».
Бизнес в состоянии уязвимости
Конечно, все требования бизнеса, касающиеся ИТ-поддержки, должны быть реализованы в информационных системах. Бизнес плохо понимает, что и как работает, поэтому кто-то должен проанализировать и представить бизнесу риски, после чего владельцы бизнес-процессов должны принять осознанное, взвешенное решение о возможности или необходимости снижения соответствующего риска. Эта работа стоит определенных денег. Производитель приложения и интегратор-внедренец в ней, как правило, не заинтересованы, а заказчик часто этого просто не понимает. Вот и появляются системы, где кладовщик может сам бесконтрольно списать товар, а бухгалтер — вывести средства из отчетности.
Емельянников считает, что в подобных случаях непременно появляются неконтролируемые уязвимости, через которые в лучшем случае просто организуется атака на информационную систему, а в худшем — похищаются деньги и материальные средства. «Системы выявления мошеннических действий давно стали неотъемлемой частью информационных систем банков, операторов связи и западных страховых компаний. Но выявление мошенничества — реактивный, а не проактивный ответ на имеющиеся уязвимости. Гораздо надежнее (и в конечном итоге дешевле) сформировать и реализовать требования безопасности, выявить возможные уязвимости на этапе проектирования и создания системы. Но мы живем по другим правилам — пока гром не грянет или петух не клюнет».
По мнению Разумова, хорошей практикой является формирование политики безопасности не одним, а несколькими специалистами. Например, служба безопасности предлагает внести изменения в систему безопасности, администратор предлагает механизм работы, другой сотрудник проверяет соответствие предполагаемых изменений политике компании, утверждает или отправляет их на доработку, третий специалист непосредственно реализует эти изменения.
На рынке имеется большое количество различных сканеров, которые позволяют оценить защищенность информационной системы по известным уязвимостям.
В ходе слияния или поглощения компаний их информационные системы нередко приходится объединять. Это бывает не так просто с точки зрения ИБ, поскольку у информационных систем этих компаний, скорее всего, будут разные механизмы защиты и разные уязвимые места. К тому же при объединении систем могут появиться и новые уязвимости, которых до объединения не было. Службе информационной безопасности нужно в короткие сроки выявить проблемы объединенной системы и оперативно их ликвидировать. Для этого могут использоваться сканеры уязвимостей, в автоматическом режиме позволяющие оценить уровень безопасности информационной системы.
На сегодняшний день разработано большое количество различных сканеров. Можно выделить следующие их типы.
• Активные сканеры. Они имитируют работу злоумышленника, посылая запросы каждому элементу сети. Сканер пытается определить тип используемого сетевого сервиса и, если в нем есть известная уязвимость, атаковать его. Такие сканеры хорошо позволяют обнаруживать уязвимые места информационной системы, но создают при своей работе очень большую нагрузку на сеть, поэтому для их использования нужно определить правильную политику сканирования — выполнять ее только в периоды минимальной нагрузки, делить корпоративную сеть на сегменты и использовать только безопасные режимы тестирования уязвимостей.
• Пассивные сканеры. Работу по обнаружению уязвимых сетевых сервисов можно выполнять и пассивно, то есть «слушая» и анализируя сетевой трафик, циркулирующий в корпоративной сети. С помощью анализа протоколов можно также определить версию сервиса и предположить, что она уязвима для нападения. Такой сканер даже может обнаружить попытки эксплуатации уязвимости сервиса, то есть выполнить роль системы обнаружения вторжений (Intrusion Detection System, IDS). Такие сканеры не создают дополнительной нагрузки для сети и могут работать постоянно, но их использование не гарантирует обнаружения всех уязвимых сервисов, особенно если они в момент сканирования не используются.
• Сканеры баз данных и Web-сервисов. На рынке появляются специализированные сканеры, которые проверяют защиту не сетевых сервисов, а отдельных приложений. Наиболее часто реализуются инструменты анализа уязвимостей Web-сервисов и баз данных. Эти сервисы являются наиболее частым вектором атаки. Web-приложения нередко бывают уязвимыми для атак, и общими активными сканерами сложно определить их уязвимость, поэтому приходится разрабатывать специализированные сканеры для отдельных приложений.
• Сканеры PCI DSS. Имеются специальные сканеры, которые проверяют соблюдение требований различных стандартов. Сейчас только у стандарта PCI DSS есть система сертификации, которая позволяет выявить, проверяет ли сканер соблюдение требований данного стандарта, в котором предусмотрены регулярные проверки защищенности корпоративной сети банка и процессинговой компании. Возможно, аналогичные системы сертификации появятся и для других стандартов.
Перечисленные типы средств анализа защищенности позволяют определить «белые пятна» информационной системы, над защитой которых стоит поработать.
Новые среды и прежние риски
Наступление новых технологических сред, в частности виртуальных и облачных, в которых «традиционные» средства безопасности почти бесполезны, а новых проверенных решений катастрофически мало, ставит под сомнение эффективность приведенных выше, бесспорно правильных рекомендаций. Новые технологии практически всегда приносят с собой новые риски, иногда совершенно неочевидные с позиции предыдущего опыта. Например, в виртуальной среде появились принципиально новые виды нарушителей вроде суперпользователя — администратора виртуальной инфраструктуры, а также принципиально новые виды атак, невозможные в традиционной среде, — атаки на гипервизор, атаки с одной виртуальной машины на другую в пределах хоста, атаки при переносе виртуальных машин на новый хост, атаки на системы хранения данных, физически разделенные с ESX виртуализированными серверами, и т. п.
Емельянников считает, что с облачными вычислениями ситуация сейчас обстоит еще хуже, поскольку единого, общепринятого определения облачных вычислений не существует, и поставщик услуги зачастую искусно манипулирует самими понятиями безопасности, продавая заведомо незащищеные сервисы. Как обеспечить защиту каналов при передаче данных в систему с нечеткими границами? Как управлять ключами шифрования? Что происходит с информацией пользователя после завершения вычислений в облаке? Как убедиться, что данные, переданные в облако, после оказания услуги надежно уничтожены? На эти и многие другие вопросы очевидных ответов нет. Инциденты с конфиденциальностью и вторичным использованием данных, отсутствием их фактического уничтожения в социальных сетях являются наглядным примером рисков, заложенных в облачных системах.
Решения о возможности использования облачных технологий должны приниматься осознанно, после тщательного анализа как самой инфраструктуры облака, так и механизмов, которые провайдер услуги заявляет как системы обеспечения безопасности. В противном случае экономия на создании собственной вычислительной системы может привести к полной потере контроля над данными.
По мнению Михайлова, при использовании облачных вычислений компании получают преимущество аренды и масштабирования инфраструктуры по мере ее использования, что до некоторой степени снижает риски «белых дыр» безопасности. Однако на первый план выходят риски, связанные с передачей управления инфраструктуры и сервисов контрагентам, — более высокие риски потери данных, краткосрочных и длительных перерывов в обслуживании, утечки конфиденциальной информации.
Время нового аудита
Очевидно, что никакие новые технологии и экономические обстоятельства не отменяют необходимость аудита на предмет выявления уязвимостей в контуре и политиках ИБ. По мнению Разумова, оптимальная частота проведения аудита — один раз в год. Если процессы в организации выстроены, то чаще проводить не стоит. Время от времени следует привлекать к аудиту внешних специалистов.
Впрочем, с выбором аудиторов и консультантов в области ИБ надо быть осторожными. Во всем мире (и в России в том числе) в последние годы развивался и уже успел стать довольно популярным бизнес по выявлению уязвимостей и продаже информации о них производителям больших и дорогих решений уровня инфраструктуры, операционных систем, приложений класса ERP, CRM, OSS/BSS и т. п. Если разработчик не хочет платить, сведения об уязвимости публикуются со всеми вытекающими из этого последствиями для владельцев систем и производителей ПО и оборудования.
Важность аудита сложно оспорить. Но необходимо, чтобы при этом соблюдалось главнейшее условие — высокий уровень квалификации аудитора, а также надежность и эффективность применяемых им технических средств. Следует понимать, что сложные приложения (в частности, многие программные продукты Oracle, SAP, Microsoft), как правило, требуют разработки специальных, именно под них «заточенных» сканеров.
По наблюдению Емельянникова, рынок информационной безопасности в последние годы сильно «вспенен» законом о персональных данных № 152-ФЗ: «На рынок пришли игроки, не имеющие ничего, кроме желания сорвать куш, у них нет ни квалифицированного персонала, ни опыта и компетенций, ни соответствующих технических средств. Работают они часто по демпинговым ценам, и у неопытного заказчика после их “услуг” может сложиться совершенно неверное представление об уровне защищенности своей системы».
И, наконец, следует помнить, что далеко не все уязвимости могут быть выявлены в процессе аудита, в том числе технического. В первую очередь речь идет о ранее незадокументированных уязвимостях, проблемах, не выявляемых стандартными средствами аудита (например, связанных с идентификацией и процедурой доступа к критичным ресурсам), а также об ошибках в построении самого бизнес-процесса, которые существенно влияют на безопасность, потому что аудитор ИБ, как правило, ничего не знает об особенностях бизнеса компании — заказчика его услуг.