15.07.2013

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

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

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

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

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

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

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

5 коммент.:

ZZubra комментирует...

В зачаточном состоянии у нас наличие описанной инфраструктуры и ВСЕХ сетевых потоков. А до их анализа, а тем более защиты - как до Марса пешком и без скафандра.

arkanoid комментирует...

Это когда было такое "вчера", что-то я не помню?

ZZubra комментирует...

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

arkanoid комментирует...

а чего интересного на эту тему есть на нероссийском?

ZZubra комментирует...

Оччень давно я копал в эту сторону. Но попытаюсь вспомнить:
1. Очень наглядно, особенно на видео на главной с 01:23
2. Вообще мини обзор продуктов: http://www.businesstuning.ru/pm/56-obzor-programm-dlya-modelirovaniya-biznes-processov.html
3. еще: http://www.escom-bpm.com/products/applied_solution.php?ID=51
4. еще: http://www.deskwork.ru/View.aspx?page=bpeditor (это наше но ограничено в применении только для самого продукта)
5. еще: http://ru.wikipedia.org/wiki/ERwin_Data_Modeler - вроде вообще считается чуть не эталоном (но не уверен)
6. http://ru.wikipedia.org/wiki/BPMN - это собственно от чего все отталкивается и что реализуется, хотя применяют и стандарты IDEF (http://ru.wikipedia.org/w/index.php?search=idef&title=%D0%A1%D0%BB%D1%83%D0%B6%D0%B5%D0%B1%D0%BD%D0%B0%D1%8F%3A%D0%9F%D0%BE%D0%B8%D1%81%D0%BA). Причем IDEF "типа крута" - создавался военными, долго и много денег на него потратили. Лучше всего его рассматривать как совокупность стандартов (как срезы одной большой задачи). Если не ошибаюсь сейчас от него перешли/переходят на FEAF - http://en.wikipedia.org/wiki/Federal_Enterprise_Architecture_Framework

Естественно под "их" стандарты на "их" рынке быстренько появляются продукты убирающие рутину. А их заказчики (госы и комерсанты) не стесняются заказать документацию по BPMN, IDEF или FEA. Хотя, наверняка, у них так же весело как и у нас ))) Об этом написано в "Архитектура и стратегия" Слюсаренко и Данилина. Но продукты есть.

ЗЫ Надеюсь удалось ответить на вопрос ;)