Что может включаться в чек лист application security

Безопасность в веб-разработке: чек-лист

Светлана Шаповалова, редактор «Нетологии», адаптировала статью Michael O’Brien, в которой он составил чек-лист для веб-разработчиков, предпочитающих разрабатывать не только удобные, но и безопасные приложения.

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

Если вы уже заразились идеей «минимально жизнеспособного продукта» (англ. MVP — minimum viable product, прим. перев.) и считаете, что за месяц можно создать одновременно полезный и безопасный продукт — подумайте дважды, прежде чем выпускать его. Просмотрев чек-лист, вы поймете, что оставляете немало уязвимостей.

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

Чек-лист весьма прост и пока еще не до конца полон. Я занимаюсь разработкой безопасных веб-приложений уже более 14 лет и включил в список самые важные вопросы, с которыми столкнулся за это время. Надеюсь, что создавая свой продукт, вы отнесетесь к ним серьезно.

Базы данных

Разработка

Идентификация

Защита от DDoS-атак

Веб-трафик

Валидация

Облачная конфигурация

Инфраструктура

Эксплуатация

Тестирование

Главное — планируйте

Минутка рекламы от редакции

Мы коммерческий блог, а потому не можем без ссылок:) В этот раз принесли две — на программы «Профессия веб-разработчик» и «Профессия frontend-разработчик».

Для тех, кто интересуется веб-разработкой и любит получать знания в систематизированном виде, «Нетология» открыла набор на программу «Профессия веб-разработчик».

Что изучается на курсе:

Старт занятий 23 июня. Все подробности здесь →

Также идет набор на «Профессию frontend-разработчик» — курс, ориентированный на получение навыков frontend-разработки с нуля.

Источник

Чек-лист по анализу логов событий безопасности

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

Общая схема действия

1. Определите, какие источники журналов и автоматизированные инструменты можно использовать для анализа

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

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

4. Определите, можно ли полагаться на метки времени журналов; рассмотрите различия часовых поясов

5. Обратите внимание на последние изменения, сбои, ошибки, изменения состояния, доступ и другие события, необычные для вашей IT-среды

6. Изучите историю событий, чтобы восстановить действия до и после инцидента

7. Сопоставьте действия в разных журналах, чтобы получить полную картину

8. Сформируйте гипотезу о том, что произошло; изучите журналы, чтобы подтвердить или опровергнуть её

Потенциальные источники логов безопасности

Стандартное расположение логов

Что искать в логах Linux

Что искать в логах Windows

Идентификаторы событий перечислены ниже для Windows 2008 R2 и 7, Windows 2012 R2 и 8.1, Windows 2016 и 10. (В оригинальной статье используются в основном идентификаторы для Windows 2003 и раньше, которые можно получить, отняв 4096 от значений указанных ниже EventID)

Большинство событий, приведенных ниже, находятся в журнале безопасности (Windows Event Log: Security), но некоторые регистрируются только на контроллере домена.

Что искать в логах сетевых устройств

Изучите входящие и исходящие действия ваших сетевых устройств.

Примеры ниже – это выдержки из логов Cisco ASA, но другие устройства имеют схожую функциональность.

Что искать в логах веб-сервера

Полезные ссылки

Примеры событий Windows по каждому EventID:
EventID.Net
Справочник событий журнала безопасности Windows:
Windows Security Log Encyclopedia
Список инструментов анализа журналов:
Best Log Management Tools
Другие «шпаргалки», связанные с реагированием на инциденты безопасности в блоге одного из авторов оригинальной статьи:
IT and Information Security Cheat Sheets

Источник

Как обеспечить безопасность приложения? 8 ответов от безопасников

Авторизуйтесь

Как обеспечить безопасность приложения? 8 ответов от безопасников

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

А так ли это на самом деле?

Какие уязвимости можно найти в приложении?

Ещё живут различные инъекции (SQL, NoSQL, LDAP, OS, XML, XQuery, XPath, XSLT), LFI-уязвимости, закладки (внедрённые в код функции, которые срабатывают в определённый момент), слабые алгоритмы шифрования, небезопасная работа с логами и cookie, а также утечка информации через социнжиниринг.

Самые опасные уязвимости веб-приложений можно посмотреть на странице OWASP Top Ten, которая регулярно обновляется.

И это лишь вершина айсберга.

Правда ли, что львиная доля атак приходится на бреши в механизмах аутентификации?

Согласно статистике Positive Technologies, наиболее часто встречающиеся уязвимости веб-приложений за 2019 год связаны с неправильной настройкой безопасности. А вот самому высокому риску подвержены сайты со слабой аутентификацией. Такая проблема была обнаружена в 45% исследованных веб-приложений:

