Безопасность + Разработка = ♡ Как выпускать релизы в срок и дружить с безопасностью

В идеальном мире команды безопасности — это компетентные специалисты, которые занимаются анализом рисков, моделированием угроз, защитой от целевых атак, расследованием инцидентов и другой важной работой. В том же идеальном мире разработчики ПО — это люди и команды, которые создают продукты и выполняют проекты в срок и с наилучшим качеством. В их продуктах не бывает уязвимостей, и иногда им всего лишь нужно пройти «эту дурацкую приемку» по безопасности у крупных заказчиков.

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

Начинаем диалог с командой безопасности

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

Свой безопасник 

В самом общем случае безопасник приходит к команде разработки и говорит: «Вот наши требования по безопасности [на все случаи жизни]. Понимаю, что они не слишком учитывают вашу специфику, но изменить эти требования нельзя. Вы уж придумайте что-нибудь…»

Что это значит на практике? Похоже, безопасник сам не знает: 

• Какие требования по безопасности реально важны для продукта; 

• Какие способы их реализации существуют в вашем продукте;

• Как проверить корректность их реализации. 

Чтобы понять, что с этим делать, стоит задать два простых вопроса: Какие риски мы закрываем? Зачем выполнять эти требования? 

Дальше возможны два варианта.

Если безопасник отвечает — Это обязательные требования / потому что регулятор / ибо ФЗ — то дальше можно тему не развивать и ограничиться следующими вопросами:

• Как будет происходить приемка по этим требованиям?

• Можно ли исключать требования на этапе приемки, если они не применимы для нашей системы? 

• Есть ли градация требований по приоритету выполнения? 

• Предложить свою методику проверки требований. 

Во втором случае безопасник может ответить более конструктивно, показав, что в приложении действительно есть проблемы с безопасностью и как они могут реализовываться: «Смотри, так наше приложение смогут взломать. Для этого достаточно будет…». Или: «Такая реализация будет очень ресурсоемкой, и сервис ляжет при минимальной попытке DDoS. Например, когда…» 

В этом случае самым разумным будет:

1. Показать, что конкретно вы уже сделали в вопросах безопасности; 

2. Объяснить, какие инженерные решения вы принимали с точки зрения безопасности и для чего; 

3. Проговорить, какие требования на самом деле не критичны и по факту их можно исключить.

Это уже более конструктивный диалог, и он намного быстрее приведет к сдаче системы.

Внешний заказчик

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

Узнать это вам помогут очень простые вопросы, но, если вовремя их задать, они сэкономят очень много времени:

• Что нужно описать, согласовать и сделать для начала испытаний по безопасности? 

• Кто назначает время испытаний? 

• Сможем ли мы всё показать у нас в облаке? Или обязательно в инфраструктуре заказчика? 

• Кто проводит демонстрацию? 

• Кто ведет протокол?

Дополнительно попросите дать информацию о проектах, которые уже реализованы и были согласованы с безопасностью. Уточните, можно ли получить проектную и рабочую документацию. Узнайте, как безопасники передают знания, какие есть требования и методы проверки. И можно ли получить доступ к ним хотя бы в форме Excel?

Итак, вы наладили контакт с безопасниками, это хорошее начало. Переходим к следующему пункту.

Создаем базу знаний с требованиями по безопасности 

С точки зрения безопасности лучше всего, если база знаний будет создана на платформе, которая уже используется или существует в компании. То есть вам не нужно делать уникальную базу только под безопасность.

Второй нюанс — база знаний должна быть доступна внутренним и внешним командам, а также подрядчикам, клиентам и партнерам. То есть всем, кто должен видеть требования по безопасности.

И тут надо быть готовым ответить на вопросы коллег из команды безопасности:

• «Кто получит доступ?» — Этот вопрос в общем-то относится к любой базе знаний. Опасение безопасников: вдруг в базу будут иметь доступ люди, не имеющие отношения к компании? 

• «Кто и как может вносить изменения в базу знаний?» — Опасение безопасников: что будет, если будут изменены данные, на основе которых принимаются важные решения?

Вы избежите подобных проблем, если учтете эти вопросы безопасников еще при проектировании.

Алгоритм создания защищенной базы знаний

1. Определите способы получения доступа на этапе создания базы знаний:

• Кто может инициировать доступ? 

• Какая форма заявки? 

• С кем согласуется доступ? 

• Кто предоставляет права в системе?

2. Оцените критичность знаний в базе, например:

• Компания понесет ущерб, если знания станут доступны кому угодно? 

• Что будет, если чужой человек создаст в базе статьи с «ложными» знаниями? 

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

3. Примените ограничения доступа, которые вы спроектировали.

Поддерживаем базу знаний для создания безопасных приложений

Наполняем базу

Лучшие на текущий момент и наиболее применимые к вашим продуктам и проектам требования можно взять из нескольких источников. Во-первых, это требования и руководства OWASP по безопасности мобильных платформ и приложений:

• Android: OWASP Mobile ASVS + Testing guide и Google Android Security Tips.

• iOS: OWASP Mobile ASVS + Testing guide и iOS Security.

• Web: OWASP Web Testing Guide и Payment Card Industry Data Security Standard.

