Контакты
Подписка
МЕНЮ
Контакты
Подписка

ИТ&ИБ: кто сверху?

Мона Архипова, 17/12/18

arhipovaРечь в данной статье пойдет не о безопасности в целом, а об ИТ-направлении отрасли (оно же компьютерная безопасность или, в более широком плане, кибербезопасность).

Немного истории

ИТ-безопасность как отдельное направление защиты информации начала оформляться только в 1990-х гг., вместе с массовой цифровизацией почти всех технологий. Наверное, главной вехой стоит считать начало разработки Common Criteria for IT Security Evaluation (свод общих критериев), который, в свою очередь, обобщил, упорядочил и обогатил опыт использования "Оранжевой книги" АНБ США (Trusted Computer System Evaluation Criteria).

Однако то, что сейчас принято называть системами ИТ-безопасности,  появилось намного раньше, чем были приняты все эти замечательные документы. Например, первые файрволы и антивирусы появились еще в 80-х гг., а прадедушка современных SIEM – и того раньше, первые системы ADP известны с середины 1970-х гг.

Курица или яйцо

До конца 1990-х ни о каких выделенных специалистах по ИT-безопасности в бизнесе и речи не было. Равно как и хакеры были всего лишь талантливыми программистами, без современного зловещего образа.

Задачи современной ИТ-безопасности с первых больших мейнфреймов и вплоть до появления доступных ПК решались силами системных операторов, профессия которых со временем трансформировалась в современных системных администраторов и инженеров.

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

Да будет ИT-безопасность!

Казалось бы, все логично, появилось новое направление, практики, отточенные на военных технологиях, стали общедоступными, бери и делай. Появилась та самая безопасность, которую мы видим сейчас и о которой говорят на несчетном количестве различных конференций. Но вместе с этим началось и внутреннее разделение "безопасников" на более узкие профили в рамках тех же стандартов: инфраструктура, приложения, соответствие требованиям. Разделение в основном было вызвано тем, что одновременно качественно изучить новые аспекты один человек был физически не в состоянии, а бизнесу тем временем продавали, а местами и насаживали требования соответствия новым реалиям. Не-ИТ-специализации в том или ином виде уже были задолго до массового распространения технологий: физический и экономический профиль, риски, непрерывность бизнеса. Новые стандарты лишь объединили эти разноплановые направления воедино, дав нам процессный подход и понимание, что обеспечение защиты информации стало намного шире и сложнее. Но вместе с этим начались проблемы совсем другого рода.

Ожидание vs реальность

Ожидание: мы внедрим стандарты и нас точно никто не поломает, все будут рады нам помочь.

Реальность глазами "типичного безопасника": админы ленивые, не устраняют уязвимости на вон том старом сервере, не хотят нам включать полный аудит, сеть плоская, мы купили решение, которое приводит к отказу ключевой системы.

Почему так вышло? Не все стандарты одинаково полезны, не всем пунктам можно (и нужно) дословно следовать. К сожалению, основная претензия со стороны ИТ к безопасности заключается в том, что не всегда уровень технической компетенции последних успевает за технологиями. К сожалению или к счастью, но факт: хороший специалист по безопасности получается из бывшего админа, программиста или специалиста по тестированию. То есть из тех людей, которые могут не только сказать "надо сделать так", но и перевести это с формального сухого языка требований на реальные примеры и технические требования. К тому же всегда нужно смотреть шире и оценивать проблемы с безопасностью не только на уровне веса уязвимости и ее вектора, но и с точки зрения бизнеса.

Быстрее, выше… Сильнее ли?

Любой новый процесс вызывает отторжение. Сейчас это вопросы безопасности, в свое время такое же неприятие вызывали новомодные практики ITIL (IT Infrastructure Library - библиотека инфраструктуры информационных технологий). Тем не менее любое внедрение систем безопасности по классике ведет к усложнению процесса для пользователя – неважно, конечного клиента или внутреннего высокопривилегированного пользователя в лице сисадмина. И все эти нововведения идут вразрез с той скоростью, с которой сейчас живет бизнес. Мы смеемся над "Agile для HR", зачастую упуская из вида причины популярности подобных подходов. А примеры-то у нас все перед глазами: когда-то для создания почты на своем домене нужно было делать почтовый сервер и обслуживать его. Теперь же за $5 можно получить все и сразу, и даже без необходимости нанимать системного администратора. То же самое с любыми другими облачными сервисами и серверами: зачем платить такие космические деньги за серверы, лицензии и людей, если все можно вот тут быстренько развернуть. А про безопасность отдельный раздел на сайте написан – значит они безопасные. Однако в случае форс-мажора вроде блокировок одного крупного облака  виноваты будут ИТ… Ну или СБ, за то, что не предусмотрели эту, как ее там, доступность. Но это уже совсем другая история.

(R)evolution