Почти треть таких уязвимостей обусловлена неограниченным количеством попыток войти в аккаунт. Аутентификация только по паролю является тем фактором, который способствует наибольшему количеству атак посредством перебора комбинаций «логин/пароль». Требования к возрасту и сложности пароля, которые раньше были «золотым стандартом», теперь подрывают безопасность. Согласно рекомендациям NIST, организациям следует перейти на многофакторную аутентификацию, если они ещё этого не сделали.

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

Обеспечение безопасности приложения — это задача безопасников?

Не совсем, ведь уже на стадии разработки нужно обращать внимание на очевидные уязвимости.

Разработчик должен с первой редакции сайта или приложения заложить основные инструменты защиты данных пользователя, например Web Application Firewall. В дальнейшем, с выходом патчей, закрывать появляющиеся уязвимости. В идеальной ситуации разработчик должен либо самостоятельно, либо с привлечением дополнительных специалистов тестировать продукт на проникновение, раз за разом применяя популярные методы взлома и после анализируя полученный результат.

Что включает в себя обеспечение безопасности приложения?

Это все меры, в том числе и те, которые предшествуют этапу разработки:

Application security — сложная задача, особенно в больших командах. Здесь важна грамотная работа архитекторов, которая предусмотрит механизмы безопасности для каждого из «кирпичиков» проекта, тем самым обеспечивая многоуровневую защиту продукта.

Какими бывают технические средства анализа защищённости кода?

Основной пласт анализаторов включает в себя:

Как создать защищённую среду разработки?

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

На что должен обращать внимание разработчик, чтобы защитить приложение от взлома?

Позаботиться о безопасности сервиса лучше на самых ранних этапах его разработки. В этом помогут проекты от сообщества OWASP, например руководства «Проактивная защита: Топ-10 требований OWASP» (набор практик для изначального повышения безопасности приложения) и рейтинг 10 самых опасных угроз безопасности веб-приложений OWASP Top 10. Также важным является включение безопасности как составляющей цепочки CI/CD вашего приложения, например использование SAST и DAST-решений. Причём необязательно сразу покупать и внедрять коммерческие решения, ведь существуют и вполне достойные варианты из мира свободного ПО.

По моему опыту, один из главных шагов к безопасности приложения — это ограничение функциональности для каждого пользователя по принципу need-to-know. Этот принцип возник в военной среде, однако полезен и в разработке: соблюдая его, вы не даёте пользователю получать больше информации, чем ему нужно.

Не менее важны процессы код-ревью и независимого анализа защищённости. Для второго можно привлекать собственную команду безопасности, обращаться в специализированные компании или добавить приложение в программу bug bounty, чтобы сотни исследователей со всего мира непрерывно искали за вас баги.

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

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

А как обстоят дела с безопасностью мобильных приложений?

Безопасная разработка мобильного приложения включает три этапа.

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

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

Далее необходимо протестировать приложение на предмет наличия подобных уязвимостей. В основном используются методы белого и чёрного ящика. Метод белого ящика (статистическое тестирование безопасности SAST) подразумевает проверку разработчиком, имеющим доступ к коду. Метод чёрного ящика предполагает анализ только пользовательского опыта, без оценки кода. Тестировать можно вручную или с помощью специальных сервисов.

И последнее, перед собственно отработкой выявленных уязвимостей расставьте приоритеты. В первую очередь устраните ошибки, при которых работа приложения невозможна. Затем идут критические баги: зависание системы или временные падения. После смотрите на ошибки, не влияющие на работу, например, недочёты дизайна. В самом конце устраняйте мелкие баги.

Рекомендую использовать параметризованные запросы к базе данных, не конструировать запросы внутри системы, для доступа к БД использовать отдельную учётку и не забывать про журналы безопасности.

Резюмируя

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

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

Источник

Перевод стандарта ASVS 4.0. Часть 1

Это первая статья из серии переводов стандарта Application Security Verification Standard 4.0, который был разработан OWASP в 2019 году. Стандарт состоит из 14 групп требований для программного обеспечения. Первая группа (V1) содержит в себе требования к архитектуре и моделированию угроз для основных функций ПО, таких как, аутентификация, управления сеансами, контроль доступа и др. Последующие группы расширяют список требований для каждой из функций.

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

Стандарт проверки безопасности приложений (Application Security Verification Standard – ASVS 4.0)

1. О стандарте

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

1.1 Использование ASVS

ASVS преследует две основные цели:

— помочь организациям разрабатывать и поддерживать безопасные приложения;

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

1.2 Уровни проверки безопасности приложений

Стандарт проверки безопасности приложений определяет три уровня проверки безопасности, каждый из которых дополняет требования предыдущего уровня.

