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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Международные вопросы становятся еще более запутанными, когда необходимо разобраться с нормативами "Вассенаарского соглашения" (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, имеющую проверку сертифицированных полномочий, для управления своими ключами через модем, установленный в системе, практически полностью изолированной от остальной сети организации. Организация руководствовалась простым правилом, которое предписывает внеполосную пересылку. Вот оно.

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

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

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

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

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

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

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

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

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

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

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

Шифрование

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

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

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

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

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

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

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

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

Разрешенный формат для генерируемых ключей: двоичный код или открытый текст.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Требования к аппаратных средствам по защите от несанкционированного вмешательства.

Физическое блокирование устройства с использованием настоящего ключа.

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

Защиту хранилища носителей с программными дистрибутивами.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Инструкции о речевых оборотах

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

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

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

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

После небольшой корректировки эта формулировка была включена в документ AUP.

Контроль и исследование сетевых данных

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

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

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

Обязанности пользователей Internet

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

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

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

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

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

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

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

И, наконец, если в правила Internet входит программа инструктажа, то в документ AUP нужно добавить простую формулировку, подобную следующей.

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

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

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

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

Для регистрации в сети вы должны ввести по запросу свое пользовательское имя и пароль.

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

блокировку.

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

Вы никогда не должны записывать свой пароль.

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

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

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

Ответственность организации и предоставление информации

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

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

Правила надежной работы

Тем читателям, КТО СЛЕДУЕТ УКАЗАНИЯМ настоящей книги, необходимо еще провести большую работу, чтобы завершить разработку правил информационной безопасности. Закончив эту массу работы, следует обратить свое внимание на итоговую версию документа, называемую Правилами надежной работы (Acceptable Use Policy — AUP).

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

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

Образец AUP

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

Работа с системами и в сети

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

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

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

Пользователи не должны использовать системы, сети или подключения к Internet для игр.

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

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

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

Разработка AUP

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

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

Язык документа AUP

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

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

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

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

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

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

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

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

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

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

в котором описаны все правила,

Правила надежной работы (AUP) представляют собой документ, в котором описаны все правила, касающиеся пользователей. В AUP собраны фрагменты правил организации, отражающие обязанности пользователей в области обеспечения безопасности. В основном, в этих фрагментах резюмируются отдельные мысли правил, и написаны они простым языком. Документ AUP должен быть кратким, чтобы его можно было использовать в качестве обязательства подчиняться правилам информационной безопасности. Его можно выдавать вновь принятым на работу сотрудникам, подрядчикам или поставщикам, которым предоставляется доступ к сети, чтобы обеспечить гарантии того, что они будут знать свои обязанности.
1. Разработка AUP.
AUP является важным документом. Он должен быть кратким и исчерпывающим. Одна из проблем, с которой можно столкнуться при разработке AUP, заключается в том, что для создания документа необходимо скоординировать работу различных отделов.
Обычно документ AUP должен быть простым и четко оформленным.
2. Обязанности пользователей при регистрации в системе.
Этот раздел представляет собой краткое изложение правил аутентификации (см. главу 5). Пользователи должны быть информированы о положениях, которые им надлежит знать, даже если они и не читали все документы, составляющие правила безопасности.
3. Работа с системами и в сети.
В этом разделе повторяются многие правила безопасности, касающиеся ежедневной работы.
Это обычные правила поведения, нашедшие отражение в правилах безопасности.
4. Обязанности пользователей Internet.
В правилах Internet описываются обязанности пользователей. Эти правила являются кодексом поведения для пользователей, подключающихся к Internet. Мы включили отдельный раздел для пользователей Internet по причине растущего значения Internet как производственного ресурса и особого вида коммуникаций.
В AUP необходимо включить исключительно правила, относящиеся к использованию Internet.
Выделите наиболее важные положения правил Internet и включите их в качестве резюмирующих формулировок в AUP.
5. Ответственность организации и предоставление информации.
Организация обязана информировать пользователей о том, каких действий требуют от них предписания правил, и какие санкции возможны со стороны pуководства организации. Организация еще имеет правовые обязательства информировать о том, какие шаги она предпринимает, включая наблюдение и сбор данных, проходящих через сеть.
Если правилами разрешен мониторинг пересылок по сети или пользовательских файлов, в документе AUP следует написать об этом.
Организация должна информировать о том, что она занимается сбором информации о пользователях из любых источников. В правила необходимо включить формулировки о методах сбора и хранения данных. Информирование - это то, что должно предотвратить осложнения, если собранная информация будет служить основанием для дисциплинарных взысканий.
6. Инструкции о речевых оборотах.
Можно добавить формулировку о введении инструкций, касающихся речевых оборотов, что поможет предотвратить определенные проблемы в будущем. Эти инструкции обсуждались в предыдущих главах.
В некоторых организациях считается более удобным неформальный стиль взаимоотношений. Главное - построить взаимоотношения так, чтобы пользователи прислушивались к руководству.

Сбор конфиденциальных данных

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

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

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

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

Прежде всего должна быть обоснована необходимость сбора конфиденциальной информации.

Организация понимает, что распространение собранных конфиденциальных данных запрещено.

Должно быть определено, разрешен ли мониторинг в организации и, если разрешен, то какой тип мониторинга.

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

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

Аудит и сбор данных

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

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

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

Меры наказания

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

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

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

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

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

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

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

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

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

Мониторинг

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

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

Мониторинг, средства управления и меры наказания

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

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

Обязанности администраторов

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

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

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

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

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

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

Сопровождение главной базы данных или каталога идентификационной базы пользователей и прав доступа.

Выполнение операций по изменению прав и должностных обязанностей.

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

Контроль соответствия при переводе систем в онлайновый режим или их обновлении.

Определение соглашений по присвоению имен для систем и других компонентов сети.

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

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

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

Отчетность о нарушениях безопасности

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

Публикация документов правил и требования по уведомлению

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

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

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

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

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

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

Работа с отчетностью об инцидентах, затрагивающих информационную безопасность

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

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

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

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

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

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

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

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

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

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

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

Работа с правоохранительными органами

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

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

Для обеспечения гарантий защищенности систем

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

Согласование и внедрение

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

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

Консультации у юриста

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

Соображения, касающиеся действий после совершения компьютерных преступлений

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

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

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

Соображения по регистрации событий

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

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

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

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

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

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

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

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

Администраторы должны регулярно просматривать системные и другие журнагы регистрации.

Просматривать файлы журналов могут только пользователи, которым даны на это права.

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

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

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

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

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

Соображения по сохранению улик

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

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

Тестирование и эффективность правил

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

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

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

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

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

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

Требуемые действия

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

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

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

Расширение правил в отношении отчетности и устранения заражения вирусами.

Как документировать и реагировать на запрошенную отчетность о неисправностях программного обеспечения и других изъянах.

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

Управление

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

Руководство должно установить средства управления согласно требованиям этих правил.

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

Дело Рэндала Шварца

В громком деле знаменитый автор и эксперт фирмы Pearl Рэндап Шварц (Randal Schwartz) был осужден за компьютерное преступление в штате Орегон. Обвинявшийся, помимо всего прочего, в несанкционированном тестировании средств защиты сети и систем корпорации Intel, когда он работал на Intel в качестве подрядчика, Шварц заявил, что он это сделал с наилучшими намерениями. Независимо от мнения читателя об этом деле, представим, будто читатель несет ответственность за безопасность сети. Никто никогда не знает, с какими намерениями осуществляется зондирование системы — с благородными или не совсем, особенно, если это, якобы благородное, лицо делает это без разрешения. Как можно об этом знать наверняка? Что предпринял бы читатель в этой ситуации? Об этом стоит подумать при разработке ваших правил.

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

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

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

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

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