Цель защиты

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

На консультации у юриста ...

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

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

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

Определение типа защиты от вирусов

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

Перемещаемые программы

Перемещаемые программы

Новая запись, появившаяся в перечне вопросов к руководству, названному "Часто задаваемые вопросы" (Frequently Asked Questions), — "Что такое перемещаемая программа?". Концепция перемещаемых программ появилась, когда компания Sun разработала язык Java и операционную среду для него. Она заключается в написании одной единственной программы, которая будет работать, где угодно. Путем создания перемещаемых программ, которые загружаются с сетевого сервера, такого как Web-сервер, решена задача, когда одна программа может быть отправлена на любую систему и будет в ней работать.
В настоящее время самое распространенное использование перемещаемых программ в Internet для повышения технического уровня пользователя при работе с Web-узлом. Но принцип перемещаемых программ можно использовать для доставки любых типов приложений, в том числе вирусов и другой гадости.

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

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

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

Правила эксплуатации стороннего программного обеспечения

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

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

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

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

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

Предостережение от традиционного подхода к защите от вирусов

Предостережение от традиционного подхода к защите от вирусов
Традиционный подход к защите от вирусов заключается в том, чтобы заниматься только проблемами, возникающими в системах, построенных на платформах Windows различных версий, или в других приложениях, разработанных компанией Microsoft. Однако, проблемы с вирусами возникают и в других системах независимо от того, на какой операционной системе они базируются. Вирусы, которые появляются в определенных приложениях, могут инфицировать любую систему, в которой эти приложения запускаются. Одним из примеров является система Lotus Notes, которая может распространять вирусы на серверы UNIX, запускающие сервер Notes, но также и в том случае, когда запускается Windows NT. Существуют даже "неудаляемые" (proof-of-concept) вирусы для устройств, работающих в PalmOS.
Если организация работает с межплатформными приложениями, то правила должны требовать защиту всех платформ, а не только систем, работающих в Windows.

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

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

Привлечение пользователей к защите от вирусов

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

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

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

Проверка целостности системы

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

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

Распределенные и съемные носители

Другой сложной областью при разработке правил можно считать защиту не часто используемых устройств или съемных носителей. Свойства и тех, и других меняются, поскольку кто-нибудь может снять диск, ленту или любой носитель, на котором хранятся данные, и установить их на другую систему. Пользователь также может переносить вирусы с одной системы на другую.

Трудность разработки правил заключается в том, что различные системы выдвигают различные требования к съемным носителям. Например, система на основе UNIX имеет не такие требования к сканированию, как система на базе Windows. Однако, мы не можем быть уверены в том, что компакт-диск, записанный в системе UNIX не инфицирует систему Windows.

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

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

и компьютеры, не только обходятся

Резюме

Вирусы, "черви" и "троянские кони", которые инфицируют сети и компьютеры, не только обходятся организациям "в копеечку", но и снижают объем производства, который может в дальнейшем и не быть компенсирован. Правила защиты от вирусов могут устанавливать требование для всех пользователей защищать ценные данные организации.
1. Цель защиты. Иногда из соображений, выдвинутых юридической практикой, в правила безопасности достаточно включить формулировку, устанавливающую только требование защиты от вирусов, причем средства защиты должны использоваться исключительно по своему назначению. Другая формулировка должна включать указание пользователю использовать для антивирусной защиты только утвержденные средства и никакими действиями не препятствовать их применению. 2. Определение типа защиты от вирусов. В правилах защиты от вирусов должен быть отражен подход к антивирусной защите, но необязательно сам программный продукт. В правилах необходимо связать принцип сканирования с используемой для этого программой. Это делается для обеспечения полной открытости информации в случае судебных дел. Для определения программы защиты от вирусов необходимо составить формулировку правил, охватывающую следующие вопросы: подход к тестированию на вирусы; проверка целостности системы; проверка распределенных или автономных средств. 3. Правила эксплуатации стороннего программного обеспечения. Несмотря на то, что это происходит довольно редко, все же бывают случаи, когда поставщики теряют бдительность и распространяют зараженные вирусом свои программы. Можно разработать правила, предписывающие особый режим эксплуатации стороннего программного обеспечения. В правилах может быть предписано, чтобы стороннее программное обеспечение перед загрузкой их на другие системы устанавливалось на испытательную систему и проверялось. 4. Привлечение пользователей к защите от вирусов. Организация не хочет, чтобы ее пользователи имели какое-то отношение к вирусам. Это может плохо повлиять на выполнение задач организации. Данные правила должны жестко требовать, чтобы пользователь не имел никакого отношения к вирусам. Чтобы сделать формулировку правил более жесткой, в некоторых организациях добавляют в нее положение о дисциплинарных взысканиях, включающих увольнение и передачу дел правоохранительным органам.

