1. Тестирование безопасности
1. Метод тестирования безопасности
Методы тестирования могут быть использованы для тестирования безопасности.В настоящее время основными методами тестирования безопасности являются:
1) Тестирование безопасности статического кода
В основном за счет проверки безопасности исходного кода в соответствии с потоком данных, потоком управления, семантикой и другой информацией в программе и ее уникальной базой правил безопасности программного обеспечения, чтобы обнаружить потенциальные лазейки безопасности в коде.
Статическое тестирование безопасности исходного кода — очень полезный метод для выявления всех возможных угроз безопасности на этапе кодирования, чтобы разработчики могли устранять потенциальные проблемы безопасности на ранней стадии. Из-за этого статическое тестирование кода больше подходит для ранних стадий разработки кода, а не для тестирования.
2) Динамическое тестирование на проникновение
Тестирование на проникновение также является широко используемым методом тестирования безопасности. Он заключается в использовании автоматизированных инструментов или ручных методов для имитации действий хакеров, проведения наступательных тестов в системе приложений и выявления лазеек в системе безопасности, существующих во время выполнения.
Характерной чертой этого теста является то, что он реален и эффективен, а обнаруженные проблемы в целом правильные и серьезные. Но фатальным недостатком тестирования на проникновение является то, что смоделированные тестовые данные могут достигать только ограниченного количества контрольных точек, а степень охвата очень низкая.
3) Сканирование данных программы
Для ПО с повышенными требованиями к безопасности нельзя уничтожать данные во время работы, иначе это приведет к атакам типа переполнения буфера. Средством сканирования данных обычно является тестирование памяти.Тестирование памяти может найти множество уязвимостей, таких как переполнение буфера, которые трудно найти с помощью других методов тестирования.
Например, сканировать информацию о памяти во время работы программы, чтобы увидеть, нет ли там какой-либо информации, которая может привести к скрытым опасностям.Конечно, это требует специальных инструментов для проверки, и вручную это сделать сложно.
2. Обратный процесс тестирования безопасности
Тестирование безопасности большинства программ осуществляется по принципу обратного проектирования дефектного пространства, то есть заранее проверить, где могут быть угрозы безопасности, а затем протестировать эти возможные скрытые опасности.
Таким образом, процесс обратного тестирования начинается с дефектного пространства, устанавливает дефектную модель угроз, находит точку вторжения с помощью модели угроз, а также сканирует и тестирует известные уязвимости точки вторжения. Преимущество состоит в том, что известные дефекты могут быть проанализированы, чтобы избежать известных типов дефектов в программном обеспечении, но они, как правило, бессильны против неизвестных методов и методов атаки.
1) Создать модель угрозы дефекта
Создание модели угроз дефектов в основном начинается с известных уязвимостей безопасности и проверяет, есть ли известные уязвимости в программном обеспечении. При создании модели угроз необходимо сначала определить, какие профессиональные области задействованы в программном обеспечении, а затем смоделировать в соответствии с методами атак, встречающимися в каждой профессиональной области.
2) Найдите и просканируйте точки проникновения
Проверьте, какие недостатки в модели угроз могут возникнуть в этом программном обеспечении, а затем включите возможные угрозы в матрицу точек вторжения для управления. Если имеется зрелое средство сканирования уязвимостей, используйте средство сканирования уязвимостей для непосредственного сканирования, а затем включайте обнаруженные подозрительные проблемы в матрицу точек вторжений для управления.
3) Проверка матрицы вторжений
После создания матрицы вторжений соответствующие тестовые примеры могут быть разработаны в соответствии с конкретными элементами матрицы вторжений, а затем может быть проведена тестовая проверка.
3. Процесс прямого тестирования безопасности
Чтобы избежать неполноты теста, вызванной принципом обратного проектирования, необходим метод прямого тестирования для относительно полного тестирования программного обеспечения, чтобы тестируемое программное обеспечение могло предотвратить неизвестные методы и методы атаки.
1) Сначала определите тестовое пространство
Определите все переменные данные в тестовом пространстве.Из-за высокой стоимости тестирования безопасности важно определить внешний входной слой.
Например, этапы анализа требований, эскизного проектирования, детального проектирования и кодирования должны идентифицировать тестовое пространство и установить матрицу отслеживания тестового пространства.
2) Точно определить пространство дизайна
Сосредоточьтесь на проверке того, четко ли определено пространство проектирования в требованиях, и определили ли данные, включенные в требования, допустимый диапазон значений.
На этом этапе самое важное, на что следует обратить внимание, — это точное слово, и пространство дизайна должно быть точно определено в строгом соответствии с принципом безопасности.
3) Определите потенциальные угрозы безопасности
В соответствии с найденным тестовым пространством и пространством дизайна и правилами преобразования между ними определите, какое тестовое пространство и какие правила преобразования могут иметь риски безопасности.
Например, чем сложнее тестовое пространство, т. е. чем сложнее тестовое пространство разделено или чем более изменчивы отношения комбинации данных, тем оно менее безопасно. Кроме того, чем сложнее правила преобразования, тем выше вероятность возникновения проблем, которые представляют собой угрозу безопасности.
4) Создайте и проверьте матрицу вторжений
После того, как идентификация угроз безопасности завершена, можно составить матрицу вторжений в соответствии с выявленными угрозами безопасности. Перечислите потенциальные угрозы безопасности, определите переменные данные, которые имеют потенциальные угрозы безопасности, и определите уровень угроз безопасности. Среди них для тех переменных данных с высоким уровнем риска безопасности должен быть выполнен подробный тестовый сценарий.
4. Разница между прямым и обратным тестированиемПроцесс прямого тестирования основан на пространстве тестирования для поиска дефектов и уязвимостей.
Процесс обратного тестирования основан на известном пространстве дефектов, чтобы определить, будут ли в программном обеспечении возникать те же дефекты и уязвимости, которые имеют свои преимущества и недостатки.
1) Форвард тест
Преимущество процесса в том, что теста относительно достаточно, но рабочая нагрузка относительно велика. Поэтому ПО с низкими требованиями к безопасности, как правило, можно тестировать по обратному процессу тестирования, для ПО с высокими требованиями к безопасности процесс прямого тестирования должен быть основным процессом, а процесс обратного тестирования должен дополняться.
2) Обратный тест
Одним из основных преимуществ этого процесса является низкая стоимость при условии, что известные дефекты, которые могут возникнуть, могут быть проверены, но недостатком является то, что тест не идеален, тестовое пространство не может быть полностью покрыто и неизвестная атака методы не могут быть найдены.
2. Распространенные недостатки и уязвимости безопасности программного обеспечения
Существует много аспектов безопасности программного обеспечения.Основные проблемы безопасности вызваны уязвимостями самого программного обеспечения.Ниже представлены распространенные дефекты и уязвимости безопасности программного обеспечения.
1. Переполнение буфера
Переполнение буфера стало общедоступным врагом номер один в области безопасности программного обеспечения, и многие реальные проблемы безопасности связаны с ним. Обычно есть две причины проблем с переполнением буфера.
1) Проблема верификации правил преобразования проектного пространства
То есть отсутствие проверки измеримых данных приводит к тому, что недопустимые данные не проверяются и отбрасываются во внешнем входном слое. После того, как недопустимые данные попадут на интерфейсный уровень и уровень реализации, это вызовет переполнение, так как превысит соответствующее тестовое пространство или пространство проектирования интерфейсного уровня и уровня реализации.
2) Недостаточное локальное тестовое пространство и пространство для проектирования
Когда вводятся юридические данные, происходит переполнение программы из-за нехватки пространства для тестирования или дизайна на уровне реализации программы.
2. Слабые стороны шифрования
Эти криптографические слабости небезопасны:
1) Используйте небезопасные алгоритмы шифрования. Силы алгоритма шифрования недостаточно, а некоторые алгоритмы шифрования можно даже взломать методом грубой силы.
2) При шифровании данных пароль генерируется по псевдослучайному алгоритму, а метод генерации псевдослучайных чисел несовершенен, что позволяет легко взломать пароль.
3) Алгоритм аутентификации недостаточно.
4) Часы клиента и сервера не синхронизированы, что дает злоумышленнику достаточно времени, чтобы взломать пароль или изменить данные.
5) Зашифрованные данные не подписаны, что позволяет злоумышленникам подделывать данные. Поэтому при тестировании шифрования необходимо проверить эти возможные недостатки шифрования.
3. Обработка ошибок
В обычных условиях обработка ошибок возвращает пользователю некоторую информацию. Возвращенная информация об ошибке может быть использована злоумышленниками для атаки. Злоумышленники могут проанализировать возвращенную информацию об ошибке, чтобы узнать, что делать дальше, чтобы атака была успешной.
Если обработка ошибок вызывает некоторые функции, которых там быть не должно, то будет использоваться процесс обработки ошибок. Обработка ошибок — это проблема обработки в пространстве исключений.Обработка в пространстве исключений должна быть максимально простой.Использование этого принципа проектирования позволяет избежать этой проблемы.
Однако обработка ошибок часто связана с проблемами удобства использования.Если подсказки по обработке ошибок слишком просты, пользователи могут растеряться и не знать, что делать дальше. Следовательно, при рассмотрении безопасности обработки ошибок ее необходимо сопоставить с простотой использования.
4. Чрезмерная властьЕсли предоставлено слишком много полномочий, это может привести к тому, что злоумышленники, имеющие только права обычного пользователя, будут использовать слишком много полномочий для выполнения операций, угрожающих безопасности.
Например, отсутствие ограничений на то, чем можно манипулировать, может привести к тому, что пользователи получат доступ к другим ресурсам за пределами указанной области. При проведении тестирования безопасности необходимо проверить, не использует ли приложение избыточные разрешения, сосредоточив внимание на анализе разрешений, которые должны быть доступны в различных ситуациях, а затем проверить, действительно ли данные разрешения превышены. Проблема чрезмерных полномочий — это, по сути, проблема чрезмерного пространства дизайна, поэтому необходимо контролировать пространство дизайна во время проектирования, чтобы избежать проблемы чрезмерных полномочий, вызванной чрезмерным пространством дизайна.
3. Рекомендации по качественному тестированию безопасности
Многие опыты тестирования безопасности программного обеспечения говорят нам о том, что необходимыми условиями для хорошего тестирования безопасности программного обеспечения являются:
1. Полностью понимать уязвимости безопасности программного обеспечения
Оценка степени безопасности программной системы должна начинаться одновременно с трех звеньев проектирования, реализации и развертывания. Давайте начнем с того, как Common Criteria оценивает безопасность программных систем.
Сначала определите профиль защиты (PP), соответствующий программному продукту. ПЗ определяет шаблон функции безопасности для класса программных продуктов.
Например: ПП базы данных, ПП брандмауэра и т.д. Затем, в соответствии с PP, выдвигаются конкретные требования к функции безопасности, такие как реализация аутентификации пользователя. Наконец, определите объект безопасности и то, как выполнить соответствующие требования функции безопасности. Следовательно, ни одно из трех звеньев защитного программного обеспечения не выйдет из строя.
2. Оценка тестирования безопасностиКогда тестирование безопасности завершено, может ли программное обеспечение достичь ожидаемого уровня безопасности? Это наиболее волнующий вопрос тестировщиков безопасности, поэтому необходимо установить механизм оценки безопасности после тестирования. Обычно он оценивается по следующим двум аспектам.
1) Оценка данных о дефектах безопасностиЧем больше недостатков безопасности и уязвимостей обнаружено в программном обеспечении, тем больше недостатков может остаться позади. При проведении этого типа оценки исходные данные должны быть установлены в качестве справочных, иначе оценка не сможет сделать правильный вывод без основы.
2) Использовать имплантацию уязвимостей для оценки
Метод имплантации уязвимости и тест вставки неисправностей в тесте на надежность одинаковы, но вот некоторые проблемы с рисками безопасности, вставленные в программное обеспечение. При использовании метода имплантации уязвимости, сначала пусть конкретный персонал, который не участвует в испытании на безопасность предварительно имплантат определенное количество уязвимостей в программном обеспечении, и, наконец, посмотрите, сколько имплантированных уязвимостей обнаруживаются после завершения теста, чтобы оценить Тест безопасности программного обеспечения. Будь то достаточным.3) использование методов и инструментов тестирования безопасности
Профессиональное программное обеспечение для сканирования системы безопасности с определенными функциями можно использовать для поиска потенциальных уязвимостей, включения возникших дефектов в библиотеку дефектов, а затем использовать автоматизированную библиотеку дефектов для бомбардировочного тестирования с помощью автоматизированных методов тестирования.
Например, используйте какое-нибудь программное обеспечение, которое может имитировать различные атаки для тестирования.
Тестирование безопасности используется для проверки того, действительно ли механизмы защиты, встроенные в программное обеспечение, могут защитить систему от незаконного вторжения. Популярная поговорка: безопасность программной системы, конечно же, должна быть в состоянии противостоять лобовым атакам, но она также должна быть в состоянии противостоять боковым и тыловым атакам.