На грани между ИТ и ИБ: противоборство или союз специалистов?

В среде разработчиков бытует мнение, что информационная безопасность относится к IT не напрямую, а косвенно, что это вспомогательная область и даже вторичная. Но так ли это на самом деле? На этот неоднозначный вопрос серьезно и обстоятельно ответили спикер Слёрма Роман Панин и его коллега Павел Шатилов, руководители направления архитектуры ИБ в МТС. Вот о чём они рассказали:

• о безопасной разработке, по-другому — SSDLS;

• DevOps и DevSecOps;

• противостоянии подразделений ИТ и ИБ;

• смежных специальностях в ИТ и ИБ;

• вузовских программах по направлению «Информационная безопасность».

Безопасная разработка, или SSDLC

Жизненный цикл разработки практически любого программного обеспечения можно разложить на вполне конкретные этапы или фазы.

Более того, человечество уже сформулировало такой подход в виде фреймворка, стандартизировало его и дало имя SDLC — Systems Development Life Cycle.

Методология SDLC упрощает жизнь как разработке, так и бизнесу: она позволяет правильно закладывать ресурсы и сокращать время вывода продукта на рынок. Фреймворк — 

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

Существует множество трактовок этапов SDLC, но большинство сходятся на примерно такой последовательности:

• Планирование: формулирование вида целевого продукта;

• Анализ: формулирование ТЗ и спецификаций;

• Проектирование: создание дизайна и архитектуры продукта/системы;

• Разработка: реализация требований из ТЗ;

• Тестирование и развертывание: проверка корректности выполнения всех требований и вывод продукта в эксплуатацию;

• Поддержка и сопровождение: эксплуатация в продакшене и обеспечение надежности

Кажется, что всё учтено и риск ошибиться или потерять деньги при разработке ПО стремится к нулю. К сожалению, это не так.

Дело в том, что и разработчики, и архитекторы, и DevOps-инженеры, и тестировщики тоже люди, которым свойственно ошибаться, из-за чего и появляются уязвимости в безопасности и лазейки для злоумышленников.

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

Пример №1

Разработчик пишет backend-сервис одного продукта, и для реализации определённой функциональности ему нужно воспользоваться методами популярной библиотеки. Он смело качает её с GitHub-а, заливает в свой проект и деплоит его в продакшен. Методы подтянулись как надо, библиотека подходит, сервис работает и отвечает техзаданию. Кажется, что всё отлично, но есть один нюанс. 

Библиотека, будь она хоть самой популярной и распространённой, может быть заражена как эксплойтом, так и закладкой с лозунгами, а это может привести к финансовым и репутационным издержкам. Это не обязательно должна быть библиотека, это может быть любой компонент, скачиваемый напрямую из общедоступной сети. Подобные артефакты необходимо подвергать различным видам сканирования и анализа, с чем и помогают команде разработки их коллеги из Application Security.

Пример №2

 На очереди у нас ИТ-архитекторы, которые не пишут код, да и компоненты из интернета не скачивают. Где же они могут оступиться? Хороший ИТ-архитектор может умело спроектировать дизайн целой системы или платформы. Проблема состоит в том, что нужно не только корректно спроектировать архитектуру системы и её функциональных компонентов, но и безопасно расположить в рамках существующей инфраструктуры организации. У нас могут обрабатываться карточные данные или информация, содержащая тайну связи. Обрабатывающие их сервисы и ресурсы должны быть размещены в отдельном сегменте сети за межсетевым экраном, а доступ к ним — максимально ограничен. В ином случае злоумышленник имеет все шансы добраться до чувствительных данных и слить их. 

Для того чтобы этого не произошло, архитектор ИБ должен следить за тем, чтобы проектирование систем было корректным и с точки зрения безопасности. Помимо размещения ресурсов в релевантных сегментах сети, он также контролирует и другие средства защиты информации, к ним относятся системы обнаружения и предотвращения вторжений. Они необходимы для того, чтобы остановить злоумышленника даже после того, как он преодолел контур безопасности.

Пример №3

 Ну и завершим примером будет случай из DevOps-практик. Может случиться ситуация, при которой некоторые БД системы не обновляются просто потому, что новые патчи никак не влияют на скорость работы баз и оптимизацию ресурсов. DevOps-инженер может отложить этот апдейт до лучших времен, так как задач на продакшене всегда хватает, а бэклог умеет только расти, а не уменьшаться. По сути, из-за отсроченного обновления БД, ничего критичного произойти не должно. Но может быть и такое, что в новых обновлениях ресурсов системы есть критичные обновления безопасности, закрывающие свежие уязвимости из базы CVE. DevOps-инженер может не уделить этому должного внимания, а злоумышленник может с лёгкостью использовать непропатченную уязвимость. 