Тестирование на вирусы

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

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

Вирусы "черви" и "троянские кони"

Вирусы, "черви" и "троянские кони"

Не проходит и недели без слухов о новых вирусах, "червях" и "троянских конях", которые инфицировали сети или компьютеры. Решение этих проблем не только требует немалых денежных затрат, но и чревато снижением объема производства, который может в дальнейшем и не быть компенсирован. Несмотря на то, что эти проблемы в первую очередь влияют на определенный тип операционной системы и программное обеспечение определенного поставщика, не существует операционных систем, которые давали бы полную гарантию защищенности от вирусов. Следует помнить, что первый известный "червь" был запущен в 1988 году и предназначался для атаки систем Digital VAX и Sun System, работавших под управлением одной из версий UNIX.

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

Федеральные стандарты криптографии

Федеральные стандарты криптографии
Для организаций не оборонного и не разведывательного профиля все технические стандарты для федеральных компьютерных систем устанавливаются в документах федеральных стандартов по обработке информации (FIPS — Federal Information Processing Standard). Национальный институт стандартов и технологий (NIST — National Institute of Standards and Technology) conpoвождает эту документацию, а также является высшей инстанцией при работе с федеральной документацией. Федеральные стандарты криптографии входят как составная часть в издание FIPS 140-2, а последняя поправка была проведена в июне 2001 года (при написании этой книги). В приложении Б представлено больше информации о том, как получить документы издания FIPS 140-2, а также другие документы.

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

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

Если у читателя возникают какие-либо вопросы, то в издании FIPS 140-2 (см. "Федеральные стандарты криптографии") также описываются требования по физической защите устройств криптографии. Несмотря на то, что это требования федерального правительства, они могут применяться и в неправительственной сфере.

Хранение ключей

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

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

Ключи не должны храниться на том же диске, где находятся защищенные данные.

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

Изменения в администрации

Изменения в администрации
Когда писалась эта книга, шел первый год правления Джорджа Буша. До сих пор президент Буш не разрабатывал никаких правительственных постановлений, которые изменили бы проводимую политику в области шифрования. Однако, это не означает, что его администрация не будет заниматься данными вопросами. Ситуация стала еще более проблематичной в результате террористических атак 11 сентября 2001 года. Конгресс начал рассматривать некоторые постановления, которые могли изменить общую политику в отношении шифрования. В организации необходимо иметь кого-то, кто будет отслеживать потенциальные изменения законодательной политики, поскольку эти изменения будут отражаться и на правилах информационной безопасности организации.

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

Эксплуатация криптографических систем и обработка зашифрованных данных

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

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

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

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

Архивные и резервные данные не должны шифроваться. Секретные данные должны храниться в соответствии с предписаниями правил.

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

После шифрования данных все исходные данные нужно удалитъ или необходимо уничтожить носители, на которых они записаны. Оперативная и внешняя память, используемые в процессе шифрования, также должны быть тщательно вытерты nocлe завершения работы.

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

Юридические вопросы

Политика США в области использования и распространения криптографии контролируется президентом (статья 22, раздел 2778). До начала бурного развития электронной торговли правила международной торговли оружием (ITAR — International Traffic in Arms Regulations) ограничивали как применение шифрования в Соединенных Штатах, так и экспорт технологий шифрования. Поскольку среда электронной торговли изменилась, на администрацию президента начали оказывать давление с целью добиться изменения политики в данном вопросе. Конгресс поддержал общественное мнение принятием различных указов, смягчающих законодательство в этой области.

Начиная с 1996 года, администрация Клинтона стала смягчать законодательство в этой области. После передачи в декабре 1996 года полномочий проведения этой политики Бюро по экспорту (ВХА) Управления торговли первым достижением стало то, что пользователи смогли загружать Web-броузеры с использованием более мощных средств шифрования. Что касается бизнеса, то необходимы были дальнейшие изменения законодательства для упрощения экспорта криптографических технологий, особенно в тех случаях, когда крупные организации пытались создавать виртуальные частные сети, к которым подключались и заокеанские офисы. Изменения были также необходимы для упрощения лицензирования и процессов предоставления льгот.

Международные правила применения шифрования

Международные вопросы становятся еще более запутанными, когда необходимо разобраться с нормативами "Вассенаарского соглашения" (WA- Wassenaar Arrangement) и с тем, как различные страны применяют на практике эти нормативы. WA является международным многосторонним соглашением, в котором определены меры контроля над экспортом для типов вооружений, ограниченных в ITAR. Переговоры, касающиеся WA, велись среди 33 постоянных членов организации (см. Рисунок 9.1, представляющий список участников), чтобы определить меры контроля над экспортом, за обменом идеями и информацией, а также за распространением технологий по всему миру. Это соглашение, подписанное в 1996 году Координационным комитетом по контролю над экспортом (СОСОМ — Coordinating Committee on Export Controls), является международной рекомендацией для подписавшихся сторон, а не договором.

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

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

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

Пересылка ключей

В любом алгоритме шифрования ключей присутствует функция замены ключей. Открытый ключ или асимметричные технологии шифрования предполагают меньше вопросов, поскольку открытый ключ может пересылаться открыто без того, чтобы беспокоиться о взломе (для получения разъяснений, что такое криптография с открытым ключом, см. главу 6). Открытые ключи используются как часть PKI, и их также можно заменять на основе сертификационных полномочий, которые позволяют не только хранить ключи, но и снабжать их цифровой подписью для проверки их принадлежности.

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

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

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

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

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

Раскрытие ключей

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

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

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

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

Криптографические ключи могут быть раскрыты только по требованию правовых органов.

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

Разъяснение вопросов связанных с шифрованием

Разъяснение вопросов, связанных с шифрованием
Поскольку автор писал книгу на основе собственного опыта, его точка зрения на правила шифрования и законы основывается на том, что он видел в Соединенных Штатах. Даже если читатель живет в Соединенных Штатах, ему следует получить ответы на многие вопросы у юриста, специализирующегося в этой области. Можно также связаться с Бюро по экспорту (Bureau of Export Affairs) в Управлении торговли (Department of Commerce), чтобы получить более подробную информацию. См. Приложение Б "Ресурсы".

Пересылка данных через Internet облегчает

Резюме

Пересылка данных через Internet облегчает решительному взломщику возможность считать эти данные. Единственный способ предотвратить вторжение такого типа заключается в использовании шифрования. Шифрование представляет собой особую технологию, и правительства предпочитают, чтобы рядовые граждане не пользовались ею, поскольку шифрование делает сложным прослушивание пересылаемых вами данных. Все это требует особых соображений во время разработки правил информационной безопасности организации.
1. Юридические вопросы. Правительство Соединенных Штатов и правительства других стран относятся к технологиям шифрования, как к видам вооружения. Поэтому правительства принимают законы для ограничения использования криптографии, а также экспорта криптографических технологий и оборудования. В 1996 году администрация Клинтона стала смягчать законодательство в области криптографии. Полномочия проведения этой политики были переданы в Бюро по экспорту (ВХА). Новый подход к политике изменил общие стандарты применения шифрования, а также упростил лицензирование и процедуры предоставления льгот. Международные законы базируются на постановлениях "Вассенаарского соглашения", многостороннего международного соглашения, в котором определены меры контроля над экспортом для типов вооружений, включая криптографию. Несмотря на то, что решения Вассенаарского соглашения не являются обязательными для исполнения, страны-участники разработали постановления на основе большей части этих рекомендаций. Хотя предполагается, что зашифрованные данные должны быть секретными, правовые органы могут официально получить полномочия исследовать системы организации или контролировать зашифрованные пересылки по сети. Если организация принимает участие в программе изъятия ключей, ключи могут быть восстановлены без участия вашей организации. 2. Управление криптографией. В некоторых организациях требуют, чтобы руководство утверждало применение криптографических средств. В свою очередь руководство возьмет на себя ответственность за выдачу разрешений на использование шифрования только после выяснения всех юридических вопросов. Если организация имеет договор с федеральным правительством, то управление шифрованием должно соответствовать опубликованным государственным стандартам. В правилах могут быть определены методы физического управления аппаратными средствами и программным обеспечением, используемыми в системах шифрования. В некоторые правила физической безопасности входят положения, требующие использование аппаратных средств, защищенных от несанкционированного доступа, возможность физического блокирования, физическую охрану сети, а также защиту хранилища носителей с программными дистрибутивами. 3. Эксплуатация криптографических систем и обработка зашифрованных данных. В правилах, определяющих, когда шифровать данные, можно указать, что данные классифицируются на основе условий их хранения и пересылки. Данные, классифицированные по определенным признакам, должны шифроваться. Можно делать исключения, особенно для носителей с резервными копиями, которые могут иметь сложное управление ключами и непростые процедуры восстановления. В правилах должно быть определено, что после зашифровки данных для предотвращения доступа к ним посторонних лиц данные должны быть полностью удалены или уничтожены физически носители с этими данными. 4. Соображения о генерировании ключей. Одним из самых важных аспектов, касающихся криптографии, является ключ. В криптографии ключ является переменной, которая вводится в алгоритм, применяемый для шифрования данных. Обычно ключ является секретной величиной или несет в себе секретный компонент. Важно обеспечить гарантии того, что ключ остается в секрете. В правилах можно оговорить разработку рабочих инструкций, по которым следует работать, оставляя на усмотрение администраторов разработку соответствующей технологии. В правилах генерирования ключей может идти речь о разрешенных форматах, требованиях по хранению, сроках их действия, а также о секретности программного обеспечения и процедур генерирования ключей. Правила могут предписывать уничтожение всех компонентов, использовавшихся для генерирования ключей, для чего в них должно быть включено требование по перезаписи оперативной памяти и онлайновых запоминающих устройств. Дополнительно в правилах может требоваться уничтожение компонентов памяти на автономных запоминающих устройствах. 5. Управление ключами. Управление ключами представляет собой довольно сложную проблему из-за различий в типах шифрования и стандартах, используемых для различных технологий шифрования. Независимо от используемой технологии шифрования на каком-то этапе ключи должны быть раскрыты. Требования по раскрытию могут основываться на соглашениях о предоставляемых услугах или на требованиях по использованию программного обеспечения или устройств. Можно разработать правила, определяющие, каким образом будут раскрываться ключи, а также определяющие организационные моменты раскрытия ключей или их изъятия. Определенные аспекты хранения ключей контролировать невозможно. Правила хранения ключей могут предписывать, каким образом хранить ключи, как делать резервные копии или обеспечивать их пересылку. Но особенно важно рассмотреть случай хранения ключей на том же устройстве или носителе, где хранятся защищенные данные. Особенности пересылки ключей связаны с используемыми алгоритмами и с тем, является ли сервис пересылок зашифрованной информации сторонним. Открытый ключ или технологии асимметричного шифрования вызывают меньше проблем, поскольку открытый ключ может передаваться открыто, и не нужно беспокоиться о том, что он может быть скомпрометирован. При использовании технологии симметричного шифрования необходимо искать другие альтернативы. Можно разработать общие правила, предписывающие внеполосную пересылку, не вдаваясь в детали ее реализации.

Семь исключений в политике шифрования США

Семь исключений в политике шифрования США
Независимо от того, что законы в отношении экспорта стали очень мягкими, США продолжают проводить политику жестких ограничений экспорта и использования криптографии в отношении тех стран, которые государственный Департамент США считает врагами Соединенных Штатов или поддерживающими терроризм. В список таких стран входят Куба, Иран, Ирак, Ливия, Северная Корея, Сирия и Судан.

Шифрование

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

Шифрование пришло к нам из военной области и области шпионажа и превратилось в технологию, необходимую для защиты пересылок электронных активов. Начиная с виртуальных частных сетей (VPN - Virtual Private Networks) и заканчивая усовершенствованной конфиденциальной электронной почтой, шифрование стало основной технологией, используемой повсеместно.

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

Соображения о генерировании ключей

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

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

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

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

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

Управление ключами

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

Когда возникают вопросы о том, какую использовать технологию, ответ, обычно, заключается в использовании стандартов. Однако, если в организации применяется открытый криптографический ключ и делаются попытки создать инфраструктуру открытого ключа (PKI), то стандарты постоянно меняются, и ответить на этот вопрос сложно. Производители могут предоставлять инструкции, но нужно проявлять осторожность, чтобы эти инструкции не противоречили принятым в организации правилам, потому что это может привести к блокированию собственных решений. Для получения более подробной информации о PKI и связанных с ней правилах см. раздел "Применение PKI и других средств контроля" в главе 6 "Правила безопасности Internet".

Исходя из задач, поставленных политикой безопасности, можно выделить три области, которые необходимо рассмотреть в правилах управления ключами: раскрытие и изъятие ключей, хранение ключей и пересылка ключей. Это, конечно, не полный перечень, но это главные вопросы, с которых необходимо начать разработку правил.

Управление криптографией

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

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

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

Вопросы обязательств

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

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

Дополнительные соображения по поводу правил

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

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

Во всех разработках программного обеспечения необходимо использовать один язык программирования, согласованный на этапе проектирования.

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

Во всех разработках программного обеспечения необходимо рассматривать возможность повторного использования компонентов из других проектов. При разработке программного обеспечения необходимо учитывать возможность повторного использования проекта.

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

Во всех разработках программного обеспечения необходимо использоватъ только полностью доработанные средства разработки и методики.

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

Во всех разработках программного обеспечения должно использоваться единое правило присваивания имен для всех производственных файлов.

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

Генерирование тестовых данных

Много лет назад, находясь в командировке с целью консультации сотрудников одной организации, автор начал работать с группой, отвечающей за тестирование программного обеспечения, разработанного автором. Когда проводившие тестирование специалисты имитировали какие-нибудь проблемы, автор обратил внимание на то, что в используемой тестовой информации присутствуют данные личного характера хорошо известных клиентов этой организации. Увидев несколько знакомых имен, автор поинтересовался, откуда появились эти данные. Группа испытателей призналась, что они для создания тестов извлекли реальные данные из базы данных организации.

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

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

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

Этапы разработки программного обеспечения

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

Область действия правил разработки программного обеспечения

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

Ограничение коммерческого распространения

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

В современном мире Web-технологий сторонние проектировщики рассчитывают, что разработанные ими пакеты программного обеспечения станут основой предлагаемых для продажи услуг. В этом окружении может быть меньше ограничений на перепродажу разработок. Но организация может и не иметь возможности контролировать стороннего разработчика. Эта неопределенность должна быть учтена в правилах организации. Один из вариантов разрабатываемых правил может быть следующим.

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

Определение обязанностей при разработке программного обеспечения

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

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

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

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

Передача программного обеспечения третьей стороне

Как-то автор работал с производителем систем встроенного телекоммуникационного оборудования. Однажды шеф попросил автора создать набор PROMoв (Programmable Read Only Memory— перепрограммируемое постоянное запоминающее устройство, специальные блоки памяти, на которых данные не могут быть вытерты). Затем он захотел, чтобы автор книги распечатал исходники программ, которые хранились на этих PROMax, и отдал их тем, кто передал бы их тому, кто будет их хранить. Автор поинтересовался, зачем это нужно. Оказывается, был запрос от клиента, который беспокоился о том, какие меры необходимо предпринять в случае ликвидации предприятия.

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

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

Следующая формулировка правил была позаимствована у клиента, который являлся разработчиком Web.

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

Правила доступа и HIPAA

Правила доступа и HIPAA
Тот, кто, работая в сфере здравоохранения, сталкивался с изложенными здесь фактами, обнаружит в них немало противоречий с постановлениями Закона страхования здоровья и ответственности за него (NIPAA— Health Insurance Portability and Account ability Act). Несмотря на то, что HIPAA составлен для обеспечения безопасности и конфиденциальности личных данных, с которыми работают в здравоохранительных органах, в нем также имеется постановление, позволяющее практикующим врачам получать доступ к информации пациентов клиники без выяснения личности запрашивающего или его аутентификации. Назначение этого встроенного нелегального входа или средства быстрого доступа, требуемого HIPAA, заключается в том, чтобы получить доступ к секретным данным в экстремальных ситуациях сотрудникам органов здравоохранения.
Несмотря на то, что HIPAA не разъясняет, как разрабатывать правила и процедуры для экстремальных ситуаций, здравоохранительные организации должны руководствоваться не только HIPAA, но и определять в своих правилах баланс между необходимостью предоставления быстрой медицинской помощи и конфиденциальностью этих личных данных.

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

Все средства привилегированного доступа, а также средства управления, встроенные в собственное программное обеспечение, должны соответствовать стандартам на административные средства управления, как это отмечено в правилах и соответствующих директивах.

Правила гарантирующие целостность программного обеспечения

Правила, гарантирующие целостность программного обеспечения

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

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

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

Все программное обеспечение, разработанное сторонними организациями, должно соответствовать установленным стандартам информационной безопасности. Это программное обеспечение должно согласовываться со средствами управления операционной системы или средствами управления программным обеспечением.

Правила разработки программного обеспечения

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

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

Процедуры инсталляции

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

В процедуры управления конфигурацией необходимо включитъ процедуры инсталляции и "отката" к предыдущей версии в случае возникновения проблем.

Процедуры запросов на замену версий

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

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

В правилах не отражены ни конкретные методы выполнения этих работ, ни программное обеспечение, которое может быть использовано в работе. Еще раз напомним, что это относится к деталям реализации.

Разработка программного обеспечения представляет собой

Резюме

