Практические советы по использованию тестирования безопасности приложений и стандартов тестирования
modern security, secure, security, безопасность, тестирование безопасности
Сообщество по безопасности постоянно меняется, растет и учится друг у друга, чтобы лучше защищать мир от киберугроз. В последнем посте серии блогов «Голос сообщества» менеджер по маркетингу продуктов Microsoft Наталья Годыла беседует с Дэниелом Катбертом, руководителем глобального отдела исследований в сфере безопасности в Banco Santander.
Наталья Годыла, Менеджер по маркетингу продуктов, служба безопасности
Дэниел Катберт, Руководитель глобального отдела исследований в области безопасности, Banco Santander
Дэниел рассказывает о том, как использовать тестирование безопасности приложений и стандарты тестирования для повышения уровня безопасности.
Наталья: Что такое тест безопасности приложения и что он в себя включает?
Даниэль: Допустим, у меня есть традиционное легальное банковское приложение. Пользователи могут войти в систему через веб-браузер, чтобы получить доступ к финансовой информации или средствам, осуществлять перевод и получение денег. Обычно, когда вы хотите провести оценку приложения такого типа, смотрите на процессы аутентификации и авторизации, на то, как работает архитектура приложения, как оно обрабатывает данные и как пользователь взаимодействует с ним. По мере того, как из одного приложения, взаимодействующего с внутренней базой данных, вырастают приложения с функциями микросервисов, все более важными становятся все способы перемещений и установки данных и процессы
Как правило, при тестировании приложений проверяется нулевая вероятность того, что кто-то сможет получить несанкционированный доступ к данным или чужим деньгам. Мы хотим убедиться, что авторизованный пользователь не сможет выдать себя за другого пользователя, получить доступ к чужим средствам или заставить систему сделать в архитектуре то, чего разработчики или инженеры никогда не ожидают.
Наталья: Что такое стандарт проверки безопасности приложений (ASVS), Open Web Application Security Project (OWASP), и как организации должны использовать этот стандарт?
Даниил: ASVS расшифровывается как Application Security Verification Standard1. Идея заключалась в том, чтобы нормировать порядок проведения тестов безопасности приложений и получения их результатов. До этого никакой методологии не существовало. В отрасли было много неясностей. Вы говорили: «Мне нужно провести тест приложения», и надеялись, что у выбранной вами компании есть методология, а люди, проводящие оценку, способны следовать этой методологии.
В реальности это было не так. В разных компаниях, занимающихся тестированием на проникновение, были разные подходы. Те, кто получал консультации по тестам на проникновение и тестированию приложений, не имели четкого представления о том, что должно быть протестировано или какое приложение является безопасным и надежным. Вот здесь-то и приходит на помощь ASVS. Теперь вы можете сказать: «Мне требуется провести тестирование приложения. Мне нужна оценка этого приложения на Уровне 2». Человек, получающий тест, точно знает, чего он ожидает, а человек, проводящий тест, точно знает, чего ожидает клиент. Все оказываются на одной волне, и именно этого нам не хватало раньше.
Наталья: Как компании должны расставлять приоритеты и ориентироваться в уровнях ASVS и контролях?
Дэниел: При первом знакомстве с ASVS многие люди пугаются и нервничают. Прежде всего, сохраняйте спокойствие. Ориентиром являются три уровня. Уровень 1 должен быть абсолютным минимумом. Он вступает в игру, если вы размещаете приложение в интернете, и мы стараемся разработать Уровень 1 так, чтобы его можно было автоматизировать. Что касается инструментов для автоматизации Уровня 1, то это достигается с OWASP Zed Attack Proxy (ZAP). В 2021 году приложение должно соответствовать Уровню 2, особенно если принимать во внимание конфиденциальность. Уровень 3 является уникальным. Большинству людей никогда не понадобится Уровень 3, который был разработан для критически важных приложений с высоким уровнем безопасности – там, где в случае сбоя возможна гибель людей или масштабные последствия. Уровень 3 – это дорогой и длительный процесс, но вы все же будете ждать, если речь идет, скажем, об электростанции. Вы же не хотите, чтобы все было быстренько собрано за пару часов.
На любом из уровней вам не потребуется проходить через каждый элемент управления; здесь на помощь приходит моделирование угроз. Если ваше приложение использует внутреннюю базу данных, и есть микросервисы, вы из Уровня 2 отбираете те части, которые вам нужны, и строите свою программу тестирования. Многие думают, что надо тестировать каждый элемент управления, но это не так. Вы должны настроить тестирование так, как вам нужно.
Наталья: Какова правильная периодичность проведения тестов безопасности приложений?
Даниэль: Процесс создания приложений изменился кардинально. Десять лет назад многие люди работали по принципу водопада, используя функциональные спецификации типа: «Я хочу создать приложение для продажи обуви». Отлично. Кто-то дает деньги и устанавливает время. Разработчики приступают к разработке, а ближе к концу начинают проводить функциональное тестирование на приемку пользователем (UAT) и поручают кому-то провести тест на проникновение. Худшая ошибка. По моему опыту, мы запускали все в понедельник, а за неделю до этого проводился тест на проникновение.
То, что мы наблюдаем с внедрением гибкого подхода – это сдвиг влево жизненного цикла разработки ПО (SDLC). Мы начинаем видеть, что люди думают о безопасности не только как о дополнении в конце разработки, но и как о части функции. Мы ожидаем, что приложение будет безопасным, удобным и надежным. Мы применяем стандарты безопасности. Мы внедряем защитные ограничения для нашей последовательной интеграции и непрерывной доставки. Это означает, что разработчики пишут функцию, вносят код в Git или любой другой репозиторий, и код проверяется на надежность, правильность форматирования и безопасность. В отрасли мы отходим от того, чтобы полагаться на финальный тест приложения, и постоянно проверяем его в течение всего жизненного цикла на наличие ошибок, неправильной конфигурации или неправильного использования шифрования или кодирования.
Наталья: Какие распространенные ошибки, влияющие на результаты оценки безопасности приложений, допускают компании?
Дэниел: Первая ошибка заключается в том, что компании не принимают чудесный мир моделирования угроз. Модель угроз может сэкономить вам время и задать направление. Когда люди обходят стороной фундаментальный этап моделирования угроз, то сжигают циклы. Если вы примете модель угроз и скажете: «Вот все возможные способы, с помощью которых недоброжелатели могут взломать наше любимое приложение», – это может послужить основой и от нее можно отталкиваться.
Вторая ошибка – непонимание того, что делают все звенья вместе. Мы больше не создаем приложения, которые представляют собой один веб-сервер, Internet Information Services (IIS) или NGINX, хранящийся в базе данных. Сегодня такое встречается редко. Сегодняшние приложения комплексны. Поскольку за отдельные части этого процесса отвечают несколько команд, они не работают вместе для понимания таких простых вещей, как поток данных. Где хранятся данные? Как это приложение обрабатывает данные? Часто все полагают, что этим занимается другая команда. Это проблема. Либо scrum-мастер, либо владелец продукта должны иметь полную видимость приложения, особенно если это крупный проект. Но это зависит от организации. Мы еще не достигли достаточно зрелой стадии, чтобы эта роль стала определяющей.
Кроме того, разрыв между безопасностью и разработкой все еще слишком велик. У службы безопасности раньше было не так много друзей. Мы постоянно принижали разработчиков. Я был частью этого, и мы были неправы. В настоящее время мы пытаемся объединить обе команды. Мы хотим, чтобы разработчики видели, что служба безопасности пытается им помочь.
Мы должны создать разработчикам условия, чтобы они могли быть настолько креативными и крутыми, насколько мы этого от них ожидаем, и в то же время установить ограждения, чтобы предотвратить появление распространенных ошибок в конвейере кодов. Безопасный код писать очень трудно, но тут мы можем использовать четвертое поколение непрерывной интеграции и непрерывной доставки (CI/CD). Зарегистрируйте здесь свой код; затем проведите серию тестов. Убедитесь, что в этот момент и при этой фиксации код соответствует требованиям надежности, безопасности и корректности.
Наталья: Как команда безопасности должна работать с разработчиками для защиты от уязвимостей?
Дэниел: Я не ожидаю, что разработчики будут разбираться во всех последних уязвимостях. Это роль команды безопасности или инженеров по безопасности. По мере развития команд, инженеры по безопасности или служба безопасности выступают в роли связующего звена. Понимая какие есть уязвимости и как ими могут воспользоваться, они воплощают соответствующие наработки в процессе разработки людьми кода для своей организации. Они также рассматривают различные инструменты или процессы, которые можно использовать, чтобы предотвратить появление этих уязвимостей.
Одна из действительно крутых вещей, которые я начинаю видеть в GitHub, – это идеи GitHub. Допустим, есть крупная организация, у которой тысячи репозиториев. Проанализировав все эти репозитории, вы, вероятно, увидите общую картину уязвимостей. Сегодня мы приближаемся к тому этапу, когда у нас будет функция безопасности в стиле «Minority Report».
На ежемесячной основе я могу сказать: «Покажите мне команды, которые проверяют ошибки – допустим, десериализацию». Я хочу понять проблему до того, как она станет серьезной, и поработать с этими командами, чтобы сказать: «Из последних 10 аргументов 4 были отмечены как уязвимые для ошибок десериализации. Давайте сядем и поймем, как вы строите, для чего вы строите, и какие конструкции пытаетесь внедрить. Можем ли мы создать для вас более лучшие инструменты для защиты от уязвимости? Хотите ли вы понимать саму уязвимость?». Инструменты, конвейеры и обучение уже существуют. Мы можем стать этим мостом.