Здравствуйте, уважаемые радиослушатели, менеджеры, программисты, админы и все-все-все. Сегодня я выскажусь о наболевшей теме, время от времени вызывающей у меня острую зубовную боль, а именно — об информационной безопасности на предприятии.
Что собой представляет ИБ на крупном предприятии или даже банке? Жгучий коктейль из нормативных актов, густо приправленных запретами всего и вся и с добавлением угроз расправы по вкусу. Ведь что делает обычный администратор системы для предотвращения несанкционированного доступа? Запрещает всё, что не разрешено. Что делает обычный безопасник? Запрещает вообще всё, что находится на границе (а часто и за границей) здравого смысла и хоть какой-то возможности функционирования предприятия. При этом составляется огромное количество нудных описаний угроз, нормативных актов (скука!) и прочих устрашающих действий, все которые сводятся к одной простой мысли «ЕСЛИ ЧТО, МЫ ЖЕ ПРЕДУПРЕЖДАЛИ!». Таким образом, складывается ситуация, когда ИБ риски обозначает, но ответственность не несет — её несут сотрудники. Однако и пренебрегать этой мутной темой информационной безопасности руководители не могут и в результате ИБ на предприятии все процессы заворачиваются на ИБ, и ИБ становится тем узким бутылочным горлышком, от ширины которого часто напрямую зависит скорость функционирования бизнеса предприятия в целом.
C горячей и горящей частью опуса закончу, не за эмоции речь, переключаемся на конструктив. Все, кто с этим сталкивался, поймет и немало дополнит. Речь сейчас хочу завести о том, что с этим делать? Ведь в основе ИБ на предприятии лежит крайне конструктивная и разумная цель — предотвращение утечек данных, которые потом по этому самому предприятию могут вдарить, и часто — очень больно. Здесь стоит учесть не только (и не столько) финансовые риски, сколько репутационные и прочие другие риски, которые несомненно исполнились бы, когда-нибудь бы, возможно бы, *-бы *-бы *-бы.
Основные кейсы, которые пытается закрыть собой ИБ на мой недальновидный взгляд, такие:
1. Пресечение НСД (несанкционированный доступ, мы же о ИБ говорим, будем использовать тысячи сокращений) ко всякого рода БД, СХД, серверам (не знаю как сократить), помещениям с серверами и БД. Сие есть самая главная цель в функциональности ИБ, и они с ней справляются очень хорошо. Огромные тучи железа и ПО, созданные как раз для этих целей, вполне способствуют пресечением НСД, ловле и расследованию инцидентов ИБ.
2. Ограничение НСД «из вне». Ну тут всё понятно. Вкупе с програмнно-аппаратными комплексами из первого пункта решение этих типовых задач сложности не представляет.
3. Ограничение НСД «из нутрей» организации ко всему тому, что перечислено в п 1. Здесь несколько подробней, т.к. главная угроза НСД в ИБ — сотрудник предприятия — преобладает в качестве потенциальной угрозы. К указанному оборудованию, перво-наперво, необходим доступ админам всех мастей, программистам иили аналитикам, и иногда непосредственно бизнесу, который использует какое-нибудь ПО для верчения данных, отчётов, и всего такого, что ему, бизнесу, надо. Как ни странно, здесь уровень сложностей и проблем, создаваемых ИБ, не так высок. Т.к. админам доступ нужен для своей админской магии, аналитики часто просто работают на ПО, которое поставили админы, бизнес «сказал надо, значит надо» и ему сделали доступ, потому что ИБ работает на бизнес, а не наоборот. Больше всех страдают разработчики, которым подавай сервера, доступы, непонятное ПО, самописное непонятное ПО, при этом чтобы и данные были живые. Всё это подпадает по собственноручно написанные нормативные акты и какие-нибудь-ещё акты, приказы, нормы, угрозы-риски, которые же сами безопасники и написали в ходе трудовой деятельности. Здесь и срабатывает эффект бутылочного горлышка, что пока разработчики вкупе с менеджерами согласуют (если это вообще возможно) все эти бесконечные согласования, то бизнес стоит и ждёт. Потому что сам поймал себя в ловушку картбланша для ИБ, потому что не продумал механизм эскалации рисков и их оценки, потому что вникать и понять этот пласт информационных угроз, которые, на минуточку, включают практически весь спектр IT-дисциплин, ну просто невозможно.
Какие варианты выхода из ситуации я вижу (придумал, прочувствовал):
1. Первый, он же главный, возможность принятия рисков руководителем бизнес-подразделения, который заказывает что-то, что упёрлось в сложность согласования ИБшниками. Очень часто бизнесу нужны инструменты, которые должны быстро решитьпроверить какую-нибудь мысльконцепт руководителя. Эти точечные, или акупунктурные, уколы могут быть очень действенны и полезны для выполнения бизнес-задач. И если с другой долгой тягомотиной — закупкой оборудования — вопрос можно решить обратившись к хостингам, то вопрос ИБ встает в полный рост. Данные, которые нужно обработать, находятся во внутренних системах и их нужно передать в системы внешние. Тут два есть два варианта: очень долгий и быстрый неправомерный. Думаю, не стоит объяснять, каким вариантом чаще пользуются люди, которым нужно выполнить задачу.
2. Построениесокращение списка критичных ресурсов и построение ОЧЕНЬ защищенной прослойки между всеми остальными системами и этими супер защищенными системами. Вот там есть где развернуться во всю ширь и мощь. Наверняка, это и часто применяется, но список угроз, которые пытается объять ИБ такой огромный, что сами безопасники бы захлебнулись (что нередко и бывает), если хотя бы половину из них закрывали по нормам-порядкам защиты от ИБ. Остальные же системы ограничить штатными средствами антивирусов, политик доменной безопасности, но без ущемления функциональности.
3. Упрощение деятельности по согласованию всех своих же ограничений. Ведь они все равно будут согласованы, потому что «нужно», но это сэкономит гекалитры крови, пролитой на полях аутлучных согласований.
В заключении хотел бы выразить благодарность тем адекватным, понятливым и гибким безопасникам, которых я еще не встречал.
С любовью, ненавистью и пониманием,
%работникнейм%
Автор: Crossover
