Сообщений в теме: 13

[Green]

Коллеги,
использует ли кто-нибудь в своей практике тестирование разрабатываемого приложения на безопасность?

Интересуют следующие вопросы:
- какие проекты (web, desktop)?
- что тестируете?
- какие тулы используете?

Заранее благодарен.

[Yarilo]

Привет!

На безопасность тестируем web проекты (шифрование паролей). Также, если для клиент-серверного приложения было требование шифрования данных при передаче, то тоже тестируется (разработчиками).

Если приложение (любого типа) поддерживает права на объекты данных и (или) назначение прав пользователям/группам, то и этот аспект тестируется. Правда, это скорее функциональное тестирование, на мой взгляд...

[van]

Коллеги,
использует ли кто-нибудь в своей практике тестирование разрабатываемого приложения на безопасность?

Что именно подразумевается под безопасностью в Вашем случае?

[Green]

Коллеги,
использует ли кто-нибудь в своей практике тестирование разрабатываемого приложения на безопасность?

Что именно подразумевается под безопасностью в Вашем случае?

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

Здесь имеется ввиду, что разрабатываемая программа имеет некий интерфейс, доступный извне. Для web приложений таких два: пользовательский интерфейс на клиенте и web интерфейс серверной части. Каждый из них имеет свои слабые стороны и может быть использоват для атаки на приложение (не систему).

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

[Green]

Привет!

На безопасность тестируем web проекты (шифрование паролей). Также, если для клиент-серверного приложения было требование шифрования данных при передаче, то тоже тестируется (разработчиками).

Yarilo,

Не могли бы Вы рассказать поподробнее как Вы это делаете?
Методика, тулы, проблемы?

Спасибо.

[van]

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

[Spy]

В данный момент проводим аудит информационной безопасности Автоматизированной системы учёта бланков строгой отчётности.

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

• экспертная оценка качества реализации криптографических программных средств (наличие сертификатов у программных средств, наличие лицензии у разработчика, наличие и содержание договора о доверии в использовании криптографических средств между разработчиком и заказчиком);
• экспертная оценка защищённости центральной вычислительной системы;

Для тестирования ПО я пытался использовать предварительный государственный стандарт Республики Беларусь СТБ П 34.101.5-2003 Информационные технологии и безопасность. Общая методология испытаний продуктов и систем информационных технологий на соответствие уровням гарантии. С основан на международном документе CEM-97/017 Common Methodology for Information Technology Security Evaluation. Part I. Introduction and general model. Version 006, 1997 и CEM-99/008 Common Methodology for Information Technology Security Evaluation. Part II. Evaluation Methodology. Version 0.6, January 1999. Есть как успехи, так и проблемы.

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

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

[Green]

to Spy

Я подхожу к проблеме с другой позиции.

Мы создаем приложение. Оно само по себе может иметь уязвимости. Необходимо их обнаружить и устранить. Для выполнения задачи надо протестировать приложение на известные уязвимости. Для многих технологий они известны на 90% - 99% (я не имею ввиду уязвимости используемого стороннего ПО, такого как ОС, web servers и т.п.).

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

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

[Spy]

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

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

Здесь имеется ввиду, что разрабатываемая программа имеет некий интерфейс, доступный извне. Для web приложений таких два: пользовательский интерфейс на клиенте и web интерфейс серверной части. Каждый из них имеет свои слабые стороны и может быть использоват для атаки на приложение (не систему).

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

[Spy]

В целом аспектов больше...

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

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

Короче у вас должен быть подробно расписан весь набор ВСЕвозможных способов использования вашего ПО, а также какого рода информация в ней циркулирует. Лучше всего для этого использовать подход на базе международного стандарта "Общих критеририев", этот стандарт принят в качестве национальных в более чем 20 стран, в том числе РФ и Республика Беларусь.

[Spy]

По сути, это разновидность функционального тестирования

Вот кстати, возвращаясь к тем самым "Общим критериям", там есть такие понятия как уровень гарантии оценки (терминология используется в соответствии с белорусским переводом СТБ 34.101.1-3), так вот только самый нижний уровень

УГО1 - функционально тестированный, а вот все последующие уровни уже будут по-круче:
УГО2 - структурно тестированный
УГО3 - методически тестированный и проверенный
УГО4 - методически спроектированный, тестированный и пересмотренный
УГО5 - полуформально спроектированный и тестированный
УГО6 - полуформально верифицированный проект и тестированный
УГО7 - формально верифицированный проект и тестированный

за подробностями в стандарт и в статьи, что я постил в моей ветке форума.

[Green]

Спасибо Spy.
Чувствуется, что у Вас "рука набита".

[Spy]

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

А подобный интерес - ваша собственная инициатива или требование заказчика?
От вас требуется подтвердить качество защиты?

[Green]

А подобный интерес - ваша собственная инициатива или требование заказчика?
От вас требуется подтвердить качество защиты?

Это глобальная программа в Делл.

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

Что касается Европы...
У нас сейчас идет специализированный тренинг по секьюрити для системных архитекторов. Лектор из F1 (ведущей европейской обучающей компании) сказал, что Делл одна из нескольких компаний в Европе, кто имеет программу по секьюрити.
:rolleyes: (немного рекламы)

Так что могу рекомендовать все тестировщикам специализироваться в этой области. Очень перспективная, а специалистов нет. За три месяца поисков как в России, так и в Ирландии и Англии ни один из кандидатов не дошел до стадии интервью.
:(