Разработка программного обеспечения представляет собой искусство компилирования закодированных инструкций таким образом, чтобы преобразовать их в понятную программу для запуска ее на компьютере. Подобно другим видам искусства, основанным на научных теориях, ошибки и упущения могут привести к катастрофическим результатам. Довольно часто обеспечением безопасности начинают заниматься уже после разработки, что приводит к необходимости применения экстраординарных мер. Включив в правила безопасности организации положения о разработке программного обеспечения, можно избежать последующей доработки программного обеспечения собственными силами, вызванной необходимостью обеспечить безопасность программного обеспечения и систем. Даже если организация не занимается разработкой собственного программного обеспечения, некоторые положения этих правил могут оказаться довольно полезными.
1. Этапы разработки программного обеспечения. Наличие правил разработки программного обеспечения является гарантией того, что вопросы безопасности будут учтены при проектировании и разработке. Правила безопасности, регламентирующие разработку программного обеспечения, должны определять, введение каких обязанностей способствует разработке мер безопасности и корректному использованию программного обеспечения. Введение правил разработки программного обеспечения должно базироваться на трех основных рекомендациях, соблюдение которых, также как и соблюдение правил разработки программного обеспечения, будет способствовать разработке безопасного программного обеспечения: требования разработки спецификаций, контроль и квитовка вводимой пользователем информации и контроль предельных значений данных во время пересылки. Кроме этих основных правил защиты разработки программного обеспечения существуют еще два правила, которые должны помочь предотвратить проблемы с защитой: исключить "лазейки" или любые другие точки доступа, позволяющие обойти защиту программного обеспечения, которые нарушают безопасность, и исключение особых привилегий для разработчиков. Средства управления доступом, встроенные в собственное программное обеспечение, должны соответствовать стандартам на их применение и инструкциям. При проектировании и развертывании программного обеспечения собственной разработки в нем должна применяться идентификация и авторизация, которые должны базироваться на встроенных в операционную систему, базу данных или в системы сервисного программного обеспечения алгоритмах. Другие правила, затрагивающие процесс разработки идентификации и авторизации, касаются обработки информации, которую содержат пароли. 2. Тестирование и документирование. Одной из самых запущенных тем в правилах безопасности, касающихся разработки программного обеспечения, является тема тестирования и документирования. Это очень важные компоненты разработки программного обеспечения, которые затрагивают и вопросы безопасности. В правила необходимо включить требования обеспечить защиту личной и патентованной информации о клиентах путем ограничения ее использования при тестировании программного обеспечения. Процедура тестирования предназначена для выявления всех возможных проблем и нарушений защиты. Можно записать в правила, что запрещено инсталлировать программное обеспечение, если оно не прошло тестирование и не было утверждено руководством. Наличие документации - это не требование обеспечения безопасности. Документация необходима будущим разработчикам, чтобы изучить программные интерфейсы, а также определить, как эти интерфейсы будут функционировать в будущем. Знание интерфейсов максимально раскрывает суть работы системы программного обеспечения, оно необходимо при проведении анализа возможности возникновения в системе проблем и побочных эффектов, которые могут отразиться на информационной безопасности системы. 3. Замена версий и управление конфигурацией. Для управления заменой версий необходимо знать конфигурацию системы и ее компонентов. Зная, что должно быть в системе и в сети, администраторы смогут докладывать о нарушениях безопасности и неисправных программах, установленных в системе. Одним из ключевых аспектов, касающихся безопасности при замене версий и управлении конфигурацией, является возможность отслеживания изменений. Этими правилами устанавливается требование письменных запросов на внесение в систему изменений, которые затрагивают безопасность. Считается неизбежным, что установленное программное обеспечение имеет ошибки. Всегда следует решать такие проблемы немедленно, чтобы предотвратить появление новых проблем. Однако, установка патчей, даже переданных поставщиком, может привести к непредвиденным результатам. Правила, регламентирующие эту сферу, должны вводить процедуры тестирования и требовать установку исправлений, касающихся защиты до установки всего программного обеспечения. Независимо от того, насколько часто тестируется программное обеспечение, может возникнуть необходимость выгрузить из работающей системы установленное ранее программное обеспечение или патчи. В правила управления конфигурацией необходимо включить требование как по инсталляции, так и по
"откату" к предыдущей версии. 4. Сторонняя разработка. Некоторые организации не обладают достаточным опытом, необходимым для разработки собственного программного обеспечения. Проекты, разработанные на заказ, представляют собой потенциальную угрозу безопасности и могут создать в организации определенные проблемы. Когда организация прибегает к помощи со стороны для разработки программного обеспечения, необходимо позаботиться о целостности этого программного обеспечения. Правила в данной области подобны правилам разработки программного обеспечения. Разница в том, что эти правила касаются сторонних организаций и соглашений, определяющих взаимоотношения с ними. В дополнение к обеспечению того, что программное обеспечение функционирует так, как было определено в техническом задании, необходимо, чтобы оно могло работать со средствами управления безопасностью операционной среды, в которой установлено. Если работа программного обеспечения не будет согласована с принятыми инструкциями и алгоритмами, то она может свести на нет требования правил безопасности. Когда организация для разработки программного обеспечения нанимает разработчика со стороны, сторонняя организация может оценить достоинства ваших технологий и рассмотреть возможность продажи на открытом рынке пакета программного обеспечения, созданного для организации, оплатившей разработку. Может быть страхи и преувеличены, но сторонняя организация может даже продать конкурентам технологии вашей организации. Поэтому можно разработать правила, предписывающие, чтобы в соглашениях со сторонними организациями содержались условия продажи и распространения. Учитывая волну банкротств, коснувшуюся многих компаний, вашей организации захочется выяснить, что произойдет, если компания, которая разработала для организации Web-сайт, будет ликвидирована. В большинстве случаев, когда компании закрываются, получение любых ее активов затруднено. Однако, если организация передала на хранение третьей стороне копии программного обеспечения (включая исходники), то она может либо поддерживать программное обеспечение силами собственных разработчиков, либо эту информацию можно передать другой, третьей стороне на сопровождение. 5. Вопросы интеллектуальной собственности. Независимо от того, кто занимается разработкой, конечный результат считается интеллектуальной собственностью организации. Эта собственность включает технологии и другую патентованную информацию о том, каким образом работает организация. Программы должны рассматриваться как ценные активы, принадлежащие организации. Организациям, не имеющим правил защиты интеллектуальной собственности, стоило бы выделить ресурсы на разработку таких правил. Поскольку эти правила не должны противоречить соответствующим законам об интеллектуальной собственности, которые могут быть довольно запутанными, лучше пригласить на работу юриста, который специализируется на вопросах интеллектуальной собственности.

