По каждому из направлений в ИТ есть свои так называемые «приколы» и особенности в части поиска и обучения сотрудников, взаимодействия с софтом, заказчиками и так далее. В моей области, то есть в области информационной безопасности, все еще обсуждают такой вопрос: «Должен ли безопасник расти из программиста?». Имея 25+ лет в области ИТ и ИБ ответственно заявляю — должен. Для меня это не вопрос, но многие со мной не согласятся. Сегодня раскрою свою позицию и объясню, почему безопасникам жизненно необходимо быть программистами.
Небольшое уточнение — для удобства я называю программистами всех, кто пишет код, манифесты, какие‑нибудь конфиги и так далее.
Какие типы безопасников сейчас есть
На рынке существует несколько видов безопасников, которые специализируются в различных областях информационной безопасности. Я выделяю два основных типа:
Классический безопасник — это специалист, который занимается обеспечением безопасности информационных систем и сетей, защитой от хакерских атак и других угроз. Он может заниматься аудитом безопасности, реагированием на инциденты, разработкой политик безопасности и т. д.
Безопасник из программиста — это специалист, который имеет навыки программирования и разработки, но также обладает знаниями в области информационной безопасности. Он может заниматься разработкой безопасного программного обеспечения, тестированием на проникновение, обучением разработчиков правилам безопасного кодирования и т. д.
В общем, безопасники могут быть различного профиля и специализации, в зависимости от конкретных задач и потребностей организации.
ЦОД и база
Разберем тему на базовом примере с ЦОД. ИТ — это достаточно сложная инфраструктура, которая начинается с дата‑центров и телекоммуникационных каналов, объединяющих эти дата‑центры с каналами связи, маршрутизаторами, коммутаторами. Они создают инфраструктуру для серверов и облаков. Над этим всем стоят люди, занимающиеся разработкой, поддержкой и работой с оборудованием и софтом. Над этими людьми, собственно, есть еще одна надстройка — безопасники.
Работа безопасника может начинаться с банального пропуска сотрудников, работников или клиентов в ЦОДы. Все оборудование, железо, которое там размещается, тоже необходимо защищать. И тут, пожалуй, стоит смотреть на ИБ в двух направлениях: разработка и инфраструктура.
В направлении инфраструктуры безопасник должен защищать каналы связи, всю инфраструктуру ЦОД и всё, что к ней подвязано, проводить анализ систем на уязвимости и возможность проведения атак, например, тех же DDoS‑атак. В этой области есть неплохие системы мониторинга, позволяющие все это отслеживать и уведомлять специалистов о тех или иных проблемах с безопасностью. В них учитывается работа коммутаторов, серверов, маршрутизаторов и даже систем кондиционирования и бесперебойного питания — если их вывести из строя, можно остановить работу всего ЦОД.
Соответственно всё, что касается инфраструктуры, активно мониторится. Можно написать большое количество обвязки в системе мониторинга, которая будет собирать температуру с определенных датчиков, напряжение и частоту с источников бесперебойного питания и все это отображать в красивых графиках. По определенным триггерам в этих метриках будут срабатывать соответствующие оповещения. Это все работает в настоящих современных ЦОД. То же самое касается каналов связи, DDoS‑атак и так далее. Это все уже хорошо организовано и применяется.
Оркестрация, SRE и DevOps
Также у нас есть слой инфраструктуры, который относится к виртуализации (VMware, Hyper‑V, KVM, Proxmx и т. п.) или к оркестрации (Kubernetes, Docker Swarm, OpenShift, Hashicorp Nomad). Все гипервизоры должны быть сегментированы и изолированы и должны иметь определенные политики доступа к гипервизорам и другим инфраструктурным компонентам. Здесь тоже все достаточно просто и проблем не возникает. А вот оркестрация уже непосредственно касается работы SRE и DevOps. То есть здесь могут появляться более существенные вопросы, связанные с ИБ. Безопасники, связанные с оркестрацией и виртуализацией, отвечают непосредственно за процессы, завязанные на бизнес‑логику организации. Здесь запускается большое количество инфраструктурных контейнеров, контейнеров приложения с бизнес‑логикой, которые сами по себе могут нести большое количество уязвимостей. Человеку, который этим никогда жил, разобраться во всем скорее невозможно, чем возможно.
В данном случае безопасник должен быть из классических админов в первую очередь. Желательно, чтобы он был из DevOps, в идеале — чтобы еще и SRE. Эти люди реально понимают, как работает инфраструктура, кластеры и оркестрация, какие процессы там происходят и как этим управлять. И они знают основные точки входа, по которым можно атаковать. Специалист должен представлять, с чем он работает и с чем он должен взаимодействовать.
Если говорить про классические сканеры уязвимости на этом слое, то это сканеры, которые относятся к Kubernetes: KubeBench, KubeHunter, Trivy‑operator, Falco, Aqua, а также отечественные продукты типа Positive Technologies Container Security, Касперский Container Security. В эти системы безопасности не просто нужно изучать, их нужно устанавливать, обслуживать, обновлять и работать с ними. И эта работа тоже отчасти SRE, потому что нужно взаимодействовать с компонентами кластеров Kubernetes. Классический безопасник, который с этим никогда не сталкивался, скорее всего, не сможет выполнять эту работу, потому что у него не будет соответствующей компетенции этой области.
Сборка и доставка
Переходим к сборке и доставке. Этим тоже занимаются SRE и в нашем случае все flow в конвеере CI/CD. Сама система управления репозиториями кода также может быть подвержена атакам, поэтому нужно понимать, как работает весь конвейер сборки и доставки, какие есть слабые места и уязвимости в этих системах. Если ты никогда с этим не сталкивался и не умеешь проектировать и писать flow для процессов сборки и доставки, то ты, скорее всего, не сможешь понять, каким образом его проверять на уязвимости. Каких‑то специальных сканеров, которые бы позволили это сделать, в настоящее время нет. Нужно смотреть на бизнес‑логику процессов, то есть разбирать по шагам все джобы и понимать, что они делают. Это уже вопрос на стыке программирования и инфраструктуры.
Еще один момент, на который нужно обратить внимание — это контейнеризация и контейнерная безопасность. Специалист ясно и четко должен представлять, что такое контейнеры, из каких слоев они состоят, что на каждом слое находится и что может быть в них уязвимо, с какими правами они запускаются, под какими пользователями и самое важное — как исправить неисправность. Без навыков работы с контейнерами устранять и разбирать уязвимости в них не получится. Часто в них находится операционная система, базовый слой, в каких‑то слоях могут заноситься как артефакты, относящиеся к операционной системе, так и артефакты, связанные с бизнес‑логикой — непосредственно сам код. Нюансы работы с исходным кодом, который выполняется в контейнере, очень важны, и не знающий код безопасник не сможет качественно провести триаж уязвимостей.
Разработка и тестирование
Разберем самую верхнеуровневую историю — разработка и тестирование. Я считаю, что программирование является основой для понимания и анализа вообще всех уязвимостей в любой информационной системе. Простой пример из раздела с инфраструктурой. Современные маршрутизаторы и коммутаторы содержат определенное количество кода, который пишут инженеры сетевой инфраструктуры. Этот код надо понимать и уметь читать. В области виртуализации есть большое количество конфигурационных файлов, которые настраивают так, чтобы поддерживать определенную инфраструктуру в части сети и виртуальных машин, запущенных в ней. На уровне SRE есть огромное количество YAML‑манифестов, которые применяются в среде, в оркестрации, допустим в Kubernetes. Их тоже нужно уметь писать и с ними работать. Если мы берем Docker файлы и контейнеры Docker, то там большое количество конфигурационных файлов Dockerfile, из которых контейнеры собираются. И только те, кто сам пишет код, будут понимать, как работают данные конфигурации и каким образом реализуются эти алгоритмы и структуры данных.
Знание кода помогает более глубоко понимать уязвимости в программном обеспечении и искать пути их устранения. Программисты видят моменты, связанные с точками входа и процессами обработки и анализа каких‑то состояний. Вернемся к маршрутизаторам. Есть какой‑то конфиг для этого маршрутизатора, и в нём — открытые порты. Инженер или сетевой инженер видит, что открыто и куда можно проводить атаки. В SRE то же самое. Там есть сервисы, которые открывают доступ к определенному микросервису и на которые можно проводить атаки.
Еще одно важнейшее преимущество безопасника‑программиста — способность к комплексному подходу к задаче обеспечения безопасности. Безопасник должен закрывать какую‑то определенную зону ответственности. Как это сделано у нас: AppSec‑специалисты занимаются разбором кода и бизнес‑логики, которые пишут программисты. DevSecOps занимаются контейнерной безопасностью и безопасностью Kubernetes, то есть они детально разбирают это направление. Есть мобильные безопасники Application Security, которые занимаются поиском уязвимостей в мобильных приложениях.
Программисты приучены к анализу кода на микроуровне и к тщательной проверке каждой строки кода на ошибки и уязвимости. Это все подсвечивается сканерами. Но нужно понимать, что сканеры не позволяют определять процессы, связанные с бизнес‑логикой. Если есть цепочка атак, которая приведет к выполнению каких‑то плохих состояний для этой информационной системы, сканер может это не увидеть. А вот безопасник‑программист сможет определить изменения и подозрительные моменты, которые не увидят другие специалисты.
Обучение безопасника‑программиста
Следующий момент, про который нужно сказать — это непрерывное обучение и развитие специалиста безопасника. ИБ быстро меняется, особенно в последнее время: выходят новые стандарты и политики, появляются новые базы уязвимостей, которые нужно обновлять, постоянно поддерживать, совершенствовать. Кроме того, необходимо совершенствовать свои навыки и знания в области информационной безопасности. Этому способствуют разные курсы, семинары, конференции, как онлайн, так и оффлайн. И мы за этим тоже следим и стараемся все время быть в тренде этих процессов.
Программисты благодаря как раз своему большому опыту и умению быстро учиться новому могут легче адаптироваться к этим изменениям и быть в курсе последних событий и трендов в области информационной безопасности. Хорошо, кстати, если программисты в целом работают с безопасниками. Специалист по ИБ видит результаты сканирования, проверяет код и приходит с этими уязвимостями к разработчику. Разработчик на основе этих данных начинает обучаться информационной безопасности. То есть в следующий раз он таких ошибок допускать уже не будет, и его уровень и компетенция будут постоянно расти.
Курсы по ИБ по типу «Войти в ИТ за 20 минут» тоже не панацея в данном вопросе. Как правило, их проходить должен уже разбирающийся в коде специалист, решивший перепрофилироваться на другие задачи или просто повысить качество кода, который пишет. Нередко те или иные вещи при написании кода могут быть неочевидны, и подобные курсы как раз помогут обезопасить результаты труда себе и всем связанным с проектом коллегам. Взять человека с нуля и обучить его работать со сканером недостаточно, чтобы получить хорошего ИБ‑специалиста.
Подведем итог
Безопасник, который вырос из программиста, будет обладать рядом неоспоримых преимуществ, которые делают его более эффективным и компетентным в области информационной безопасности. Программист, имеющий глубокие знания и навыки и обладающий комплексным подходом, вниманием к деталям и желанием постоянно обучаться будет незаменим в создании надежных и безопасных информационных систем. Еще лучше, если безопасник имеет опыт сисадминства, SRE и DevOps.
Без знания кода и нюансов его написания специалист по ИБ в лучшем случае сможет только грамотно интерпретировать результаты работы сканеров. Джунов в области ИБ можно обучать на триаже дефектов от сканеров, разборах каких‑то уже решенных кейсов, отправлять их на курсы и всесторонне обучать для достижения ими нужного уровня компетенции.
Готов обсудить с вами тему. :-)