Как стать автором
Обновить

ИБ и ИТ, давайте жить дружно. Вот как это возможно

Уровень сложностиСложный
Время на прочтение14 мин
Количество просмотров11K
Всего голосов 16: ↑15 и ↓1+17
Комментарии12

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

Никто не ждет испанскую инквизицию и специалиста по безопасности — тоже.

Потом ты приходишь в касперский и говоришь, а если ли у вас красный лестерский сыр что-то для безопасности виртуальных сред? а , говорят, закончился. И ты - а тильзит и карфилли что с анализом поведения? Нет, говорят - вот есть российский и костромской для серверов и рабочих станций.

Для тех кто не такой старый: цитата и отсылки к шуткам 1970 года

https://ru.wikipedia.org/wiki/Испанская_инквизиция_(Монти_Пайтон)

Раз десять перечитал ваше высказывание, ничего не понял. В рамках всяких SoC за последние полгода пилотировали несколько решений, и как раз у Касперского всяких продуктов, как г. за баней, что больше проблема, чем плюс, так как не понятно что выбрать. Вы имели ввиду какую-то Песочницу? У них явно она есть, только под нее ресурсы ой-ой какие нужны. Или что? У них даже EDR агент кастомные есть именно под виртуальные среды (уж сразу не скажу в чем отличие). В итоге взяли решение не от них, и то лишь по тому, что они тупо дороже (но кстати не самые дорогие по рынку).

давайте жить дружно

Не тот адресат у послания.

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

Все умные фразы во всех учебниках ничто. Потому что рулят чаще всего те, кто никаких учебников не читал. Либо читал что бы отвязались, и ничего там не понял.

Вывод - дружить лучше с начальством. В идеале - начальник должен быть другом всему коллективу.

Ну а ИБ... А что ИБ, выше начальства? Вот им и остаётся лишь учебники писать, которые начальство не читает.

Скажите, а вы ещё кипятите (зачеркнуто) требуете менять пароли каждые N месяцев?

Если вы такие умные, что ж у вас такие стрёмные продукты? Ваш чудесный антивирус пьёт мою кровь литрами и каждый день. Неужели нельзя уменьшить количество ложно-положительных срабатываний? Я вот реально за 8 последних лет видел сотни срабатываний, и ни разу он не поймал вирус. Зато исходники мои жрёт... постоянно.

И самое смешное, что даже в саппорт не написать. Всё, блин, через третьи руки.

ЗЫ: предвосхищая вопрос "а в чём проблема": берёте, делаете git clone исходников chromium, смОтрите на количество убитых файлов в локальном репозитории. Потом смотрите в лог антивируса. Профит.

Да, у них он прям параноидальный. И вся экосистема крутится, почти, вокруг ядра антивируса.

ЗдОрово, что вспомнили незаслуженно игнорируемый продукт-менеджерами ISO 25010! - эта модель лучше всего «мирит» ИТ и ИБ, справедливо относя безопасность к аспектам качества продукта. Взрослые (в смысле SAMM/DSOMM) компании стараются измерять метрики по всем характеристикам качества непрерывно в рамках DevSecOps. «Компартментализация» входит в концепцию Zero Trust в виде микросегментации. Несмотря на проходящий хайп, в ZTA заложены правильные ингредиенты.

И ещё про сближение ИТ и ИБ. Чтобы при приёмке снять вопросы «Почему и откуда взялось это требование?» (любое, не только ИБ), помогает матрица трассировки требований (RTM). В неё на этапе проектирования внести все важные для продукта аспекты качества из ISO 25010, применимые угрозы безопасности и нормативно-правовые требования. По каждому пункту указать, почему появилось это требование, сценарии тестирования и критерии приёмки. RTM работает в обе стороны: от требований к тестовым примерам обеспечивается полное покрытие тестами (TDD), а в обратном направлении мы убеждаемся, что в продукте не появились недокументированные возможности и его скоуп не «поплыл». Если при приёмке какой-нибудь тест не прошел, регистрируется дефект. При отсутствии критичных дефектов релиз едет в Прод…

Не в осведомленности дело. В малом/среднем бизнесе вполне себе совмещаться скилы и ты и чекпоинт настраиваешь и кав разворачиваешь хотя формально админ обычный. И бывает ещё по 152 ФЗ куча всего. У меня так было.


Тут другое- цели ставиться разные рук-вом. В пределе взаимоисключающее.И у директора разные замы отвечают. С позиции управления это понятно- создаться конфликт интересов и контроль. Была бы дружба и любовь- было бы попустительство.

А так- безам не платят за то что бы работало. Им надо что бы было безопасно. Безопасней всего- отключить от серверов кабель. И лучше электричества. И убрать в сейф. точно не взломают.

Безы наверно скажут что разрабам/админам пофиг на безопасность т к у них цели другие- что бы бизнес работал.

То есть конфликт есть. Но где то конструктивный. Где то доходит до странного (вроде обрубание админам доступам через WIn RM на сервера). Бывают курьёзы- на была аварийная ситуация, проводил работы на сервере dhcp. несогласованная фаловер кластер dhcp настроили и сетевое оборудование. Что бы понять что происходит понадобился мне ваер шарк. от системы безопасников прислишол письмо-мол ай ай ай использование несогласованного хакерского ПО (хотя по мне это ПО с которым инфраструктурный админ должен работать). Спросил в ответ -мне работы по критическому инциденту прерывать и согласовывать? безопасник ответил- ну если КИ -используйте. Интересами бизнеса ( и повышением времени простоя) всё же можно апеллировать . Кстати на перехват пакетов через netsh никто не ругается. Хотя риски для ИБ те же

Мысль "давайте чаще встречаться" - верная, двумя руками за. Но кажется, что этого мало. Разработчики редко думают о векторах атаки, поверхности атаки, моделях угроз, безопасности by design. Увы, но это факт. Поэтому их нужно учить - это раз. Как это сделать без отрыва от производства или с минимальным отрывом - отдельный вопрос. А после этого любые требования по безопасности не просто предъявлять, а объяснять - мы запрещаем вот это, потому что ... Проводить встречи, митапы. Если есть понимание важности требования, то острота конфликта снижается

«Для этого надо всего лишь» почаще задавать себе 4 вопроса, которые придумал гуру моделирования угроз Адам Шостак:

  1. Что мы строим?

  2. Что может пойти не так?

  3. Что мы собираемся с этим делать?

  4. Достаточно ли мы сделали, чтобы устранить проблему?

См. https://habr.com/ru/companies/vk/articles/504062/

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

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