Во-вторых, есть очень толковый стандарт индустрии безопасности платежных карт — PCI DSS. Он содержит требования и к безопасности приложений.

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

• Положение Банка России № 382-П «О требованиях к обеспечению защиты информации при осуществлении переводов денежных средств».

• ГОСТ Р 56939-2016 «Защита информации. Разработка безопасного программного обеспечения».

• Приказ ФСТЭК N 17. 

Будьте готовы к новым вопросам от команды безопасности: «Какой информацией там будут обмениваться? Вдруг это будут номера телефонов и счета клиентов, логины и пароли к системам, другая конфиденциальная информация?» Чтобы это требование не стало блокером, следите, чтобы в базе знаний не было конфиденциальной информации или персональных данных ваших клиентов, заказчиков или кого-то еще.

Поддерживаем знания в базе актуальными

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

• Изменения в стеке технологий, которые вы используете. Это должно приводить к обновлению знаний в базе по требованиям безопасности.

• Обновления уже упомянутых стандартов. Если вы решили взять их за основу — следите за появлением новых версий.

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

• Публичные инциденты, если они касаются безопасности ваших приложений. Наиболее полный и хороший источник для отслеживания — подписка от SANS.

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

Важно не только обновлять базу знаний, но и держать коллег в курсе изменений. Командам необходимо знать, что требования изменились, особенно в части безопасности. Назначьте того, кто будет пересматривать базу после обновлений и уведомлять команду. 

Маппинг требований

Если просто собирать в базу знаний все требования из рекомендуемых стандартов и руководств, то вы получите увеличенную в 2-3-4 раза базу, и при этом требования будут одними и теми же или практически идентичными. Например:

• OWASP: ошибки подсистемы аутентификации должны обрабатываться безопасно и не позволять атакующему войти в АС.

• Стандарт Банка России: должны быть определены, выполняться, регистрироваться и контролироваться правила и процедуры: идентификации, аутентификации, авторизации субъектов доступа, в том числе внешних субъектов доступа, которые не являются работниками организации БС РФ, и программных процессов (сервисов).

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

Определяем приоритеты и нужный объем знаний

Определите приоритеты и объем знаний, который должен быть у ваших команд. Стек на разных проектах в разных командах может быть очень разнообразным. Но, условно, фронтенду не нужно знать всё о безопасности бэкенда.

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

Определяем потребителей знаний и делимся знаниями самым удобным способом

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

Для регулярного управления требованиями по информационной безопасности при разработке ПО используйте продукты класса ASRTM — Application security requirements and threat management:

Итак, мы познакомились с безопасниками, узнали, как создать базу знаний с требованиями по безопасности, как ее наполнить и как управлять этими знаниями. Остался последний вопрос: как знания применить на практике?

От базы знаний — к навыкам безопасной разработки

Наверное, есть такие предметные области, где можно обойтись только знаниями, где знания — это самоцель и конечный результат. Но в нашем случае недостаточно просто «знать». В безопасности «уметь применять знания» значит «выполнять требования по безопасности». Как этого можно добиться? 

Игры в безопасность

Первый вариант  — так называемые CTF (Capture the Flag) активности. Эти соревнования часто выглядят достаточно интересно и весело. Они дают инженерам, программистам, разработчикам возможность почувствовать себя на месте тех, кто, вероятно, будет взламывать их приложения. Иногда эти соревнования проходят в командном формате, когда одна команда пытается защитить свои системы, а другая пытается их взломать.

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

Другой пример и другой подход — проекты типа WebGoat и HackThisSite. Это специально созданные приложения, чтобы можно было потренироваться искать уязвимости, компрометировать приложения и даже немного изменять их код, чтобы они становились более безопасными. 

Еще один подход можно увидеть, например, в сервисе Hacksplaining. Его создатели не просто объясняют какие-то правила безопасности, важные с точки зрения разработки. Они показывают, как эти правила могут выполняться или не выполняться в коде, и даже дают чуть-чуть попрактиковаться в искусственной, но интересной среде. И также показывают, как можно эксплуатировать проблемы с безопасностью, и объясняют, как их можно исправить.

Последний пример, как можно перейти от знаний к навыкам — это сервис Secure Code Warrior. Его особенность в том, что даже среда очень похожа на среды разработки, в которых люди реально работают. Разработчику предлагают найти уязвимость, где может быть проблема с безопасностью. После чего — понять, какое подойдет решение, и выбрать наиболее подходящее.

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

Качественный код = безопасный код

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

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

Выводы

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

• Не жалуйтесь на безопасников, но налаживайте контакт, чтобы знать, что на самом деле движет их запросами.

• Понимайте риски, которые актуальны для ваших систем, приложений и проектов. 

• Действуйте проактивно — показывайте, что уже сделано, чтобы обеспечить защищенность ваших продуктов.

• Управляйте знаниями для создания безопасных систем.

• Обучайте своих людей и тренируйте навыки безопасной разработки в своих командах.

Мое выступление на KnowledgeConf 2020:

Объявлен Call for Papers на Saint TeamLead 2022. Конференция пройдет 26 и 27 сентября в Санкт-Петербурге. Нужны спикеры, которые расскажут о своих best practices, успешных кейсах, какие инструменты используют и как практически используют методологии.

Билеты можно купить здесь. До очередного повышения цены осталось 5 дней.