Secure SDLC

Мы подходим к симбиозу работы сотрудников ИТ и ИБ, и фреймворку, который описывает их слаженную работу по созданию функционального и безопасного ПО — Secure SDLC. Это то же описание жизненного цикла разработки программного обеспечения, но обёрнутое в безопасные практики. На основе этого фреймворка к стандартным этапам SDLC добавляются процессы, связанные с информационной безопасностью. На стадии планирования производится оценка угроз кибербезопасности и анализ рисков, а на этапе проектирования формулируются не только функциональные требования к продукту, но и нефункциональные требования по ИБ, а также разрабатывается полноценная модель угроз. В пайплайны разработки встраиваются сканеры кода и сторонних библиотек. Далее, во время тестирования со стороны QA, также проводится и тестирование со стороны сотрудников кибербезопасности. Ну а на этапе эксплуатации ПО начинают действовать политики реагирования на инциденты безопасности, которые выявляются благодаря настроенному мониторингу со стороны SIEM и SOC.

Только слаженная работа команд разработки, сопровождения и информационной безопасности позволяет вывести на рынок продукт, который приносит только пользу и не представляет угрозы для целевого клиента.

DevOps и DevSecOps

 DevOps-инженеры занимаются автоматизацией различных процессов, которые помогают разработчикам, тестировщикам и сотрудникам сопровождения. Инженеры выстраивают удобные пайплайны CI/CD-конвейера: это ускоряет доставку продукта до клиента. В какой-то момент времени рынок и продуктовые компании осознали, что необходимо не только сокращать time-to-market, но и делать ПО надёжным и безопасным. Именно в этот момент и начала зарождаться роль DevSecOps.

Благодаря этим инженерам в современные пайплайны встраиваются различные сканеры безопасности: SAST, DAST, IAST и RASP. Настройка сканеров возлагается либо на самих инженеров, либо на коллег из информационной безопасности, ответственных за сопровождение средств защиты информации и AppSec. Они же отвечают за правильный Patch Management, основанный не только на потребностях бизнеса, но и на управлении актуальными уязвимостями в ПО.

Безопасность также касается и развёртывания ИТ-инфраструктуры, в которой будут жить разработанные сервисы. В текущих реалиях все уже практически переехали на микросервисную архитектуру под управлением оркестраторов, таких как OpenShift или Kubernetes. Эти технологии помогают оптимально распределять вычислительные ресурсы и обеспечивать надёжность систем, но они также требуют внимания со стороны ИБ. Здесь работают правила сетевого сегментирования, встраивания СЗИ, их грамотной настройки и сопровождения. Более того, многие компании переносят свою инфраструктуру в облака, где точно так же нужно следить за безопасными практиками. 

DevSecOps совмещает в себе сразу два крупных домена — ИТ и ИБ, совместно участвующих в доставке до потребителя итогового цифрового продукта.

ИТ и ИБ – противостояние века?

Спор ИТ и ИБ-специалистов – старая песня. Попробуем разобраться, есть ли решение данного конфликта и почему «так исторически сложилось». 

Зачастую ИТ-специалисты на этапах проектирования или развертывания инфраструктуры сталкиваются с некоторыми задачами, решить которые можно только с помощью «безопасников». Получить доступы, создать учетную запись, выделить ресурсы или разместить их в том или ином сетевом сегменте - за этим могут прийти разработчики в отдел ИБ. Но чтобы получить «желаемое», айтишникам нужно подготовить минимально необходимые артефакты, и тут начинается самое интересное. «Опять ждать согласования», «Мы ничего не успеем, нужно готовить артефакты», «В конце года развернемся», — говорили коллеги из ИТ. А иногда можно даже и вовсе услышать брошенные в сердцах утверждения: «Все, проект закроется не начавшись». 

С одной стороны, их можно понять. Ведь задача стоит – обеспечить работоспособность бизнеса, причем надо было все сделать ещё «вчера». С другой стороны, «безопасники» являются хорошим предлогом, чтобы оправдать срывы сроков проекта, если вспомнили про них на финишной прямой. 

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

ИБ и место отдела в иерархии предприятия: четыре варианта

Молодой отдел ИБ в организации рождается внутри IT-подразделения. Это могут быть специалисты ИТ, ответственные за обеспечение безопасности, либо отдельная служба ИБ в составе ИТ. При такой иерархии требования ИБ отходят на второй план, и в лучшем случае к безопасникам будут приходить за советом, а главенствующая роль будет за ИТ.

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