— Уровень 1 предназначен для низкого уровня доверия и может быть полностью протестирован только с помощью тестов на проникновение.

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

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

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

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

За последние 30 с лишним лет тестирование методом «чёрного ящика» снова и снова доказывало, что упускает из виду критические проблемы безопасности, которые напрямую вели к более серьёзным последствиям. Авторы стандарта настоятельно рекомендуют использовать весь спектр средств обеспечения и проверки безопасности, включая замену тестов на проникновение методом «чёрного ящика» полным доступом к коду, документации и разработчикам на протяжении всего процесса создания. Например, финансовые регулирующие органы не допускают внешний финансовый аудит без доступа к бухгалтерским книгам, образцам операций или людям, осуществляющим контроль. Промышленность и правительства должны требовать одинаковых стандартов прозрачности в области разработки программного обеспечения.

Авторы стандарта настоятельно рекомендуют использовать инструменты безопасности в самом процессе разработки, такие как инструменты DAST (Dynamic Application Security Testing) и SAST (Static Application Security Testing), которые должны непрерывно использоваться при сборке приложений, чтобы легко находить типовые проблемы безопасности.

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

1.3 Как пользоваться стандартом

Один из лучших способов использования стандарта – применять его в качестве образца для создания чек-листов безопасного программирования для вашего приложения, платформы или организации. Адаптация ASVS к вашим вариантам использования позволит сосредоточить внимание на требованиях безопасности, которые наиболее важны для ваших проектов и сред.

Приложение достигает Уровня 1 ASVS, если оно адекватно защищено от уязвимостей, которые легко обнаружить и которые включены в OWASP Top 10 или другие чек-листы, например, списки самых распространённых CVE (Common Vulnerabilities and Exposures) или CWE (Common Weakness Enumeration).

Уровень 1 – это минимум, к которому должны стремиться все приложения. На Уровень 1 также полезно ориентироваться при проведении первых этапов работ по созданию приложений или, когда приложения не хранят и не обрабатывают конфиденциальные данные, следовательно, не нуждаются в более строгих элементах контроля Уровней 2 или 3. Элементы управления Уровня 1 могут быть проверены либо автоматически с помощью инструментов, либо просто вручную без доступа к исходному коду. Авторы считают Уровень 1 минимальным уровнем, необходимым для всех приложений.

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

Уровень 2 – Большинство приложений

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

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

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

Уровень 3 – это самый высокий уровень проверки в рамках ASVS. Этот уровень обычно предназначается для приложений, требующих значительного уровня проверки безопасности, например, тех, которые могут быть использованы в областях вооружённых сил, здравоохранения и безопасности, критической инфраструктуры и т.д.

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

Приложение на Уровне 3 ASVS требует более глубокого анализа или более продуманной архитектуры, кодирования и тестирования, чем все остальные уровни. Безопасное приложение имеет конструктивную модульную структуру (для обеспечения отказоустойчивости, масштабируемости и, прежде всего, уровней безопасности), и каждый модуль (разделённый сетевым подключением и/или находящийся на другом физическом экземпляре) выполняет свои собственные обязанности по безопасности, которые необходимо надлежащим образом задокументировать. Обязанности по обеспечению безопасности включают в себя средства управления для обеспечения конфиденциальности (например, шифрование), целостности (например, транзакции, проверка ввода), доступности (например, корректная обработка нагрузки), аутентификации (в том числе между системами), неотказуемости, авторизации и аудита (журналирование).

1.4 Применение ASVS на практике

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

2. Оценка и сертификация

2.1 Позиция OWASP в отношении сертификации ASVS и знаков доверия

OWASP, как некоммерческая организация, не зависящая от поставщиков, в настоящее время не сертифицирует поставщиков, верификаторов или программное обеспечение.

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

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

2.2 Руководство для сертифицирующих организаций

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

Исторически сложилось так, что при тестировании на проникновение и анализа безопасности кода в окончательном отчёте указывались только тесты, которые были провалены. Сертифицирующая организация должна включать в любой отчёт объем проверки (особенно, если ключевой компонент выходит за рамки, например, SSOauthentication), сводку результатов проверки, включая удавшиеся и неудавшиеся тесты, с чёткими указаниями о том, как устранить причины провала теста.

Некоторые требования проверки могут быть неприменимы к тестируемому приложению. Например, если вы предоставляете своим клиентам API-сервис без сохранения состояния и без реализации клиента, многие требования по управлению сессиями (V3 Session Management) не применимы напрямую. В таких случаях сертифицирующая организация может по-прежнему требовать полного соответствия ASVS, но должна чётко указать в отчёте причину неприменимости исключённых требований.

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

2.3 Метод тестирования

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

Роль автоматизированных средств тестирования безопасности

