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

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

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

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

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

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

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

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

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

Казалось бы, все логично, появилось новое направление, практики, отточенные на военных технологиях, стали общедоступными, бери и делай. Истории про злых хакеров, помноженные на "проблему 2000 года" (то, что в наши дни называется "хайп") давали должный уровень внимания и финансирования. Начали появляться профильные специальности в вузах и первые выпускники. Начали налаживаться первые процессы, стандарты в области безопасности пошли в ногу со временем, появился обновленный ISO/IEC 27001:2005, вместе с ним стали появляться и отраслевые стандарты вроде PCI DSS (Payment Card Industry Data Security Standard – стандарт безопасности данных индустрии платежных карт). Появилась та самая безопасность, которую мы видим сейчас и о которой говорят на несчетном количестве различных конференций. Но вместе с этим началось и внутреннее разделение "безопасников" на более узкие профили в рамках тех же стандартов: инфраструктура, приложения, соответствие требованиям. Разделение в основном было вызвано тем, что одновременно качественно изучить новые аспекты один человек был физически не в состоянии, а бизнесу тем временем продавали, а местами и насаживали требования соответствия новым реалиям. Не-ИТ-специализации в том или ином виде уже были задолго до массового распространения технологий: физический и экономический профиль, риски, непрерывность бизнеса. Новые стандарты лишь объединили эти разноплановые направления воедино, дав нам процессный подход и понимание, что обеспечение защиты информации стало намного шире и сложнее. Но вместе с этим начались проблемы совсем другого рода.

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

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

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

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

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

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

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

(R)evolution

На самом деле в ИТ те же самые проблемы, что и в безопасности. Новых технологий с низким порогом вхождения все больше (чего только стоит новомодный Docker, эволюционировавший из LXC… А что такое FreeBSD jail 2000 г. сейчас, наверное, никто и не вспомнит), и проблема человеческого фактора начинает стоять острее, чем когда основной угрозой были пользователи с низким уровнем компьютерной грамотности. Головная боль ИТ-департаментов – чтобы все работало как надо и было доступно. Головная боль СБ – минимизировать риски и повысить стоимость атаки. А бизнес-подразделения вспоминают про ИТ или СБ только тогда, когда что-то не работает или же произошел резонансный инцидент (если, конечно, основной бизнес компании не связан с этими направлениями). В это же время практически все современные стандарты и законы в области приватности и персональных данных требуют Secure by Design системы. Но как можно сделать это самое Secure, если Design делается другим подразделением на самых модных и не всегда проверенных технологиях?

Изначальная ИТ-безопасность если не умерла, то уже начинает трансформацию. Вернее, возвращение к истокам с качественными изменениями. В 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 и встраиваться в процесс обычного тестирования. Конечно, это не будет панацеей от всех бед, и если ваш основной бизнес связан с работой приложений или сайта, то полностью полагаться на подобный процесс не стоит. Но эксперт по безопасности приложений может находиться и среди разработки.

Postmortem

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

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

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

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

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

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