Лебедь, рак и щука информационной безопасности

Современные службы информационной безопасности (да и регуляторы заодно) сегодня стоят перед непростым выбором - как строить систему корпоративной (или ведомственной) защиты? Еще несколько лет назад такого выбора и в помине не было. Парадигма была проста - внутри злоумышленника быть не могло и поэтому защищаться надо было на периметре (и даже если он был, его можно было остановить на периметре); оборона должна быть эшелонированной; и конечно же, обеспечивать ИБ должно само предприятие. Так было вчера. А что сегодня?

А сегодня картина полностью изменилась (и кто знает, что будет завтра). Начнем с того, что чисто периметровая защита уже мало что решает. И установка на ПК антивируса тоже. И на DLP на серверах... Нужна полноценная защита внутренней сети, которая позволяет охватить взглядом всю инфраструктуру и все сетевые потоки, проходящие по ней - от ПК к серверам, между виртуальными машинами, от камер видеонаблюдения к видео-хранилищу, от принтера к Интернет, от СКУД куда-нибудь еще. Нужен именно всесторонний контроль, который позволит отследить то, что пропускают точечные средства защиты, эффективность которых зависит от того, где они установлены. Не лишним будет напомнить, что сетевое оборудование (коммутаторы, включая виртуальные, маршрутизаторы, точки и контроллеры беспроводного доступа) должны участвовать в процессе сбора информации, на базе которой будет приниматься решение о нарушении политик безопасности (и неплохо бы, если бы то же сетевое оборудование будет еще и точкой применения политик ИБ). Но это только начало.

У нас на повестке дня стоит и другой вопрос - эшелонированная или нет? Раньше (да и сейчас) нередко звучат рекомендации построения системы защиты, состоящей из нескольких уровней, которые последовательно должен пройти злоумышленник, чтобы получить доступ к защищаемому ресурсу. Но это красиво выглядит в теории, а что в реальной жизни? А на практике потребитель не готов платить за 6 последовательно установленных средств защиты (МСЭ, VPN, IPS, антивирус и контентный шлюз для анализа e-mail и Web). И за 3 тоже не хочет. И за два. Он готов заплатить за одну "железку", этакую "серебянную пулю", которая избавит его от всех хлопот с безопасностью. И находится немало желающих такую "пулю" разработать и предложить. А потребитель, особенно в условиях нехватки бюджета и его сокращения, готов с радостью ее купить. Так появляются средства класса UTM. Не скажу, что я большой сторонник объединения "все в одном" - я считаю, что это снижает защищенность (хотя эшелонированная оборона повышает сложность). Но что поделать, условия рынку диктует потребитель. Он хочет получить все в одном, да еще и подешевле? Он его получает. Но правильно ли это? Это вопрос.

Но и это не все вопросы, стоящие на повестке дня руководителя службы ИБ. Дальше возникает вопрос, к которому до сих пор многие безопасники относятся с подозрением. Речь идет об аутсорсинге ИБ и, как новомодное развитие, об облачной безопасности, которую вам организует третье лицо, нанятое по договору. Вообще, это кошмар для безопасника - отдать в третьи руки свою безопасность и не иметь (почти) возможности по управлению ею. В страшном сне такое не приснится. Кто-то к ней обращается вынужденно (например, при переходе к облачным вычислениям или аренде ЦОДа). Некоторые компании вполне осознанно переходят к этой модели, сосредотачивая в своих руках преимущественно контрольные функции. Единственно верного ответа тут тоже нет. Каждый должен ответить для себя сам.

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

ЗЫ. Хуже всего в такой ситуации регуляторам, которым невозможно выбирать одно, единственно верное решение и отталкиваясь от него, выстраивать свои нормативные документы. Это как раз тот случай, когда ставить на одну лошадь нельзя; не факт, что именно она придет первой. А для этого нужно сценарное планирование (security foresight), которое пока у нас находится в зачаточном состоянии.