На одном языке. Как наладить контакт команды ИБ и программистов

На одном языке. Как наладить контакт команды ИБ и программистов

Социальная инженерия и использование человеческого фактора в кибератаках стали основным трендом последних лет. Нападения становятся всё более сложными и задействуют все слабости корпоративных информационных систем — как психологические уязвимости людей, так и уязвимости в программах.

Люди выполняют начальное действие, например открывают документ и разрешают выполнение макросов. А дальше вредоносный код использует другую разновидность уязвимостей — ошибки в программах. С их помощью на компьютере жертвы запускается «полезная нагрузка», например троян или бэкдор, шифровальщик-вымогатель или шпионский модуль…

Работу над устранением уязвимостей в программах нужно начинать не в момент, когда ими воспользовались преступники, а значительно раньше — на стадии создания приложения и даже ещё раньше, во время проектирования и формирования требований к безопасности программы (Илл. 1). О том, как повысить эффективность формирования требований к безопасности разработки, поговорим в этой статье.

Иллюстрация 1. Относительная стоимость устранения дефектов ПО на разных стадиях разработки

ВЫЯВЛЯЕМ НЕЭФФЕКТИВНЫЕ ПРАКТИКИ

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

С первого взгляда кажется, что для разработки безопасной программы нужно не так много усилий:

• взять требования к безопасности разработки ПО, например, из ГОСТ Р 56939—2016. Защита информации. Разработка безопасного программного обеспечения. Общие требования;
• добавить отраслевые практики, например PCI DSS и/или OWASP;
• вписать всё это в таблицу Excel или Google Sheets;
• передать её программистам, которые воплотят требования и рекомендации в коде;
• проконтролировать результат на приёмо-сдаточных испытаниях.

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

Большинство разработчиков ожидают, что:

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

Единственное препятствие на этом блестящем пути — приёмо-сдаточные испытания, в ходе которых неожиданно выясняется, что результат не соответствует требованиям. Основная причина в том, что разработчики не знают ответов на фундаментальные вопросы:

• Какие угрозы актуальны?
• В чём реальные риски?
• Что такое безопасный код и как его писать?
• Какие могут быть проблемы с окружением?

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

В результате вместо ввода программы в эксплуатацию приходится повторно уточнять требования к безопасности и заново проходить все стадии разработки и тестирования. Это приводит к срыву сроков и значительному удорожанию проекта.

Но и со стороны ИБ-подразделений тоже наблюдаются проблемы, поскольку их сотрудники:

• даже зная наизусть ГОСТ Р 56939—2016, Приказ ФСТЭК № 17, Положение ЦБ РФ № 719-П, не могут сформулировать их в виде понятных разработчикам требований;
• не могут качественно сопоставить требования отечественных нормативных документов с аналогичными требованиями международных стандартов;
• не имеют представления о том, как требования к безопасности соотносятся с технологическим стеком, который использует команда разработки, а в ряде случаев не знают даже, какие фреймворки и языки программирования задействованы в проекте;
• не готовы проводить верификацию программы в части реализации сформулированных требований по безопасности просто потому, что не знают, как это сделать.

ФОРМУЛИРУЕМ ИДЕАЛЬНЫЕ ТРЕБОВАНИЯ ПО ИБ К ПО

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

Корректные требования по ИБ к ПО формируются командами разработки самостоятельно и автоматически.

Чтобы добиться этого результата, необходимо организовать процесс таким образом, чтобы учитывать все уровни требований по информационной безопасности и обеспечить «перевод» требований с формального языка на язык соответствующей целевой группы (Илл. 2).

Иллюстрация 2. Уровни требований по информационной безопасности

Этот процесс состоит из следующих этапов:

1. Анализ законодательства и требований регуляторов с фокусом на комплаенс и организацию процессов ИБ.
2. «Перевод» требований на язык ИБ-экспертов и системных администраторов.
3. Анализ внутренних требований организации, лучших отраслевых практик и стандартов с фокусом на оценку рисков. На этом этапе целесообразно выполнить сопоставление (маппинг) аналогичных требований из различных документов с тем, чтобы избежать дублирования одинаковых требований, сформулированных по-разному, например: OWASP (ошибки подсистемы аутентификации должны обрабатываться безопасно и не позволяют атакующему войти в АС) и Стандарт Банка России (должны быть определены, выполняться, регистрироваться и контролироваться правила и процедуры — идентификации, аутентификации, авторизации субъектов доступа, в том числе внешних субъектов доступа, которые не являются работниками организации БС РФ, и программных процессов (сервисов).
4. «Перевод» расширенной и очищенной от дублирования подборки требований на понятный разработчикам язык.
5. Дополнение и уточнение требований с учётом используемых языков программирования, платформ и фреймворков.
6. Выгрузить окончательный перечень требований в виде удобного для использования документа.

СОЕДИНЯЕМ ОЖИДАНИЯ ИБ И РАЗРАБОТЧИКОВ

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

В функции такой платформы должны входить:

• возможность создавать и наполнять базу требований;
• все требования стандартов, руководств и лучших практик;
• автоматическое обновление требований при любом изменении конфигурации ПО, стандартов и нормативных документов, причём изменения сразу должны быть видны у инженерных команд;
• автоматическое сопоставление требований из разных стандартов и от разных регуляторов в единые референсные требования без противоречий и дублирования;
• конкретные примеры и практики реализации требований для разработчиков;

Такая платформа позволила бы командам ИБ и разработки:

• поддерживать актуальность знаний о приёмах безопасной разработки;
• изменять требования при изменениях в стеке технологий;
• отслеживать обновления стандартов;
• своевременно получать информацию о новых уязвимостях;
• быть в курсе публичных инцидентов;
• получать обратную связь от процессов тестирования требований: пентест, ПСИ, SAST/DAST.

РЕАЛИЗАЦИЯ ОЖИДАНИЙ 

Результатом тесного сотрудничества ИБ-команды и разработчиков Антифишинга стал новый продукт – система Антифишинг.START, в котором были реализованы ожидания и пожелания всех участников процесса создания ПО (Илл. 3).

Иллюстрация 3. Интерфейс системы: заполнение анкеты для формирования требований к новому приложению

Главные функции системы:

• работа начинается с составления анкеты, на основании которой формируются  требования по защите информации;
• содержит предустановленные базы требований нормативных документов, регуляторов и стандартов: OWASP, 382-П и 719-П, PCI DSS;
• умеет сопоставлять требования в базе знаний с требованиями из государственных нормативных актов и стандартов, показывает, каким законом или стандартом предъявляется данное требование;
• автоматически обновляет требования по информационной безопасности при изменении архитектуры или бизнес-требований к системе;
• каждое требование привязано к одному из этапов DevSecOps;
• позволяет добавлять уникальные требования для каждой разрабатываемой системы;
• контроль выполнения требований с помощью наглядных статусов;
• интеграция с LDAP, JIRA, GRC и другими системами и средствами защиты.

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

Благодаря Антифишинг.START не только экономится время, но и существенно повышается качество результата:

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