Обновить

ИБ как запретительный орган: традиция или необходимость?

Уровень сложностиПростой
Время на прочтение2 мин
Охват и читатели7.5K
Всего голосов 4: ↑4 и ↓0+7
Комментарии21

Комментарии 21

К сожалению это действительно так. Сейчас очень распространена атака на цепочку поставок, а так как сервис дески в основном опенсорсное решение и редко когда разработчики занимаются харденингом кода, а если к этому еще добавить огромное количество форков, в которых может быть овердофига закладок и т.п., то пускать в ружу такую систему может быть себе дороже. Обычно сервис дески работают с AD по LDAP, и если с ружи получится скомпрометировать УЗ и повысить привилегии, то game over. Понятно что в зрелых организациях есть FW на границе, возможно даже EDR на конечных точках (хотя бы серверах) и сисадмины даже могут замутить DMZ спецом для такого кейса, но все это упирается во время и нехватку персонала, поэтому либо проект остаётся на бумаге либо чаще просто НЕТ.

Спасибо. Тут дело не в сервис десках (кстати опен сорс решений у энтерпрайз сегмента не видел), думаю с такой проблемой сталкиваются любые классы систем, которые хотят на ружу). Да сервис деск зачастую работает с AD по LDAP, но SSO SAML никто не отменял + всегда есть двухфакторная аутентификация, если подытожить то упираемся в бюджеты и время.

Я такой себе ИБ пофигист, поэтому пускаю клода в свою небольшую рабочую сетку небольшой организации на 30 чел. Настраивает AD вдоль и поперёк. Вычистил кучу техдолга в интранете. В общем имхо вопрос бюджеты-время упирается лишь в уровень доверия ИИ инструментарию.

ИИ инструментарий это относительно новая технология. А вот всякие CRM или ITSM системы используются уже десятки лет, а до сих пор запрещают в некоторых организациях интеграцию с внешними системами. Что касается ИИ тут в первую очередь с людьми нужно работать, что бы не сливали в ИИ конфиденциальную информацию.

Я для тестов свою AD тоже настраивал чрез ИИ, заводя тута десятки тестовых пользователей, групп и т.д.

Недавно клодом 1) поднял новую виртуалку на ESXi c Win2025 2) На нём новый DC 3) старый задемоутил Всё это с ворохом всякого обвеса в sysvol и кастом скриптах, вылечиванием старых проблем в DNS и DHCP из-за собственной криворукости и прочее. За 2 дня. Ни разу не заходив ни на один из серверов. Не призываю так делать, но будущее рядом.

Не запретительный, а разрешительный :)

Две стратегии:

  1. (Либеральный) Всё разрешено, пока явно не запрещено

  2. Всё запрещено, пока явно не разрешено

  3. Оставим гибридную за рамками…

Первая требует постоянного мониторинга изобретательности людей и выдачи точечных запретов (запретительный орган). В итоге нужно управлять и поддерживать большой список непонятных запретов.

Вторая требует мониторинга, но не совсем такого широкого. В итоге нужно управлять и поддерживать небольшой список понятных разрешений. (разрешительный орган)

А как там устроено на местах - это отдельный вопрос. Где-то ИБ может работать только как супервизор: не предлагает решений, а анализирует предложенные на предмет их допустимости. "Нет" значит “в этом виде не годится, приходите с другим решением”.

Спасибо, в таком случае получается, что у каждой команды разработки должен быть личный ибешник, что в целом правильно. Код должен быть безопасным. Иначе я не понимаю как можно приди с другим решением, не имея должной компетенции в составлении таких решениях

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

Существуют две политики, массовая - палочная, и маргинальная - превентивная.

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

Стратегия, имхо, должна предусматривать всего то несколько принципов:

защита компании от нарушителей

соответствие регуляторики в отрасли

защита сотрудников компании от ошибок

Стиль простой, ИБ должна работать так, чтобы никто и не знал о её работе, а все действия пользователей, отрегулированные политикой в рамках трудовой деятельности, никак не могли создать проблем как системам так и самим пользователям, им не нужно думать о правилах соблюдения ИБ, у них своя работа есть, подчас гораздо сложнее.

Это непростая задача, но решаемая. Главное чётко представлять цели, а способ найдётся.

Долгое время был частенько с ИБ на ножах (персоналка, PCI DSS, банковская тайна, тайна связи. ГИС - это всё с чем работаю, обычно). Но как-то попал в одного телеком провайдера и как-то с ребятами притерлись и нормально сотрудничали, да местами искрило, но был диалог, а не посылания и эскалации.

С тех пор сразу диалог с ИБ:

1) Что хотим сделать, зачем хотим сделать, как хотим сделать, можно насыпать какие бенифиты могут быть для ИБ, если они есть;

2) Если отказ, то прошу примеры векторов атаки => идем прорабатываем концепт, с учётом защиты от указанных векторов. Часто так получалось, что ИБ само давало подсказки в виде каких-нибудь статей

3) Приходим повторно с доработанными предложениями.

4) ИБшники (во множественном числе не просто так, у них бывает много направлений) предлагают докрутки объясняют зачем и почему, плюс у себя какие-то докрутки.

5) Идём считаем во сколько это всё встрянет и сравниваем с планируемым профитом. Если перевешивает профит - идём и делаем.

Пункты 2, 3, 4, обычно, выполняются в цикле, пока, не придете к одному или нескольким вариантам.

