Comments 7
Одна из основных проблем ИБ, которая должна идти вторым пунктом (у вас про это почему-то вообще ни слова) — как повлияют вводимые стандарты на процессы в компании, к чему приведут и вообще выполнимо ли то что написано на бумаге?
Вот с последним чаще всего и возникает проблема. Причем самое печальное, что возникает она в 1 случае из 100, но при этом виноватым делают человека который вообще ни при чем.
Возьмем ПД, 152-ФЗ и все такое. Выпускаем регламент, приказ и пучек бумаг. Ставим IDS\IPS\SIEM и прочие страшные штуки, ПД хранятся всейфе защищенном периметре, доступ к которому у 1.5 бухгалетров и отдела кадров. Почта, траффик анализируется и наружу ничего не предается, даже если очень захотеть.
И вроде бы все хорошо ровно до того момента, как пуско-наладчику не надо отправиться на какой-нибудь дальний военный\атомный\НИИ\гос\нефе\хим. объект за 1000+ км.
Итак, имеем менеджера которому надо организовать пропуск. Для пропуска на объект надо предоставить паспортные данные.
Дальше два варианта — отправка лично\голубиной почтой заказным письмом. Что заведомо невозможно. Сроки горят, генеральный орет.
Второе, обход всей системы ИБ (каким именно образом — приказным, обманным или хитростным оставим за скобками).
Второй момент никто никогда почему-то на совещаниях не говорит об увеличении срока работ персонала.
-С завтрашнего дня никаких административных прав пользователям!
-Ок. Но вот наш пуско-наладчик поедет за 1200 км. в сибрирь, на вышку, настраивать какой-ндь частотник и окажется, что потребуется специфическое ПО для этой самой наладки и что мы будем делать? Админа туда отправлять? Или он будет после каждой рекомендации производителя звонить админу на «переставить\обновить\подключить\отключить?» Т.е. у нас время наладки будет увеличено на х часов? По факту, свободных админов не будет\дело будет ночью и реально у нас все сроки увеличиваются на х дней?
Таких примеров можно насобирать пучек и вот на бумаге все хорошо, да в реальности у людей на рабочем месте стоит офисный ПК для отправки писем и личный ноутбук для выполнения трудовых обязанностей так сказать вопреки.
Понятно дело, есть ряд мер которые на работу персонала и производственные процессы не влияют. Но моя основная претензия к ИБ — нежелании думать как бы так и от угроз защититься и при это внести минимальное влияние на производственный процесс.
Вот с последним чаще всего и возникает проблема. Причем самое печальное, что возникает она в 1 случае из 100, но при этом виноватым делают человека который вообще ни при чем.
Возьмем ПД, 152-ФЗ и все такое. Выпускаем регламент, приказ и пучек бумаг. Ставим IDS\IPS\SIEM и прочие страшные штуки, ПД хранятся в
И вроде бы все хорошо ровно до того момента, как пуско-наладчику не надо отправиться на какой-нибудь дальний военный\атомный\НИИ\гос\нефе\хим. объект за 1000+ км.
Итак, имеем менеджера которому надо организовать пропуск. Для пропуска на объект надо предоставить паспортные данные.
Дальше два варианта — отправка лично\
Второе, обход всей системы ИБ (каким именно образом — приказным, обманным или хитростным оставим за скобками).
Второй момент никто никогда почему-то на совещаниях не говорит об увеличении срока работ персонала.
-С завтрашнего дня никаких административных прав пользователям!
-Ок. Но вот наш пуско-наладчик поедет за 1200 км. в сибрирь, на вышку, настраивать какой-ндь частотник и окажется, что потребуется специфическое ПО для этой самой наладки и что мы будем делать? Админа туда отправлять? Или он будет после каждой рекомендации производителя звонить админу на «переставить\обновить\подключить\отключить?» Т.е. у нас время наладки будет увеличено на х часов? По факту, свободных админов не будет\дело будет ночью и реально у нас все сроки увеличиваются на х дней?
Таких примеров можно насобирать пучек и вот на бумаге все хорошо, да в реальности у людей на рабочем месте стоит офисный ПК для отправки писем и личный ноутбук для выполнения трудовых обязанностей так сказать вопреки.
Понятно дело, есть ряд мер которые на работу персонала и производственные процессы не влияют. Но моя основная претензия к ИБ — нежелании думать как бы так и от угроз защититься и при это внести минимальное влияние на производственный процесс.
Согласен, оценка влияния на процессы обязательна должна проводиться. И мы при разработке техстандарта это учитывали. В нашем случае можно говорить о двух случаях.
1. Оценка влияния на процессы ИБ. Тут нам было в каком-то смысле проще т.к. в нашу же задачу входило проектирование процессов ИБ. Соответственно, проектировали мы с учетом требований разработанного стандарта. Причем разработка стандарта велась итеративно. Т.е. сначала был разработан стандарт и мы понимали, что какие-то требования там могут не заработать ввиду особенностей ИТ и ИБ-инфраструктуры. Поэтому никто разработанный стандарт не спешил утверждать. По мере проектирования процессов ИБ мы корректировали стандарт. Финальная же ревизия и корректировка стандарта была выполнена только после того как все процессы ИБ были спроектированы, задокументированны и согласованы.
2. Оценка влияния на бизнес-процессы. При разработке технического стандарта постоянно велось взаимодействие с подразделениями, которых он прямо или косвенно касался. Постоянно вырабатывались решения, чтобы не попасть в описываемую вами ситуацию. При этом, в стандарте есть ряд исключений и четко описаны случаи, когда от его требований можно отступать. Это делось в т.ч. с целью минимизации потери времени в критически важных ситуациях. Все отступления от требований стандарта осуществляются под контролем ИБ-подразделения.
Также добавлю, что описываемая вами ситуация достаточна частая для бизнеса. Мы придерживаемся подхода, что ИБ должна быть разумной и не идти вразрез с целями и задачами бизнеса.
1. Оценка влияния на процессы ИБ. Тут нам было в каком-то смысле проще т.к. в нашу же задачу входило проектирование процессов ИБ. Соответственно, проектировали мы с учетом требований разработанного стандарта. Причем разработка стандарта велась итеративно. Т.е. сначала был разработан стандарт и мы понимали, что какие-то требования там могут не заработать ввиду особенностей ИТ и ИБ-инфраструктуры. Поэтому никто разработанный стандарт не спешил утверждать. По мере проектирования процессов ИБ мы корректировали стандарт. Финальная же ревизия и корректировка стандарта была выполнена только после того как все процессы ИБ были спроектированы, задокументированны и согласованы.
2. Оценка влияния на бизнес-процессы. При разработке технического стандарта постоянно велось взаимодействие с подразделениями, которых он прямо или косвенно касался. Постоянно вырабатывались решения, чтобы не попасть в описываемую вами ситуацию. При этом, в стандарте есть ряд исключений и четко описаны случаи, когда от его требований можно отступать. Это делось в т.ч. с целью минимизации потери времени в критически важных ситуациях. Все отступления от требований стандарта осуществляются под контролем ИБ-подразделения.
Также добавлю, что описываемая вами ситуация достаточна частая для бизнеса. Мы придерживаемся подхода, что ИБ должна быть разумной и не идти вразрез с целями и задачами бизнеса.
-Ок. Но вот наш пуско-наладчик поедет за 1200 км. в сибрирь, на вышку, настраивать какой-ндь частотник и окажется, что потребуется специфическое ПО для этой самой наладки и что мы будем делать?
Если наладчик работает не в шарашке (с такими-то требованиями к документации) то такой ситуации в принципе не может быть.
Всё оборудование наглухо засертифицировано и весь нужный софт в наличии, а ненужного и нет.
А дуракам оно и не должно помочь.
Если наладчик работает не в шарашке (с такими-то требованиями к документации) то такой ситуации в принципе не может быть.
Вы не работали в полях. Вы не работали с оборудованием АСУ ТП, там местами такой махровый легаси встречается. Реальный случай из жизни — есть коммутаторы производителя начинающегося на Н, конфигурировались через веб-морду и все было хорошо до тех пор пока из всех браузеров не выпили поддержку аплетов джавы. Про протухшие сертификаты вообще говорить не приходится. Звонок производителю и «Вот мы выпустили специальное ПО ставьте...» Если вы не работает с этим оборудованием постоянно то увы узнать о такой проблеме можно только столкнувшись.
Второй пример — заказчик хочет определенный функционал плюс кое-чего не работает, звоним производителю. А дальше дословно «Не, у нас такого нет, но вы можете допилить сами, вот вам сорсы, вот инструкция по сборке...». И да это был МЭК61850, а оборудование требование заказчика.
Третье — знаете сколько оборудования работает ТОЛЬКО с определенной версией ПО\прошивкой\драйвером?
В общем, работать постоянно с одиним вендором это конечно хорошо и приятно, но не когда ты интегратор и каждый заказчик хочет свое, да еще и с модернизацией лет через 5-10.
У меня есть железяки, работающие ещё под 6.22
и строго под 3.1.
специально для них на антресоли лежат Тошиба T4400C и Юнисбук.
Раз в два-три года пригождаются, каждым вытиранием пыли принося столько денёг, сколько я когда-то отдал за них.
Это, на минуточку, с 1995 и 1998 года примерно.
А выверты заказчиков — к прибыли исполнителей.
и строго под 3.1.
специально для них на антресоли лежат Тошиба T4400C и Юнисбук.
Раз в два-три года пригождаются, каждым вытиранием пыли принося столько денёг, сколько я когда-то отдал за них.
Это, на минуточку, с 1995 и 1998 года примерно.
А выверты заказчиков — к прибыли исполнителей.
Больше бумаг — чище жо па.
Тут должна быть какая нибудь шутка о применимости заглавной фотографии в контексте печальной судьбы объекта, где она сделана. :)
Sign up to leave a comment.
Как писать техстандарт по защите информации для крупной компании