Рекомендуется использовать автоматизированные инструменты тестирования на проникновение для обеспечения максимально возможного покрытия. Невозможно полностью завершить проверку ASVS с использованием только автоматизированных инструментов тестирования на проникновение. Хотя подавляющее большинство требований Уровня 1 можно выполнить с помощью автоматических тестов, в целом большинство требований не проверяются автоматическим тестированием на проникновение. Обратите внимание, что границы между автоматическим и ручным тестированием стираются по мере развития индустрии безопасности. Автоматизированные инструменты часто настраиваются вручную экспертами, и при ручном тестировании часто используется широкий спектр автоматизированных инструментов.

Роль тестирования на проникновение

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

При выполнении оценки Уровня 2 или 3 требуется взаимодействие с разработчиками, доступ к документации, коду и тестовому приложение с не конфиденциальными данными. Тестирование на проникновение, проводимое на этих уровнях, требует такого уровня доступа, который обычно называется «гибридные проверки» или «гибридные тесты на проникновение».

3. Другое использование ASVS

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

Как подробное руководство по архитектуре безопасности

В качестве замены готовых контрольных списков безопасного программирования

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

В качестве руководства для автоматизированных модульных и интеграционных тестов

ASVS разработан для обеспечения высокого качества тестирования. Создавая модульные и интеграционные тесты, которые проверяют конкретные и релевантные случаи неувязок и завышенных полномочий, разработчики делают приложение почти самопроверяющимся при каждой сборке. Например, для набора тестирования входа в систему могут быть созданы дополнительные модули, проверяющие имя пользователя на предмет совпадения со списками распространённых имён по умолчанию, нумерации аккаунтов, брутфорс, внедрение XSS, LDAP- и SQL-инъекций. Точно так же проверка параметров пароля должна включать словарные пароли, длину пароля, инъекцию нулевого байта, удаление параметра, XSS и многое другое.

Для обучения безопасной разработке

Как основа для Agile-методов разработки приложений

ASVS можно использовать в процессе Agile разработки в качестве базы для определения конкретных задач, которые должны быть реализованы командой, чтобы получить безопасный продукт. Один из подходов может быть следующим: начиная с уровня 1, проверьте конкретное приложение или систему в соответствии с требованиями ASVS для указанного уровня, найдите, какие элементы отсутствуют, и создайте определённые задачи в следующий спринт. Это помогает расставить приоритеты для конкретных задач и делает безопасность видимой в Agile-процессе. Это также можно использовать для ранжирования задач аудита и проверки в организации, где конкретное требование ASVS может быть основой для проверки, рефакторинга или аудита для конкретного члена команды и отображаться как «задолженность», которую необходимо в конечном итоге выполнить.

Как основа для руководства закупкой безопасного ПО

Далее следует содержательная часть стандарта. В этой части статьи будет приведена только первая группа требований.

4. V1: Требования к архитектуре, дизайну и моделированию угроз

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

Если бы разработчики вложили средства в единую безопасную модель поставщика учётных записей, такую как SAML, поставщик мог бы быть обновлён с учётом новых требований, таких как соответствие NIST 800-63, без изменения интерфейсов исходного приложения. Если многие приложения используют одну и ту же архитектуру безопасности и, следовательно, один и тот же компонент, все они получают выгоду от этого обновления. Однако SAML не всегда будет лучшим или наиболее подходящим решением для аутентификации – его, возможно, придётся заменить другими решениями по мере изменения требований. Подобные изменения либо сложны и настолько дороги, что потребуют полного переписывания кода, либо вообще не будут возможны без внедрения безопасной архитектуры.

В этой главе ASVS охватывает основные аспекты любой надёжной архитектуры безопасности: доступность, конфиденциальность, целостность обработки, невозможность отказа от авторства и конфиденциальность. Каждый из этих принципов безопасности должен быть встроен во все приложения. Очень важно проводить Shift-left тестирование, начиная с предоставления разработчикам контрольных списков безопасного кодирования, наставничества и обучения, программирования и тестирования, построения, развёртывания и конфигурирования, заканчивая последующим независимым тестированием, чтобы гарантировать, что все меры безопасности присутствуют и функционируют. Раньше индустрия тестирования занималась только последним шагом, но этого уже недостаточно, когда разработчики публикуют код в production десятки или сотни раз в день. Специалисты по безопасности приложений должны не отставать от Agile-методов, что означает внедрение инструментов разработчика, обучение программированию и работу с разработчиками, а не критику проекта через несколько месяцев после того, как все остальные ушли.

Требования к жизненному циклу безопасной разработки программного обеспечения

Таблица 1 – V1.1 Требования к жизненному циклу безопасной разработки программного обеспечения

Источник