Наверное, стоит рассмотреть отдельно, если в организации теоретически есть СС или гостайна, там бесполезно. Сам не сталкивался, но опосредственно наблюдал: "заваривают" так, что проще и дешевле еще раз читануть регламент или местный стандарт ИБ, а потом забить болт

Классный опыт, но он работает на уровне внутри компании, моя рабочая практика быть подрядчиком. И не всегда заказчики готовы идти проделывать шаги 2, 3, 4 даже при условии моего согласия проходить эти шаги совместно и всячески содействовать. Все как всегда на личной инициативе. Спасибо за классный чек-лист.

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

Всегда должен быть business needed, если его нет, то и ничего не будет сделано, либо будет сделано "в стол". Хотя бывало и такое, что из стола доставали через какое-то время, адаптировали и внедряли )))

У меня опыт не только внутри, но с партнёрами и в вендорах. Соглашусь, к вендорам, часто, ИБ относится как к известной субстанции и даже не стесняются об этом говорить прямо 😁 но тут уже вопрос к спонсорам на стороне заказчика

Я не вендр, подрядчик.
У хорошего рукпроекта нет плохих проектов, он чует запах провального проекта до его провала, тактично сливается с него, а потом говорит, что при нем такой фигни не было.

Безусловно, когда есть конкретное велью от инициативы, то она скорее всего пройдет. С этим то все понятно как раз, это стандартная история в отрасли.

Меня больше сам подход смущает. Я все таки за явный процесс, что точно 100% запрещённое, а, что можно рассмотреть и дать доступ, что бы не было всегда во всех случаях "НЕТ".

Понятно. Первый кто покидает корабль при виде воды не разобравшись: точно пробоина или прохудилась труба на кухне с питьевой водой. Не осуждаю, но такой подход не уважаю.

Тогда не понимаю: зачем Вам ответы на данные вопросы, если Вы всё равно сольётесь в непонятной/подозрительной ситуации? :) Пусть разбираются те кто остался ;)

Я не РП. Это был сарказм. Есть книжка интересная, там как раз вредные советы, но лично встречал таких РП, которые реально сливаются, потом именно так гвоорят.

У меня вопрос исключительно методологический. ИБ работает так, как работает. Каждый случай взаимодействия с ними на моей практике уникален, есть случае, когда они реально говорят "НЕТ", что я и не поддерживаю так-как считаю, что их задача принять меры и обезопасить, то решение, которое озвучили. Как минимум учувствовать в проработке подходящего решения, а не просто вырубать любые доступы.

Также знаю и встречал случае, где мнения ИБ вообще никого не волнует. Опыт взаимодействия с ИБ имеется.

Мне в первую очередь интересен опыт взаимодействия с ИБ других специалистов, кто как решает с ними проблемы, кто как их убеждает в том, что доступы все таки нужно прорубить.


У меня вопрос исключительно методологический. ИБ работает так, как работает. Каждый случай взаимодействия с ними на моей практике уникален, есть случае, когда они реально говорят "НЕТ", что я и не поддерживаю так-как считаю, что их задача принять меры и обезопасить, то решение, которое озвучили. Как минимум учувствовать в проработке подходящего решения, а не просто вырубать любые доступы.

Ну у меня был случай, когда мне нужно было готовить платежный шлюз к PCI DSS, а у местного ИБ нет такой темы в регламентах: поругались-поскакали-эскалировали. В итоге, вместе сели регламент пилить для организации в параллель с подготовкой, я используя свой предыдущий опыт банках, они свой опыт по защите ПДн и тайны связи. Но тут бизнес был заинтересован отжиматься, и да я работал в подрядчике-вендоре.

Также знаю и встречал случае, где мнения ИБ вообще никого не волнует. Опыт взаимодействия с ИБ имеется.

Я таких тоже знаю и сразу вываливаются ситуации со СДЭК, Яндекс-Едой, М-Видео, Спортмастер. Сейчас ИБ проще делает: пишут специальную бумажечку с отказом от ответственности, если их требования игнорируют. А потом, если что-то вдруг происходит: увозят не ИБшника, а конкретное лицо, которое нарушело. Как-то было такое: сидим работаем, слышим за дверью кабинета шум-гам-суета, выглядываем, а там маски-шоу тащат кого-то уже по коридору. Потом новенькая тачка этого челика года три возле офиса опечатанная стояла-пылилась.

Приходит ИБ и говорит НЕТ. Защищенный контур, никаких внешних обращений, точка.

если есть изолированная система, то ответ абсолютно верный.

Если просто защищенный сегмент, то нужно затратить возможно большой объем ресурсов, чтобы сделать, чтобы данный сегмент остался защищенным после исполнения ваших желаний.

пс не безопасник. просто админ.

Соглашусь про больший объем ресурсов. Спасибо

Всё верно, ИБ это классический бюрократический орган, который имеет власть, и не несёт никакой ответственности.

Их деятельность буквально описана в анекдоте про "как пожар — так хоть увольняйся". Запретить? Всегда готовы! Твёрдо, чётко, непоколебимо. Допустили атаку и кражу данных? Страдает бизнес, которому мешают нормально работать? Виноваты менеджеры, виноваты их лиды, виноваты смежные команды, и едва ли не сам Верховный Главнокомандующий виноват.

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

В сегодняшней реальности это просто бюрократы, первоочередная задача которых состоит в обосновании собственной необходимости и наличия полномочий, а случись чего — виноват менеджер, который оставил бумажку с паролем на столе, а ИБ тут не при чём.

Соглашусь, что виноват всегда кто-то еще.
Спасибо за комментарий

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации