 |
Оценивание защищенности ПО
|
|
|
|
В настоящее время оценивание защищенности системы приобретает большое значение, поскольку все чаще системы объединяются посредством Internet. Как уже отмечалось в главе 16, требования защищенности в некоторых отношениях подобны требованиям безопасности. В частности, они определяют нештатное поведение системы, а не ее "рабочее" поведение. Однако, как правило, невозможно определить это поведение в виде простых ограничений, контролируемых системой.
Основное отличие междубезопасностью и защищенностью состоит в том, что проблемы безопасности обычно имеют случайный характер, в то время как атаки на защищенность системы совершаются преднамеренно. Даже в тех системах, которые используются уже много лет, изобретательный взломщик может найти новый способ проникнуть в систему, которая до сих пор считалась защищенной. Например, долгое время считавшийся безопасным алгоритм шифрования данных RSA был взломан в 1999 году.
Существует четыре дополняющих друг друга метода проверки защищенности.
1. Аттестация, основанная на предыдущем опыте. Здесь система анализируется по отношению к различным типам атак, известных группе аттестации. Данный тип аттестации обычно проводится совместно с аттестацией, выполняемой инструментальными средствами.
2. Аттестация инструментальными средствами. Здесь для анализа системы используются разные инструменты защищенности, например программа проверки паролей. Данный метод дополняет аттестацию, основанную на предыдущем опыте.
3. Команда взлома. Команда ставит перед собой цель – взломать систему разными способами. Например, моделируются атаки на систему.
4. Формальная верификация. Выполняется проверка системы на соответствие формальной спецификации защищенности. Этот метод не имеет широкого применения.
|
|
|
Конечным пользователям очень сложно проверить защищенность системы. Поэтому в Северной Америке и Европе выработаны системы критериев оценки защищенности, которые контролируются специально обученными экспертами [131]. Поставщики готового ПО могут представить на рассмотрение свои конечные продукты для оценки и сертификации по различным критериям защищенности.
КЛЮЧЕВЫЕ ПОНЯТИЯ
• Из-за высокой стоимости последствий отказов в критических системах такие методы верификации и аттестации, как формальная спецификация и доказательства, требующие значительных расходов, могут оказаться рентабельными для критических систем.
• Статистическое тестирование применяется для оценки безотказности ПО. При этом проводится тестирование системы с наборами тестовых данных, соответствующими операционным профилям данного ПО. Генерация тестовых данных может быть автоматизирована.
• Модели возрастания безотказности моделируют изменения безотказности в процессе тестирования по мере исправления ошибок в ПО. Модели возрастания безотказности можно использовать для оценивания момента достижения необходимой безотказности и завершения тестирования ПО.
• Доказательство безопасности является эффективным методом оценивания надежности готового продукта. В ходе доказательства демонстрируется невозможность возникновения отказов в системе. Обычно доказательство безопасности проще, чем доказательство соответствия программы своей спецификации.
• Аттестацию защищенности можно провести методом анализа, основанного на предыдущем опыте, с помощью инструментальных средств или с помощью команды, имитирующей атаки на систему.
Упражнения
21.1. Проведите аттестацию по спецификации безотказности для программной системы, управляющей сетью кассовых терминалов в магазине, описанной в упражнении 17.3. Опишите все методы и средства, которые использовались в процессе аттестации.
|
|
|
21.2. Объясните, почему практически невозможно проверить безотказность системы, если требование безотказности определено как малое число отказов за время работы системы.
21.3. Этично ли поведение разработчика, который соглашается поставить заказчику программную систему с известными дефектами? Этично ли его поведение, если в данной ситуации он заблаговременно предупредит заказчика о наличии в системе ошибок? Разумно ли заявлять о безотказности системы в таких обстоятельствах?
21.4. Объясните, почему обеспечение безотказности системы не гарантирует безопасность системы.
21.5. Система управления дверным замком в системе хранения радиоактивных отходов спроектирована с учетом безопасности обслуживающего персонала. Вход в хранилище разрешен, только когда установлены защитные экраны или если уровень радиации в хранилище ниже некоторого установленного значения (dangerLevel). Итак:
• если контролируемые на расстоянии защитные экраны установлены, зарегистрированный оператор может открыть дверь;
• если уровень радиоактивности меньше некоторого определенного значения, зарегистрированный оператор может открыть дверь;
• регистрация оператора определяется посредством ввода им личного входного кода.
Программный код на языке Java, используемый для управления механизмом дверного замка, представлен в листинге 21.3. Заметим, что безопасное состояние состоит в том, чтобы не разрешить вход в хранилище, если не выполнены перечисленные выше условия.
Покажите, что код в листинге 21.3 потенциально небезопасный. Измените его так, чтобы он стал безопасным.
21.6. Используя спецификацию вычисления дозы в системе управления инъекцией инсулина (см. главу 9, рис. 9.10), по аналогии с программой из листинга 21.1 напишите на языке Java код метода computelnsulin. Постройте неформальное доказательство безопасности этого кода.
21.7. Опишите, как вы проводите аттестацию системы защиты с помощью паролей для разработанных вами приложений. Объясните назначение и применение любого инструментального средства, которое, на ваш взгляд, может оказаться полезным.
|
|
|
21.8. Предположим, что вы представитель группы разработчиков программного обеспечения для химического завода, работа которого вызывает серьезное загрязнение окружающей среды. Ваш руководитель во время интервью на телевидении заявил, что процесс аттестации программной системы всесторонний и ошибок в ней быть не может. Далее он сообщил, что проблемы возникают вследствие неправильных действий операторов, обслуживающих систему. Системные операторы не согласны с такими заявлениями и предлагают бастовать. Как вы будете действовать в сложившейся ситуации?
Листинг 21.3. Управление дверным замком
entryCode = lock.getEntryCode();
if(entryCode == lock.authorisedCode)
{
shieldStatus = Shield.getStatus();
radiationLevel = RadSensor.get();
if(radiationLevel < dangerLevel)
state = safe;
else
state = unsafe;
if(shieldStatus == Shield.inPlace())
state = safe;
if(state == safe)
{
Door.locked = false;
Door.unlock();
}
else
{
Door.lock();
Door.locked = true;
}
}
|
|
|
Вычисление параметров эмпирических распределений. Точечное оценивание
Оценивание безотказности
Оценивание интерфейса
Оценивание наследуемых систем
Оценивание неисключенной систематической погрешности и стандартной неопределенности, оцениваемой по типу В, результата измерения
Оценивание ответов обучающихся по предмету «Окружающий мир»
Оценивание тестовых работ
Оценивание уровня развития
Проверка экзаменационной работы и оценивание результатов ГВЭ-9 по русскому языку
