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

ИБ

Портал для специалистов по информационной безопасности. Новости, нормативная правовая и справочная документация. Шаблоны документов.

  • Главная
  • Новости
  • НПА
    • Стандарты и методики
    • Приказы ФСБ России
    • Приказы ФСТЭК
  • Загрузки
Вы читаете: Анализ уязвимостей в ГОСТ 15408
Поделиться
Aa

ИБ

Портал для специалистов по информационной безопасности. Новости, нормативная правовая и справочная документация. Шаблоны документов.

Aa
Поиск
  • Главная
  • Новости
  • НПА
    • Стандарты и методики
    • Приказы ФСБ России
    • Приказы ФСТЭК
  • Загрузки
Follow US
ИБ > Информационная безопасность > Анализ уязвимостей в ГОСТ 15408
Информационная безопасность

Анализ уязвимостей в ГОСТ 15408

3 года назад Просмотров: 22 3 года назад минут на прочтение: 5
Поделиться

[ad_1]

И еще раз (а может, еще и не раз) вернемся к вопросу о том, что такое «анализ уязвимостей в соответствии с требованиями ОУД4 ГОСТ 15408-3». А точнее, о том, что делать банкам с самостоятельно разработанными приложениями.

Прежде всего стоит обратить внимание на то, что сам по себе ГОСТ 15408 никак не определяет, в чем именно должен заключаться анализ уязвимостей. В ОУД4 за него отвечает компонент доверия AVA_VAN.3, который говорит, что должен посмотреть оценщик (документацию, внешние источники на предмет наличия в продукте уже известных уязвимостей и исходный код на предмет зеродеев, но ничего не говорит о том, как что именно и как именно оценщик должен искать. Более полное описание содержится в дополнении к ГОСТ 15408 — в стандарте ГОСТ 18045 «Методология оценки безопасности информационных технологий». Итак, в чем именно заключается анализ уязвимостей по версии «Общих критериев»?

  1. Оценщик должен изучить открытые источники и выяснить, нет ли в исследуемом продукте известных потенциальных уязвимостей. Очень часто это воспринимается как «давайте посмотрим в CVE, нет ли там известных уязвимостей для продукта», и это неверно. В методологии четко оговаривается, что речь идет об открытых материалах (книгах, статьях, материалах конференций), в которых описываются потенциально возможные уязвимости информационной технологии, реализованной в продукте. Так, если речь идет о веб-приложении (а к им относятся практически все фронтэнды ДБО и мобильного банкинга), то основным открытым источником для оценщика должен стать OWASP, а потенциальными уязвимостями — SQL-инъекции, XSS и весь прочий зверинец типовых уязвимостей веб-приложений. Т.е. речь на этом шаге оценки идет прежде всего о типовых уязвимостях и типовых ошибках разработки, характерных для технологии, а не только об отдельных идентификаторfх CVE.

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

  3. Кроме того, оценщик должен провести анализ исходного кода продукта (т.н. «представление реализации») в поисках зеродеев.

    Но, что гораздо интереснее, один из документов, которые на этой стадии изучает оценщик, это документ «Описание архитектуры безопасности». Согласно требованиям ГОСТ 15408, этот документ должен, помимо прочего, содержать следующую информацию:

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

  • демонстрацию того, что механизмы защит продукта невозможно обойти.

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

  • Выявленные уязвимости оценщик должен верифицировать (провести т.н. «тестирование проникновения»). Фактически речь идет о проведении эксплойтных проверок, которые подтвердят возможность или невозможность экплуатации выявленных оценщиком уязвимостей.

  • Как и в требованиях нормативных документов ФСТЭК, при оценке по ГОСТ 15408 оценщик дает положительное заключение по результатам анализа уязвимостей только в том случае, если он не выявил никаких уязвимостей или если выявленные уязвимости не удалось проэксплуатировать. Т.е. для успешного прохождения анализа уязвимостей в рамках ГОСТ 15408 не обязательно выявлять и устранять абсолютно все уязвимости: достаточно выявить и устранить те уязвимости, которые способен самостоятельно найти оценщик — или нарушитель.

    К сожалению, ни ГОСТ 15408, ни ГОСТ 18045 ничего не говорят о том, в чем именно должен заключаться поиск зеродеев в исходных кодах — и это один из основных недостатков Общих Критериев. Отсутствие прямых указаний на эту тему побудило Банк России разработать дополнительные требования к анализу уязвимостей, включив их в проект профиля защиты для автоматизированных банковских систем и приложений. Но об этих требованиях — в следующий раз.

    [ad_2]

    Источник

    Вас может заинтересовать

    Вводятся в действие рекомендации по стандартизации Р 1323565.1.043–2022

    Вступает в действие ГОСТ Р 70262.1-2022

    ИБ для чайника. Часть 1.

    Лабиринт малотавра: Как мы моделируем угрозы. Часть 3: техники и тактики

    Лабиринт малотавра: Как мы моделируем угрозы. Часть 2: негативные последствия, угрозы, техники

    Александр Демидов 08.11.2019
    Предыдущая статья Лабиринт малотавра: ОУД4 для банковских приложений
    Следующая статья Профиль защиты автоматизированных банковских систем и приложений
    Комментировать

    Добавить комментарий Отменить ответ

    Ваш адрес email не будет опубликован. Обязательные поля помечены *

    Вас может заинтересовать:

    Вводятся в действие рекомендации по стандартизации Р 1323565.1.043–2022

    4 недели назад

    Вступает в действие ГОСТ Р 70262.1-2022

    4 недели назад

    ИБ для чайника. Часть 1.

    2 года назад

    Лабиринт малотавра: Как мы моделируем угрозы. Часть 3: техники и тактики

    3 года назад

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

    Все данные на сайте представлены для ознакомления и носят исключительно информационный характер. Администрация сайта не несёт ответственность за использование размещённой на сайте информации.

    Сайт не является СМИ.

    Top.Mail.Ru

    © Ассоциация специалистов по информационной безопасности в сфере здравоохранения

    Removed from reading list

    Undo
    Go to mobile version
    С возвращением!

    Авторизуйтесь для продолжения

    Забыли пароль?