Классический вариант – отдельное подразделение ИБ уровня подразделения ИТ. При таком подходе обе структуры имеют одинаковый вес, а поиск компромисса лишь вопрос уровня, на котором его найдут.

В заключение, вариант, которые набирает все большую распространенность – использование аутсорса или создание/перевод части подразделений ИБ в дочерние компании. В таком случае, при взаимодействии ИТ и ИБ появляется третья независимая сторона, которая предотвращает конфликты интересов ИТ и ИБ. 

На стыке задач специалистов и интересов бизнеса появляются специальности, которых можно в одно и то же время отнести и к информационной безопасности, и к разработке. В организациях специалист на одной и той же должности может выполнять несколько отличающиеся задачи: подробнее о них расскажет HR во время собеседования. 

Рассмотрим наиболее актуальные специализации в области информационной безопасности в смежных сферах ИТ и их самые основные функциональные обязанности.

 Смежные специальности в ИБ и ИТ 

• Архитектор по информационной безопасности. Специалист разрабатывает безопасную архитектуру, проектирует системы защиты, координирует команды разработки по вопросам ИБ и взаимодействует с другими «безопасниками» по вопросам интеграции со средствами защиты. Эта роль родилась из всем известного ИТ-архитектора, на плечи которого возлагается ответственность за проектирование надежных систем и сервисов. Архитектор ИТ заинтересован в том, чтобы оптимально распределять вычислительные ресурсы, правильно интегрироваться с мастер-системами и создавать отказоустойчивые сервисы. У архитектора ИБ схожие цели, но он также думает и о том, чтобы вся эта история была безопасной.

• Баг-хантер или этичный/белый хакер. Практически все крупные компании и корпорации уже запустили свои программы Bug Bounty. Компания предоставляет вознаграждение человеку, который смог найти брешь в безопасности одной из систем этой компании. Такие программы породили появление новой профессии – баг-хантер. Чаще всего их не нанимают в штат, это становится уже не так выгодно. Зато в штат компании нанимают их коллег – этичных/белых хакеров и пентестеров. Эти специалисты также проводят тестирование на безопасность систем для выявления проблем, багов и критических уязвимостей. Само собой, их коллегами по цеху являются инженеры, ответственные за контроль качества продукта – QA. QA-инженеры также проводят тестирование, но уже с упором на надежность и соответствие функциональным требованиям.

• DevSecOps. Этот специалист отвечает за процессы безопасной разработки (SSDLC), применяет соответствующие инструменты, встраивает их в автоматизированные пайплайны CI/CD-конвейера и взаимодействует с командами разработки по вопросам обеспечения ИБ как на этапе разработки, так и на этапе эксплуатации ПО. Его «братом-близнецом» из ИТ является DevOps-инженер, который и выстраивает те самые автоматизированные пайплайны CI/CD. DevOps необходим командам разработки и эксплуатации уже на самых начальных этапах зрелости компании, в то время, как DevSecOps-инженер помогает выстраивать и автоматизировать безопасность уже на более поздних стадиях развития процессов ИТ и ИБ.

• Администратор информационной безопасности. Он занимается контролем и мониторингом ИБ в различных информационных системах и обработкой событий и инцидентов информационной безопасности. Его коллега – администратор ИС, который отвечает за администрирование самой системы, управление ролевой моделью и правами доступа, созданием новых и блокировкой неактуальных пользователей.

• Администратор средств защиты информации (СЗИ). Он устанавливает, настраивает и сопровождает системы ИБ: DLP, IPS/IDS, WAF, FW, антивирусное ПО и прочих. По сути, это тот же системный администратор, но в рамках ПО и железа, связанного именно с безопасностью.

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

• Аудитор ИБ. Список его обязанностей похож на то, чем занимается его коллега – пентестер, но Аудитор ИБ использует не такие активные методы и отталкивается, в первую очередь, от соответствия требований регуляторов, лучших практик, стандартов и сертификаций, таких как PCI DSS, GDPR, ISO/IEC 27000. Также отличие заключается в том, что у Аудитора ИБ есть полный доступ ко всей инфраструктуре, системам и сервисам. Его отражением со стороны IT является Аудитор ИТ, который проводит проверки в соответствии с такими методологиями и практиками как COBIT и ITIL.

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

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

Думай о безопасности со школы: в каких вузах учат ИБ?

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

