Большинство успешных атак на организацию осуществляются через уязвимости и ошибки в программном обеспечении.
К счастью, сканер уязвимостей программного обеспечения уже рассматривается компаниями не как нечто экзотическое, а как необходимый элемент инфраструктуры безопасности.
Если для небольших объемов разработки можно использовать сканер «как есть», то при больших объемах приходится автоматизировать процесс.
Но кто должен этим управлять? Решаете, как часто проверять релизы? Вам нужно проверить уязвимости? Решите, стоит ли наложить вето на релиз и отправить код для исправления уязвимостей? И ответить на многие другие вопросы.
Именно здесь в игру вступает Application Security Manager, менеджер по безопасной разработке программного обеспечения.
Но где найти такую редкую птицу или как ее вырастить самостоятельно? Артем Бычков, менеджер по безопасности приложений АО «Райффайзенбанк», и Даниил Чернов, руководитель направления Solar appScreener компании «Ростелеком-Солар», рассказывают, какие требования к Application Security Manager диктует практика разработки в российских компаниях.
Кто такой менеджер безопасности приложений
Организации рано или поздно приходят к осознанию необходимости нанять такого человека в команду.В частности, потому, что ни один из имеющихся в компании специалистов непосредственно на эту роль не подходит. Разработчики? Их опыт работы связан именно с разработкой программного обеспечения — перевести найденные уязвимости в риски информационной безопасности, а тем более бизнес-риски, для них очень сложно.
Охранники? Для них погружение в тонкости разработки проблематично: для проверки уязвимостей им необходимо умение понимать программные коды на разных языках, что требует серьезного опыта разработки.
Давайте рассмотрим, какие задачи возникают при реализации безопасного процесса разработки, которые должен решить Менеджер безопасности приложений (ASM).
У читателя может сложиться впечатление, что работа ACM связана исключительно с тестированием программных разработок на соответствие требованиям безопасности.
Но проблемы безопасности возникают на разных этапах жизненного цикла системы: от проектирования до промышленного внедрения.
Существуют разные модели построения безопасного цикла разработки (Software Security Touchpoints, SDLC и другие) и разные методы интеграции этих практик в процесс (в зависимости от используемого подхода — водопадный, гибкий).
Но все они согласны в ключевых моментах: о безопасности необходимо думать на всех этапах жизненного цикла системы.
Очевидно, что в рамках более-менее крупного проекта один человек вряд ли сможет выполнить работу на всех этапах.
Редко кто в одиночку способен разработать требования безопасности приложения, просмотреть его архитектуру и проверить результаты работы аналитиков, провести аудит безопасности кода, убедиться, что в ходе тестирования были проведены необходимые тесты безопасности приложения и что система была безопасно развернута и правильно настроена.
Причем эту деятельность часто проводят представители разных команд и отделов.
Чтобы весь механизм работал как надо, движущей силой процесса должна быть АФМ.
Задача ACM — обеспечить внедрение практик безопасной разработки либо самостоятельно, либо путем делегирования отдельных задач профильным специалистам.
Однако, как показывает наша практика, АСМ не сможет просто раздавать задания ответственным и почивать на лаврах.
Какие требования к AFM?
Во-первых, он должен понимать проект, который он поддерживает. Это особенно важно при гибкой разработке, когда, в отличие от водопадной модели, у вас нет 2 месяцев на проведение ревью перед релизом.От AFM зависит, например, как требования, сформированные на этапе проектирования, будут интерпретированы командой, как они повлияют на архитектуру, осуществимы ли они вообще и не создадут ли они серьезных технических проблем в будущем.
Чаще всего ACM является основным потребителем, интерпретатором и оценщиком отчетов автоматизированных инструментов и сторонних аудитов.
Именно ASM отфильтровывает нерелевантные и ошибочные результаты, оценивает риски, участвует в процессах управления исключениями и разработки компенсирующих мер.
Возьмем реальный пример: аудит или сканер исходного кода выявил использование в проекте небезопасной хеш-функции (MD5).
Политика компании формально утверждает, что использовать ее нельзя, а вендор соглашается заменить функцию на более безопасную в течение 3 месяцев и за крупную сумму.
Нюанс был в том, что в данном случае неустойчивость хеш-функции к коллизиям никак не влияла на безопасность системы, поскольку функция не использовалась для защиты целостности.
Формальный подход в данном случае и замена одной функции на другую привели к необоснованной задержке вывода проекта в производство и значительным затратам, дающим нулевой выигрыш в безопасности.
Во-вторых, помимо первого, АСМ должен обладать знаниями из разных областей: нужно понимать процессы разработки и принципы информационной безопасности.
«Hard Skills» также важны, потому что очень сложно критически оценить результаты работы профильных специалистов и автоматизированных инструментов, если ты не умеешь читать код и не понимаешь возможных способов эксплуатации уязвимостей.
Наверняка многие сталкивались с ситуацией, когда в отчете по анализу кода или пентесту появляется критическая уязвимость, но разработчики с этим не согласны (при этом они, как правило, тоже хотят создать безопасную систему) и указывают что аудиторы не смогли воспользоваться этой уязвимостью.
Как оценить, кто прав в такой ситуации? Без технических навыков объективно разрешить спор будет сложно.
Если процесс разработки безопасного ПО построен сторонней организацией и/или по сервисной модели, кто и как будет оценивать эффективность «технических» практик? Еще один реальный пример: внедряется новый инструмент разработки, проверяется его работоспособность на эталонном проекте, после чего он передается в коммерческую эксплуатацию.
К нему постепенно подключаются проекты, рисуется красивый зеленый дашборд. и тут происходит инцидент ИБ.
Как оказывается, использованная «дыра» должна была быть обнаружена еще на этапе динамического анализа.
Но этого не произошло, потому что.
никто не смотрел, как этот топовый сканер уязвимостей, который обычно дает отличные результаты, работает со SPA-приложениями на новом JavaScript-фреймворке.
Оказалось, что он не может «увидеть» динамически сгенерированную форму аутентификации и произвести необходимые проверки.
И никто на это не обратил внимания, потому что всё работало.
Разработчикам не нужно было вникать в особенности работы сканеров, чтобы обратить на это внимание, а специалисты по безопасности не увидели критических различий между разными подходами к веб-разработке.
Где найти такого специалиста?
Любой, кто изучал рынок, наверняка сталкивался с острой нехваткой специалистов по безопасности приложений.
Как правило, сценарий выглядит так: внутренние заказчики составляют требования к кандидату и передают их в отдел кадров.
Если требования строгие, то по результатам бесплатного поиска компания получает ноль кандидатов, поскольку готовые специалисты крайне редко выкладывают свои резюме в открытый доступ.
Если они меняют работу, то чаще всего это происходит легко и естественно через существующие контакты.
Что я должен делать? Можно попробовать переманить профессионала из других компаний, но этот путь не всегда приемлем по разным причинам.
Все чаще на рынке появляются конкурсы на аутстаффинг ACM, что вполне успешно позволяет закрыть вопрос путем аренды специалистов у поставщика услуг.
Но есть и другой вариант. Вы можете попробовать вырастить своего профессионала.
Подходящими кандидатами на такую роль могут быть представители двух сфер:
- люди с опытом разработки, которые интересуются или хотят развиваться в сфере безопасности;
- специалисты по безопасности, которые знакомы с разработкой программного обеспечения и безопасностью и хотят глубже погрузиться в эту тему.
В то же время те, кто пришел из отдела разработки и хочет «перековаться», будут лучше понимать существующую культуру и процессы в знакомых им командах.
Им может потребоваться довольно много времени, чтобы освоить области знаний, связанные с информационной безопасностью.
Однако опыт показывает, что среди разработчиков, тестировщиков, аналитиков и архитекторов можно найти людей, интересующихся безопасностью, которые уже обладают определенным набором знаний в области безопасности приложений.
Они могут быть идеальными кандидатами на работу в AFM. Профессиональным специалистам по безопасности придется акклиматизироваться, изменив существующие традиционные подходы к организации работы и переняв культуру команд разработчиков.
Однако если специалист по безопасности пишет код и знаком с процессами разработки, то он быстро и легко вольется в команду.
Общий
Контроль безопасности разработки – это прежде всего бизнес-процесс, успешное функционирование которого требует слаженного взаимодействия всех членов команды.«Сердцем» этого процесса является квалифицированный АСМ – он вдохновитель, двигатель направления, исполнитель многих задач, контролирующий менеджер и многое другое.
В общем, он и чтец, и жнец, и трубач.
Найти или вырастить такого специалиста непросто, но если вам это удастся, то все будут довольны.
Теги: #информационная безопасность #Интервью #Разработка мобильных приложений #Идеальный код #безопасность приложений #анализ кода #SDLC #анализ уязвимостей
-
Cmms Может И Улучшит Ваш Бизнес
19 Oct, 24 -
Фаренгейт, Даниэль Габриэль
19 Oct, 24 -
Что Может Быть Важнее Темпов Роста Бизнеса?
19 Oct, 24 -
Блог Компании Эр-Телеком
19 Oct, 24
