Comments 14
К сожалению это действительно так. Сейчас очень распространена атака на цепочку поставок, а так как сервис дески в основном опенсорсное решение и редко когда разработчики занимаются харденингом кода, а если к этому еще добавить огромное количество форков, в которых может быть овердофига закладок и т.п., то пускать в ружу такую систему может быть себе дороже. Обычно сервис дески работают с 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 дня. Ни разу не заходив ни на один из серверов. Не призываю так делать, но будущее рядом.
Не запретительный, а разрешительный :)
Две стратегии:
(Либеральный) Всё разрешено, пока явно не запрещено
Всё запрещено, пока явно не разрешено
Оставим гибридную за рамками…
Первая требует постоянного мониторинга изобретательности людей и выдачи точечных запретов (запретительный орган). В итоге нужно управлять и поддерживать большой список непонятных запретов.
Вторая требует мониторинга, но не совсем такого широкого. В итоге нужно управлять и поддерживать небольшой список понятных разрешений. (разрешительный орган)
А как там устроено на местах - это отдельный вопрос. Где-то ИБ может работать только как супервизор: не предлагает решений, а анализирует предложенные на предмет их допустимости. "Нет" значит “в этом виде не годится, приходите с другим решением”.
Существуют две политики, массовая - палочная, и маргинальная - превентивная.
Первая стала массовой именно потому что вы заметили, это же хоть и информационная но БЕЗОПАСНОСТЬ. А потому как правило на руководящие позиции туда прут пенсы из силовиков, в основном "мусора". Какие вы от них навыки и скилы хотите? Только наказать и палки зарабатывать. Они и в прошлом своём занятии тем же занимались. А вот стратегия (которой стараюсь придерживаться и я в своей работе) превентивная - руководством не поддерживается.
Стратегия, имхо, должна предусматривать всего то несколько принципов:
защита компании от нарушителей
соответствие регуляторики в отрасли
защита сотрудников компании от ошибок
Стиль простой, ИБ должна работать так, чтобы никто и не знал о её работе, а все действия пользователей, отрегулированные политикой в рамках трудовой деятельности, никак не могли создать проблем как системам так и самим пользователям, им не нужно думать о правилах соблюдения ИБ, у них своя работа есть, подчас гораздо сложнее.
Это непростая задача, но решаемая. Главное чётко представлять цели, а способ найдётся.
Долгое время был частенько с ИБ на ножах (персоналка, PCI DSS, банковская тайна, тайна связи. ГИС - это всё с чем работаю, обычно). Но как-то попал в одного телеком провайдера и как-то с ребятами притерлись и нормально сотрудничали, да местами искрило, но был диалог, а не посылания и эскалации.
С тех пор сразу диалог с ИБ:
1) Что хотим сделать, зачем хотим сделать, как хотим сделать, можно насыпать какие бенифиты могут быть для ИБ, если они есть;
2) Если отказ, то прошу примеры векторов атаки => идем прорабатываем концепт, с учётом защиты от указанных векторов. Часто так получалось, что ИБ само давало подсказки в виде каких-нибудь статей
3) Приходим повторно с доработанными предложениями.
4) ИБшники (во множественном числе не просто так, у них бывает много направлений) предлагают докрутки объясняют зачем и почему, плюс у себя какие-то докрутки.
5) Идём считаем во сколько это всё встрянет и сравниваем с планируемым профитом. Если перевешивает профит - идём и делаем.
Пункты 2, 3, 4, обычно, выполняются в цикле, пока, не придете к одному или нескольким вариантам.
Наверное, стоит рассмотреть отдельно, если в организации теоретически есть СС или гостайна, там бесполезно. Сам не сталкивался, но опосредственно наблюдал: "заваривают" так, что проще и дешевле еще раз читануть регламент или местный стандарт ИБ, а потом забить болт
Классный опыт, но он работает на уровне внутри компании, моя рабочая практика быть подрядчиком. И не всегда заказчики готовы идти проделывать шаги 2, 3, 4 даже при условии моего согласия проходить эти шаги совместно и всячески содействовать. Все как всегда на личной инициативе. Спасибо за классный чек-лист.
По моему опыту, личной инициативой и благомини намереньями вымощена дорога к тому самому шкафу, где у рукпроекта хранятся те самые скелеты его неуспешных проектов, поверьте, у меня, за больше чем десяток лет, целое шубохранилище (я правда туда же закидываю успешные проекты, у которых первоначальный виден поменялся, но цели, сроки и бюджет сохранились).
Всегда должен быть business needed, если его нет, то и ничего не будет сделано, либо будет сделано "в стол". Хотя бывало и такое, что из стола доставали через какое-то время, адаптировали и внедряли )))
У меня опыт не только внутри, но с партнёрами и в вендорах. Соглашусь, к вендорам, часто, ИБ относится как к известной субстанции и даже не стесняются об этом говорить прямо 😁 но тут уже вопрос к спонсорам на стороне заказчика
Я не вендр, подрядчик.
У хорошего рукпроекта нет плохих проектов, он чует запах провального проекта до его провала, тактично сливается с него, а потом говорит, что при нем такой фигни не было.
Безусловно, когда есть конкретное велью от инициативы, то она скорее всего пройдет. С этим то все понятно как раз, это стандартная история в отрасли.
Меня больше сам подход смущает. Я все таки за явный процесс, что точно 100% запрещённое, а, что можно рассмотреть и дать доступ, что бы не было всегда во всех случаях "НЕТ".
Приходит ИБ и говорит НЕТ. Защищенный контур, никаких внешних обращений, точка.
если есть изолированная система, то ответ абсолютно верный.
Если просто защищенный сегмент, то нужно затратить возможно большой объем ресурсов, чтобы сделать, чтобы данный сегмент остался защищенным после исполнения ваших желаний.
пс не безопасник. просто админ.
ИБ как запретительный орган: традиция или необходимость?