Образование в сфере информационной безопасности предлагают множество престижных вузов России. Мы решили провести анализ и разобраться к каким факультетам относятся специальности по кибербезопасности и защите информации, какие коды специальностей они имеют и относятся ли они к IT-шным специальностям. Мы опираемся на рейтинг лучших вузов агентства RAEX, рассматриваем бакалавриат, магистратуру и специалитет. 

Московский государственный университет имени М. В. Ломоносова предлагает обучение в бакалавриате по образовательной программе «Математические методы обработки информации и принятия решений» интегрированной подготовки бакалавра по направлению 01.03.02 «Прикладная математика и информатика». После окончания 2 курса студенты должны выбрать между направлениями «Математические методы защиты информации и криптологии» либо «Кибербезопасность и искусственный интеллект». В магистратуре предлагается обучение по программе «Информационная безопасность компьютерных систем», которая также относится к специальности 01.03.02 «Прикладная математика и информатика». Кафедра информационной безопасности находится в составе Факультета вычислительной математики и кибернетики (ВМК).

В Московском физико-технический институте есть специалитет 10.05.01 «Компьютерная безопасность». Направлению «Компьютерная безопасность» обучают на кафедре защиты информации на базе факультета радиотехники и кибернетики.

Бакалаврскую программу 10.03.01 «Информационная безопасность» предлагает Высшая школа экономики. Кроме того, здесь можно пройти обучение по программе специалитета 10.05.01 «Компьютерная безопасность», включающего профиль подготовки «Математические методы защиты информации». Программы бакалавриата и специалитета находятся в составе Департамента электронной инженерии Московского института электроники и математики им. А.Н. Тихонова. Помимо этого, в ВШЭ есть две магистерские программы на базе специальности 10.04.01 - «Информационная безопасность киберфизических систем» и «Кибербезопасность», причем, на второй программе есть опция онлайн-формы обучения.

В МГТУ им. Н.Э. Баумана есть две отдельные кафедры на факультете «Информатика, искусственный интеллект и системы управления»: «Информационная безопасность» (ИУ8) и «Защита информации» (ИУ10), а также есть кафедра «Безопасность в цифровом мире» на «Юридическом факультете» (ЮР).  На базе ИУ8 включены программы специалитета 10.05.01 «Компьютерная безопасность», 10.05.03 «Информационная безопасность автоматизированных систем». Последняя включает три специализации 10.05.03_01 «Анализ безопасности информационных систем», 10.05.03_02 «Защищенные автоматизированные системы управления», 10.05.03_03 «Создание автоматизированных систем в защищенном исполнении». ИУ10 также обучает по программе специалитета 10.05.03 «Информационная безопасность автоматизированных систем» по специализации «Безопасность автоматизированных систем в кредитно-финансовой сфере». Юридический факультет предлагает обучение по специальности 10.05.05 «Безопасность информационных технологий в правоохранительной сфере». Также, на ИУ8 есть магистерская программа 10.04.01 «Информационная безопасность».

Богатый выбор направлений по информационной безопасности предлагает Санкт-Петербургский политехнический университет Петра Великого. Все направления по ИБ находятся в отдельном Институте кибербезопасности и защиты информации в составе университета. Появился он, кстати говоря, относительно недавно – в 2020 году. В бакалавриате есть направление 10.03.01«Информационная безопасность» с двумя специализациями «Безопасность компьютерных систем» и «Безопасность компьютерных систем (Интеллектуальная защита от киберугроз)». Магистратура включает направление 10.04.01 «Информационная безопасность» также с двумя специализациями «Искусственный интеллект в кибербезопасности» и «Кибербезопасность нефтегазовой отрасли. Также есть три направления в специалитете: 10.05.03 «Информационная безопасность автоматизированных систем», специализация «Анализ безопасности информационных систем», 10.05.04 «Информационно-аналитические системы безопасности», специализация «Автоматизация информационно-аналитической деятельности», и 10.05.01«Компьютерная безопасность» специализация «Математические методы защиты информации».

В РАНХиГС нет классического направления по информационной безопасности, зато есть направление подготовки бакалавриата 09.03.03 «Прикладная информатика» со специализацией «Прикладная информатика в информационной безопасности» в Институте экономики, математики и информационных технологий.

В заключение

Можно ли сказать, что информационная безопасность всегда является неотъемлемой частью разработки? Однозначно отвечать не будем, ведь каждый вправе придерживаться своей позиции по этому вопросу. В чем мы уверены, так это в том, что нельзя проводить между этими сторонами производства ПО однозначный знак неравенства: где-то направления пересекаются, а где-то полностью взаимосвязаны — как в направлениях обучения вузов, так и профессиональном сообществе.