И. Соммервилл - Инженерия программного обеспечения (1133538), страница 92
Текст из файла (страница 92)
3. Огутаничение носеедемвий. Система разрабатывается так, чтобы свестн последствия опасностей к минимуму. Обычно разработчики систем, критических по обеспечению безопасности, используют комбинацию этих подходов. Например, в случае обнаружения недопустимых опасностей можно уменьшить вероятности их возникновения и добавить защитные системы, срабатывающие при их возникновении. Рассмотрим ошибки программного обеспечения (см. рис.
17.з), приводящие к опасно. стям в системе инъекций инсулина. 1. Арифлтежичегкая ошибка. Она определяется как некоторое арифметическое вычисление, которое яваястсл причиной отказа системы. В спецификации требований должны быть определены все возможные арифметические ошибки, приводящие к Отказэлетропитания Неправнльнособран механизм введения ин- сулина 17.2.4. Уменьшение рисков Средний Минимально допустима Средний Мнпииальпо допустима Средний Минимально допусти ма Низкий Допустима 17.
Спецификации критических систем 357 отказу системы. Они, конечно, зависят от используемых алгоритмов вычислений. В спецификации должен быть указан обработчик исключительных ситуаций для всех идентифицированных арифметических ошибок. В спецификации также описываются действия, которые необходимо предпринять в случае возникновения каждой из этих ошибок. При возникновении ошибок система доллсна остановиться и включить аварийную сигнализацию. 2. Алэедияккическал оыибкк Это более сложная ошибка, так как аномальную ситуацию трудно обнаружить. Ее можно было бы обнаружить, сравнивая требующуюся дозу инсулина с дозой, рассчитанной заранее.
Если доза велика, то вто значит, что она вычислена неправильно. Система может тшоке следить за последовательностью доз. Если число введенных доз выше среднего, то может быть выдано предупреждение и ограничена дальнейшая дозировка. Для определения возможных проблем оборудования используется дерево отказов. Это помогает понять требования к программному обеспечению для выявления и, возможно.
исправления потенциальных проблем. Например, инсулиновые дозы не назначаются с большой частотой: не больше двух или трех раз в час, а иногда и меньше этого. Поэтому необходимы диагностические и управляющие программы. Ошибки оборудования (датчика, насоса или таймера) должны быть обнаружены, а предупреждения выданы еще до того, как они серьезно повлияют на пациента, Некоторые требования безопасности для сйсгемы инъекций инсулина приведены во врезке 17.1. Они являются пользовательскими требованиями и, конечно, должны быть детализированы в заключительной системной спецификации, Табл. 3 и 4, на которые есть ссылки в требованиях, должны быть включены в документ спецификации. безопасности дйя системы иньекций йнсулийа ...
'.; ~~ должна превышать миинмалышй дозы;;ойределенной для. ~ не'должна йреееышаг ' слгэйцжшй иэзы'; опредеуюнйой дйя диагностичесмш оборудоеаййе'не менее 4 раз в:чао -' . -„-. работчик исключений,'определенный й табл. 3 "' " неисправности аборудоеания должен заучщь зеукоеой.сйг-, тическое сообщение, определенное е табл. 4 . ' 17.3. Специфицирование требований защищенности Спецификация требований защищенности имеет много общего с требованиями безопасно. сти. Требования защищенности также трудно определить количественно, часто зто требова. ния "не делать", т,е.
они определяют недопустимое поведение системы, а не ее функциональные возможности. Однако есть и важные различия между этими типами требований. 1. Безопасный жизненный цикл ПО, который охватывает все аспекты управления безопасностью, разработан. Аналогичный жизненный цикл для управления защищенностью программных систем пока не разработан. 358 Масть 1т'. аьритические системы 2.
Набор угроз защищенности в системах довольно обобщенный. Все системы должны защищать себя от вторженил, от отказов в обслуживании и т.д. В противоположность этому опасности в системах, критических по обеспечению безопасности, обычно очень конкретны. 3. Методы и технологии защищенности (такие, как шифрование и опознавательные устройства) только появляются. Однако много технологий защищенности было разработано для специализированных систеи (военных и финансовых), и сегодня существуют только проблемы переноса их на системы общего использования. Ме. тоды безопасности программного обеспечения еще представляют предмет исследования. Обычный (не автоматизированный) приближенный анализ защищенности основан на анализе активов (ценностей), которые должны быть защищены, и стоимости органиэации эащн.
щенноспь Поэтому высокая защищенность будет обеспечена для систем в тех областях, где раэмец1епы большие денежные суммы, в противоположносп тем, где суммы ограниченны. Возможный процесс специфицирования требований защищенности показан иа рис. 17.5. Рис.17.5. Сяехифипироэлиш эргбэалний злээищеяности Этот процесс включает несколько этапов. 1. Олределенке и окенхл активее. Определяются активы (данные и программы) и необ.
ходимая степень их защиты. Следует заметить, что степень требуемой защиты зависит от значимости активов, поэтому файловый пароль, например, более важен, чем множество ЫеЬ-страниц. поскольку несанкционированный доступ к паролю может иметь серьезные последствия для системы. 2. Анализ к экгнкл угрээ и Фигкав. Определяются возможные )трозы для защищенности системы и оцениваются риски, связанные с этими угрозами. 3. Расярсдэмякеуг)юх Для каэ~дого актива определяется свой список угроз.
4. Техкалогэчепгкку аиллкэ. Оцениваются возможные технологии защиты и их приме. ннмость против идентифицированных )тров. 17. Спецификация критических систем 359 5. сяецифипироооиио гяробоооний оашициииоояи. Определяются требования к защищен- ности системы. Определение защищенности и управление ею являются сейчас важными областями исследования в инженерии программного обеспечения.
Стандарты для управления защищенностью нзходятсл в развитии (1801 и, вероятно, будут согласованы в течение несколь ких ближайших лет. -'.о:.:;Трвбоешншубеэотазнасти должны быть определены'количественно в спецификации системша ,; .- '*' трабоеавий~ф ;:,чСущесшуют:-.'различнйе "показатели безотказности, например,вероятность опшза, частота отаца,. гагу,'$4средгше. время беэоуказнсй работы,,и работсспшобность, йаибшше подходящий поазатель дгш: Щ',, " южгкретной сисуейй.<йрядяуется а' зависимости от типа системы и области ее применения. Для 1фраЗЛИИНШГ ПсдСйСтвыс ищут ИойоЛЬЗОватЬСя разНЫЕ Шжазатвпн. ,еЯ%Неягургщшшчалоный,тГшбоеания безотаэности могут привести к фунициональным системшом тре- Г -:ф~боваййямч~трпые определят системные функции, способные уменьшить число снаецных оша. ,~;."4~'аов:и аледхгянйелыуо, уяешншь безотказность.
~.о,;-.:.АгализМпасмнсстей.является основой а процессе определения требоэзний безопасности. Систем~~угг4.' ные требоеащш'деланы Формулироваться таким образом, чтобы гарантировать, что ати опасности ~ф9йне прояяятся или,если они произойдут, то не приеедуг к тяжелым последствиям. 1ч'яу"утуднагшз рйаоц'; это процесс оценки вероятности, что опасность приведет к тяжелым последспш-„'ф„-:ям.;,Яйзлйа, рйсков включает определение критических ашснсстей, которых нужно избегать, и г,' ~";::иассифйцщг1уеу риски сагласгю ик серьезности. ~~" -:.;.. Для формулйррвайия требований защищенности необходимо определщь активы, ксторьш должны 'кь';.Х.', быль зшцищаны, а',,тшшш методы и технологии зшцнщенностн, которые будут использованы для $~ф~-.' зшциты,зтих акпгвочв,:, Упражнения 17.1. Почему нелкш использовать показатели безотказности аппаратных средств прн оценке безотказ- ности программных систем? Пронллюстрнруйте стает примером.
17,2. Укккнте подходящие показатели безотказности дпя следующе программных систем. Обоснуйте еаш выбор показателя и оцените его значение. Система контроля эа состоянием пациентов в больнице. ° Текстовый процессор. ° Автоматическая система управления торговым автоматом. ° Система торможения а автомобиле. ° Система управления холодильником.
° Генератор отчетов. 17.3. Допустим, что аы ошетственны эа написание спецификации программной системы, управляющей сетью кассовых терминапоя а магазине. Система принимает от терминала информацию, считанную с полосы штрихового кода, обращается в базу данных товаров н возвращает на терминал для отображения наименование товара и его цену, Система должна быть постоянно работоспособна з течение рабочего времени магазина. ЗБО класть зч.
Критические системы Выберите подходящий показатель безотказности дпя такой системы и напишите спецификацию требований безотказности, принимая вс внимание, что возможные системные отказы и сбои имеют рззную знзчимость. 17.4. Укажите четыре функциональных требования дпя системы кассовых терминалов, которые могли бы повысить безотказность системы. 17.Б. Объясните, почему границы в треугольнике риска, показанном на рис.
17,4, изменяются со временем в соответствии с изменением социальных ориентиров. 17.Б, В системе иньекцнй инсулина пользователь мозат управлять заменой иглы и частотой иньекций, также может мемть максимальную разовую дозу и максимальную вхадневную дозу. Назовите три ошибки пользователя, которые могут произойти, и определите меры безопасности, которые позволят набежать ошибок, приводящих к несчастному случаю. 17.7.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