Сторонняя разработка

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

Тестирование и документирование

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

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

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

Тестирование и принятие в эксплуатацию

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

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

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

Тестирование перед инсталляцией

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

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

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

Требования к документации

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

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

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

Управление доступом к программному обеспечению

Другими проблемами, влияющими на безопасность заказанного программного обеспечения, являются "лазейки" или специальные средства управления доступом, которые разработчики оставляют для себя, якобы для отладки или чтобы сопровождать программное обеспечение. Эти точки доступа обычно не документируются и бывают обнаружены только тогда, когда случается что-то непредвиденное. В одной организации обнаружили, что бывший сотрудник использовал такую "лазейку" для выгрузки патентованных данных, которые продавал конкурентам. В убытки организации вошла оплата работы приглашенных консультантов для проведения аудита и устранения других точек несанкционированного доступа.

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

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

Управление конфигурацией и настройки защиты

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

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

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

Управление конфигурацией и обновление

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

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

Bсе обновления программного обеспечения собственной разработки должны проводиться на исходниках программ, а не на созданных на их базе исполняемых модулях.

Утверждение правил разработки программного обеспечения

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

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

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

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

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

Вопросы интеллектуальной собственности

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

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

Большинство организаций имеют правила защиты интеллектуальной собственности, которые не связаны с правилами информационной безопасности. Эти правила обычно разрабатываются юристами для защиты интеллектуальной собственности независимо от того, для чего эта собственность предназначена. Если в вашей организации существуют такие правила, их не стоит включать в правила безопасности. Лучше внести еще один абзац в правила надежной работы (см. главу 11 "Правила надежной работы"), чтобы информировать пользователя о существовании таких правил.

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

Замена версий и управление конфигурацией

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

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

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

Главная сайта