Изначальная ИТ-безопасность если не умерла, то уже начинает трансформацию. Вернее, возвращение к истокам с качественными изменениями. В 2008 г., после ряда громких взломов, институт SANS начал разрабатывать "Критичные контроли безопасности" – минимально необходимый набор из 20 контролей для обеспечения базового уровня ИТ-безопасности в организациях. В 2013 г. этот документ был передан в Council on Cyber Security, а в 2015 г. – в  Center for Internet Security (CIS). Контроли делятся на три части: базовые, фундаментальные и организационные. И практически все эти контроли (кроме, пожалуй, организационных) можно выполнить силами исключительно ИТ-подразделений, они перекликаются с имеющимися в большинстве организаций системами. Взять хотя бы базовый набор, на основе которого строятся все дальнейшие:

  • CSC 1 – инвентаризация и контроль железа. Как правило, у администраторов в том или ином виде это уже есть. От файла с табличкой со списком серверов и пользовательских ПК до систем централизованного управления и/или мониторинга;
  • CSC 2 – инвентаризация и контроль ПО. Если нет - решаемо системами из CSC 1 или же банальными скриптами;
  • CSC 3 – управление уязвимостями. Тут всё несколько сложнее, но в конечном итоге обновлениями серверов будут заниматься всё те же администраторы. Впрочем, при наличии любого более-менее современного сканера с возможностью генерации отчетов в почту или системы управления задачами роль безопасности сводится только к контролю и периодической интерпретации;
  • CSC 4 – управление административными привилегиями. Банальная ИТ-гигиена "не ходи под рутом", отсутствие общих учетных записей и контроль появления новых. Впрочем, этот пункт администраторы обходят и при наличии штатного "безопасника", например на короткий срок отключив логирование событий. И намного разумнее делегировать проверку этого контроля и ответственность за исполнение оного не только системам мониторинга, но и людям внутри ИТ;
  • CSC 5 – безопасные конфигурации оборудования и ПО на всех устройствах. Исполнять это опять же будут специалисты ИТ-подразделения и опять же,набором ПО из первых двух пунктов. Роль специалиста по безопасности тут относительно одноразовая – создание стандартов и поддержание их списка в актуальном виде. Но можно обойтись и общедоступными CIS Benchmarks, в которых достаточно подробно разъяснено, зачем делается та или иная настройка;
  • CSC 6 – мониторинг и анализ логов аудита. Достаточно вспомнить, что SIEM-системы выросли из обычного ИТ-контроля, а именно управления логами (LM – лог-менеджмент систем).

Фундаментальные же контроли безопасности в большинстве организаций и так уже выполняются администраторами – создание резервных копий, антивирусная защита, администрирование сетевого оборудования, управление доступом и учетные записи. Так что, пожалуй, единственное, где специалисты по безопасности заменяются с трудом, – это тренинги персонала, реагирование на инциденты и обеспечение безопасности приложений.

Но с безопасностью приложений тоже не все так однозначно. Да, "взломы" выглядят очень эффектно, но хорошие специалисты по безопасности приложений – это те самые исторические "хакеры", т.е. программисты со знанием безопасности. Также проверки на OWASP top-10 (самые "детские" уязвимости) могут выполняться QA и встраиваться в процесс обычного тестирования. Конечно, это не будет панацеей от всех бед, и если ваш основной бизнес связан с работой приложений или сайта, то полностью полагаться на подобный процесс не стоит. Но эксперт по безопасности приложений может находиться и среди разработки.

Post-mortem

ИТ-безопасность как отдельная функция – умирает. Она не успевает ни за ИТ, ни за разработкой, ни за скоростью бизнеса в целом. Да и кадровый голод способствует тому, что функция если не мертва, то уже близка к этому. Хорошего программиста можно научить нюансам безопасности. Хорошего тестировщика можно научить искать уязвимости. Матерому системному администратору можно объяснить, как распознать компрометированный сервер или защититься. Да даже специалиста по мониторингу можно научить распознавать инцидент (он и так это делает, только в ИТ). Специалиста, который послушал учебную программу по безопасности и прочитал два стандарта, быстро обучить глубоко понимать практические аспекты невозможно.

Фундаментально нет различий между процессами ISOC и инфраструктурным мониторингом, эксплуатацией ИТ и ИБ, ИТ-тестированием и ИБ-тестированием.

Поэтому – хватит спорить, кто главнее!

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

Да, есть очень большой риск – "конфликт интересов" и рычаг пропуска небезопасных решений. Но опция "я принимаю риск" есть и при существующих службах безопасности.

А если нет разницы – зачем платить больше?

Полную версию статьи читайте в четвертом номере журнала Information Security.

Чтобы стать рекламодателем следующего пятого номера, заполните форму ниже.

СТАТЬ РЕКЛАМОДАТЕЛЕМ

Темы:УправлениеМона Архипова
Комментарии