Что собой представляет политика информационной безопасности
Однажды мне позвонил клиент и попросил прийти к нему в офис. Когда я пришел, он попросил меня установить брандмауэр, чтобы обезопасить свою сеть. Перед тем. как устанавливать брандмауэр, я поинтересовался о политике безопасности компании. Он с любопытством посмотрел на меня и спросил: "А зачем она мне нужна?".В годы повального увлечения Internet такой ответ скорее является правилом, чем исключением. В организациях проводится продуманная политика управления персоналом, документация которой иногда занимает гору бумаги, но нет никакой политики информационной безопасности. Если же такая политика и разрабатывалась, то, в лучшем случае, вам вручат 5 листов бумаги, в которых описаны активы корпорации с многомиллионным оборотом.
Также как кадровая политика подразумевает наличие четких правил, которым должны подчиняться служащие и администраторы, политика информационной безопасности определяет, каким образом компания хочет обеспечить безопасность информационных активов. Необходимо запомнить один из важнейших постулатов: информация является активами компании. Не всегда руководство компании осознает ценность информационных активов, которыми обладает, но конкуренты вполне могут заплатить тысячи и даже миллионы долларов, чтобы изучить или даже похитить эти активы.
Демонстрация усилий по управлению качеством
Желая угодить заказчику, компании демонстрируют, что их технологии соответствуют стандартам управления качеством продукции. Международная организация по стандартизации (International Standards Organization - ISO) 9001 описывает стандарты управления качеством в технологических и бизнес-процессах. Если компания хочет получить определенный уровень аккредитации, ее политика будет напрвлена на внедрение программы безопасности, отвечающей установленным стандартам управления качеством.
Каким образом нужно разрабатывать правила безопасности
Прежде чем приступать к разработке руководящих документов, необходимо определить глобальные цели политики. Заключается ли цель в защите компании и ее взаимодействия с клиентами? Или же необходимо обеспечить защиту потока данных в системе? В любом случае, на первом этапе необходимо определиться в том, что нужно защищать и почему именно это должно быть защищено.
Правила могут быть написаны для защиты аппаратных средств, программного обеспечения, средств доступа к информации, людей, внутренних коммуникаций, сети, телекоммуникаций, правоприменения и т.д. Перед тем как начинать процесс разработки правил, нужно определить, какие системы и технологические процессы являются важными для выполнения задач компании. Это поможет определить, сколько и каких правил должно быть разработано для успешной деятельности компании. В конце концов с целями нужно определиться, чтобы точно знать, что все стороны деятельности компании охвачены разрабатываемыми правилами.
Когда необходимо иметь разработанные правила безопасности
Лучше всего разработать правила еще до того, как появится первая проблема с безопасностью. Если осуществить это заранее, то администраторы безопасности будут понимать, что именно необходимо защищать и какие меры нужно предпринимать. Кроме того, всегда легче разработать политику для развивающейся инфраструктуры, чем пытаться модифицировать уже существующий режим экономической деятельности.
Критическая оценка, утверждение и претворение в жизнь
Любой корпоративный документ обычно подвергается критической оценке. Правила информационной безопасности - это документы различные по содержанию. В процессе рецензирования должны рассматриваться не только технические аспекты безопасности, но и юридические аспекты, поскольку это имеет непосредственное отношение к организации. До начала разработки правил любого уровня должно быть проведено детальное обследование объекта. Понятно, что предварительное обследование должно быть выполнено разработчиками правил безопасности, и лишь после этого должно выполняться обследование на более низких уровнях. Если в компании есть СIO (Chief Information Officer — руководитель информационной службы компании), то он должен быть в составе комиссии по обследованию объекта. Руководители департаментов или руководители отделов, которые будут иметь непосредственное отношение к разработке правил, также могут участвовать в рецензировании и делать комментарии. И. наконец, поскольку неразбериха в делах никому не нравится, юристы корпорации также должны принимать в этом участие. Юристы понимают раздел правил безопасности, касающийся правоприменения, и знают, каким образом придать правилам законною силу.
Процесс утверждения представляет собой простое одобрение руководством окончательной версии документа. Их утверждение должно состояться после рецензирования. Однако если руководство не благословит эти документы, их эффективность будет ограничена.
И, наконец, после того как правила будут написаны, утверждены, и администраторы получат необходимые инструкции, политика начнет претворяться в жизнь. Если отдельные правила не будут приведены в исполнение, это нарушит целостность всей политики. Это происходит точно так же, как и при невыполнении законов в обществе. Зачем проходить через процесс создания политики безопасности, если ее постановления игнорируются? Правила должны выполняться неукоснительно.
О политике информационной безопасности
Политика информационной безопасности является планом высокого уровня, в котором описываются цели и задачи мероприятий в сфере безопасности. Политика не представляет собой ни директиву, ни норматив, ни инструкции, ни средства управления, Политика описывает безопасность в обобщенных терминах без специфических деталей. Она обеспечивает планирование всей программы безопасности так же, как спецификация определяет номенклатуру выпускаемой продукции. Когда люди заявляют, что технологический процесс не является частью политики, всегда появляются вопросы. Технологический процесс представляет собой детальное описание всех действий. А политика представляет собой изложение целей, которые должны быть достигнуты внедрением этого технологического процесса. Для описания политики используются общие термины, так что политика не оперирует способами реализации. Например, если политика определяет единственное решение производителя для единственного контракта, то в компании возникнут трудности, когда появится необходимость модернизации для создания новой продукции. Несмотря на то, что при разработке политики может потребоваться технологическая документация, сама технологическая документация не должна являться частью политики.
Оценка риска/Анализ или аудит
Единственный способ понять инфраструктуру заключается в полной оценке риска, анализе рисковых ситуаций или полном аудите предприятия. Выполнив все это, разработчики основ политики безопасности смогут хорошо разобраться в информационных технологиях организации. Несмотря на то, что эта работа не доставляет удовольствие, она помогает авторам документов политики всесторонне понять архитектуру системы.
Для оценки степени риска организация может захотеть провести тестирование на преодоление защиты. Это тестирование должно быть выполнено и во внутренней, и во внешней сети, чтобы проверить каждую точку доступа и выявить неизвестные пока точки доступа. Такая всесторонняя оценка позволяет вникнуть в конфигурацию сети. Эта информация будет использована для определения конфигурации , правил доступа в сеть и других правил. Кроме того, такая оценка выявит, насколько сеть обеспечивает выполнение задач организации.
Некоторые администраторы полагают, что они могли бы исследовать систему, определить степень риска и провести инвентаризацию предприятия сами, без посторонней помощи. Несмотря на то. что они, возможно, и могли бы выполнить соответствующую работу всегда лучше пригласить для этого кого-то со стороны. Главная причина заключается в том, что люди извне не знают систему, излюбленных приемов работы и другой информации, которая могла бы подтолкнуть их к предвзятому мнению. Сторонний представитель может прийти в компанию и исследовать системы глазами хакеров. Здесь мы видим широкое поле для творчества. Давайте посмотрим, какая будет от этого польза? Сторонние представители могут выявить уязвимые места, слабости защиты и другие проблемы, которые следует учесть при разработке правил информационной безопасности.
Почему нужно нанимать людей со стороны для оценки степени риска?
Некоторые полагают, что сделать оценку степени риска могут их собственные профессионалы в области систем и защиты информации. Позволим себе не согласиться с этим мнением. Несмотря на то, что люди, работающие в компании, могут быть весьма компетентными, они слишком близко знакомы с технологическим процессом, чтобы суметь отличить технический риск от технологического. Люди извне не обладают такой информацией, поэтому они не будут предвзято утверждать, мол "так должно быть — и точка".
При выборе внешней компании для оценки степени риска, нужно быть уверенным, что ее представители обладают самой последней информацией в сфере защиты и достаточно оснащены технически, чтобы суметь сделать полную оценку степени риска. Они должны понимать, что риски касаются всех аспектов информационной технологии. Поскольку специализированные компании делают это ежедневно, они лучше понимают, какой результат следует ожидать при выполнении своих тестов. Эта объективная точка зрения будет неоценимой для формирования политики безопасности компании.
Определите, какие правила необходимо разработать
Правила информационной безопасности не должны быть единым документом. Чтобы упростить пользование ими, правила могут быть включены в несколько документов. Именно с той же целью эта книга, вместо того чтобы представить сплошной перечень формулировок, разбита на отдельные, объединенные смыслом, главы. Поэтому не стремитесь описать политику компании одним документом, просто разработайте необходимые вам руководящие документы и назовите их главами описания политики информационной безопасности. Тогда их будет легче понимать, легче внедрять и проще организовать изучение этих документов, поскольку каждому аспекту политики безопасности будет посвящен свой собственный раздел. Небольшие разделы также легче корректировать и обновлять.
Сколько различных правил безопасности необходимо разработать? Не хотелось бы отвечать вопросом на вопрос, но, тем не менее, сколько различных видов деятельности и задач поставлено перед вами вашим бизнесом? Для каждой системы, обеспечивающей ваш бизнес, и каждой подзадачи, на которые может быть разбита глобальная цель вашего бизнеса, необходимо разработать отдельный документ. Абсолютно нормально разрабатывать антивирусную защиту отдельно от правил использования Internet. Общепринятая ошибка заключается в попытках втиснуть описание политики безопасности в один документ, который обрисовывает только общие принципы. В результате появляется обширный документ, с которым очень трудно работать, который, возможно, никогда не будет прочитан и не получит никакой поддержки. На рис. 1.1 представлен примерный перечень разрабатываемых правил информационной безопасности.
Рис. 1.1. Примерный список систем, поддерживающих бизнес, для которых разрабатываются правила безопасности
Человечество накопило массу доказательств того, что люди не в состоянии сосредоточить внимание на чем-то одном длительное время. Увы, правила информационной безопасности не являются захватывающей темой. Следовательно, сжатое изложение правил с ясными формулировками и логическим обоснованием в четко скомпанованном документе дадут шанс этому документу быть прочитанным. И не стоит стараться ошеломить свою аудиторию.
Почему важно работать по правилам информационной безопасности
Несмотря на то, что политика не отвечает на вопрос, каким образом должны достигаться технологические цели, все же, определив должным образом, что необходимо обезопасить, мы тем самым обеспечиваем надлежащее управление процессом. В правилах безопасности описано, что должно быть защищено и какие ограничения накладываются на управление. Несмотря на то. что в них не обсуждается ни номенклатура производимого продукта, ни производственные циклы, все же правила безопасности помогут лучше ориентироваться и при выборе продукта, и при выборе путей развития компании. Реализация требований политики обеспечит более высокую защищенность всей системы.
Когда в разработке политики информационной безопасности принимает участие руководство, это говорит о том, что руководство приветствует идею создания политики безопасности, наделяя доверием всю программу безопасности. Поддержка руководства всегда важна. Без поддержки руководства служащие не станут воспринимать политику серьезно. Поэтому, если не иметь поддержку вышестоящего руководства, программа внедрения политики безопасности будет обречена на неудачу еще до окончания ее разработки.
Как получить поддержку руководства
Вначале нужно подобрать соответствующую аргументацию. Нужно доказать руководству, что системы обработки информации и сама информация стоят немалых денег. Можно продемонстрировать, каким образом постороннее лицо или обиженный чем-то собственный сотрудник может с легкостью получить доступ к важной информации, а это может привести к большим экономическим потерям. Можно показать результаты исследований, статьи и даже эту книгу. Но если это их не убедит, то можно подождать до первой беды.
Руководство может заявить, что каждый должен нести ответственность за безопасность на своем участке работы. Такой подход может иметь успех, но только короткий период времени, потому что при этом не происходит развитие компании. Если один отдел использует один стандарт, а другой отдел использует друтой стандарт, то возможность их взаимодействия станет проблематичной. Работа по единым правилам гарантирует, что в организации используются одни и те же стандарты, когда дело касается безопасности. Такая слаженность дает возможность работать организации как единому механизму, облегчает взаимоотношения с клиентами, и вообще поднимает значение информационной защиты всей системы.
И, наконец, политика информационной безопасности поможет наладить четкую работу. Мы живем в правовом обществе. Если пытаться внедрять правила, которые не написаны четко, то нужно быть готовым к судебным разбирательствам. Если вы решите уволить служащего за нарушение правил безопасности, которые никогда не существовали в письменном виде, не были вручены служащему, одним словом не были внедрены в организации, то этот служащий может подать в суд на компанию. Это звучит неприятно, но будет еще неприятней, когда придет повестка в суд.
После прорыва защиты
После прорыва защиты внедрение установок политики безопасности подобно усилиям закрыть двери коровника, когда корова уже убежала. Несмотря на то. что вроде бы уже слишком поздно, в коровнике еще могут быть коровы, которых можно сохранить. Не стоит думать, что раз это уже случилось, больше оно не повторится. Поскольку один раз это уже произошло, оно вполне может произойти снова.
Если вы приступили к разработке политики безопасности после того, как защита была взломана, не нужно фокусировать свое внимание на той части системы, в которой был прорыв защиты. Хотя и эту часть системы нужно учесть в вашей разработке, тем не менее, ее нужно рассматривать как одну из многих критичных с точки зрения защиты частей. Нужно всегда рассматривать проблему вцелом и никогда не фокусировать внимание на отдельной детали. Только таким способом можно разработать удовлетворительную политику информационной безопасности.
и не описывают, каким образом
2. Правила важны для
Соответствие документации
Правительственные чиновники, подрядчики государственных заказов, те, кто нанят подрядчиками для выполнения государственных заказов и сотрудники прочих предприятий, работающих в государственном секторе экономики, должны обеспечивать надежную и безопасную работу систем на своих предприятиях. Правительство и другие заказчики испытывают все большую потребность в четко определенных правилах информационной безопасности. Даже в самом начале нового проекта наличие наработок в области политики безопасности демонстрирует заказчику, что он имеет дело с серьезным партнером, способным обеспечить защиту и своих информационных активов, и активов заказчика.
Создается впечатление, что требования правительства к безопасности постоянно меняются. Единственное, что остается постоянным — это требования, устанавливаемые правительственными службами к подрядчикам касательно следования правилам безопасности. Если компания работает с правительством, ее первой заботой должно быть наличие политики безопасности, начиная с заключения соглашения и выполнения правовых норм, и заканчивая претворением проекта в жизнь.
Уменьшение степени риска
Как известно, бизнес не возможен без риска. Для уменьшения степени риска принимаются меры предосторожности. При разработке политики безопасности анализируются бизнес-процессы и применяются лучшие методы для обеспечения их защиты. Это также может уменьшить потери, понесенные компанией, в случае утери важной информации.
Информационная безопасность и защита компьютеров от вирусов стали неотъемлемой частью вечерних новостей. Это значит, что правовые органы серьезно взялись за борьбу с преступлениями в сфере электронной обработки информации. Все больше дел поступает в суды, чтобы распространить писанные законы на совершенно новый вид преступлений, совершенных в электронном мире. Компании, не имеющие четко разработанных правил, обнаружили, что им стало трудно выяснять отношения в суде, так как суд рассматривает только четкие формулировки. Компании, которые разработали четкие правила безопасности еще до того, как им пришлось столкнуться с необходимостью защищать свои права в суде, имеют несомненное преимущество.
Новая экономика предусматривает страховые надбавки на электронную информацию. Электронная информация и компьютеры, на которых она обрабатывается, стали неотъемлемой частью бизнеса, поэтому компании стремятся застраховать эти активы. В свою очередь, страховые компании интересуются политикой безопасности и методами ее реализации компаниями. Первый вопрос, который вам зададут при заключении договора страхования, будет касаться именно политики безопасности. Только зная политику безопасности страхуемых компаний, сами страховые компании могут определить политику страхования. Страховым компаниям известно, что без разработанной политики безопасности компания не знает степень защищенности своих активов, и, соответственно, страховать операции таких компаний слишком рискованно.
И, наконец, политика безопасности, в которую включены методики разработки программного обеспечения, будет стимулировать разработку более защищенных систем. Руководствуясь такими принципами и стандартами, разработчик сможет работать согласно установленным нормативам, испытатели систем будут знать, какие результаты должны быть получены, а администраторы будут понимать, что требуется от конкретного технологического процесса. Развитие компании по индивидуальному проекту всегда требует больших материальных затрат и ответственного отношения к работе. Путем разработки и внедрения правил разработки программного обеспечения, а также предоставив разработчикам нормативы разработки, риск в бизнесе может быть значительно уменьшен.
Определение целей политики
Анализ данных защиты
Любые наши действия на компьютерах и в сетях вызывают либо перемещение, либо обработку информации. Каждая компания, организация и правительственное учреждение занимаются сбором и обработкой данных независимо от своих функций. Даже промышленные предприятия учитывают важные аспекты обработки данных в своих операциях, включая ценообразование, автоматизацию рабочих цехов и инвентаризационный контроль. Работа с данными играет настолько важную роль, что при разработке правил инвентаризации ресурсов необходимо, чтобы все лица, принимающие участие в их разработке, четко понимали структуру и характер использования данных (а также условия их хранения).
Аппаратные средства и программное обеспечение
Средствами обеспечения бизнес-процессов являются аппаратные средства и программное обеспечение, которые должны быть охвачены политикой безопасности. Поэтому важно провести полную инвентаризацию системы, включая карту сети. Существует множество способов проведения инвентаризации или создания карты сети. Независимо от используемых методов необходимо удостовериться, что задокументировано ей. Ниже следует примерный перечень аппаратных средств и программного обеспечения, которые необходимо инвентаризовать. Возможно, для вашей системы этот список окажется неполным, вам следует самостоятельно решить, каким образом его модифицировать, чтобы он соответствовал задачам вашей компании.
Архивное хранение резервных копий
Кое-кто считает, что последняя задача, которую нужно решить при создании резервных копий, это то, как сохранять носители информации или защитить данные. В качестве одного из этапов контроля и учета операций с данными должно стать особое сообщение во время работы. Если при повседневной работе не обеспечиваются меры по защите данных, то вам стоит самостоятельно разработать правила защиты.
При рассмотрении архивирования резервных копий в первую очередь нужно определить, где будут храниться эти данные: на месте эксплуатации или вне систем? Некоторые организации имеют хранилища для хранения магнитных лент и дисков. В этом случае достаточно иметь правила хранения резервных копий на месте эксплуатации. В противном случае в создании реальных правил может помочь изучение повседневной и наиболее производительной работы.
Несколько лет назад автор извлек магнитную ленту из хранилища, где его компания хранила резервные ленты. Это хранилище было специально спроектировано для хранения 9-дорожечной ленты на срок до 6 лет и поддерживалось в надлежащих условиях. Вышеупомянутая лента была записана 18 месяцами ранее. Автор установил ленту в локальный накопитель и попытался считать ее содержимое. После промотки всего лишь нескольких десятков метров накопитель выдал сообщение об ошибке, и система отказалась считывать ленту.
Сделав еще несколько безуспешных попыток прочитать разные ленты, автор просмотрел регистрационный журнал службы архивации и обнаружил, что специалист по эксплуатации системы настраивал головки накопителей уже после того, как кто-то пожаловался на то, что не может прочитать ленту, присланную клиентом. Несмотря на необходимые настройки, ленты, записанные за три месяца до даты ремонта, были нечитабельны. Если бы эту проблему предусмотрели заранее, то был бы шанс восстановить данные. К несчастью, никаких правил работы с данными или проверки резервных копий не существовало. Руководствуясь этим, автор стал настаивать на том. чтобы внести в правила предложение проводить тестирование архива.
Это привело к возникновению других вопросов: Почему хранилище оказалось заполненным архивами шестилетней давности? Нужно ли нам хранить данные в течение шести лет? Этой компании они были нужны, но необходимо ли другим организациям сохранять информацию столь долгий срок? Если нет, какой срок хранения назначить? В случаях, когда максимальное время хранения дольше, чем время жизни носителя (стандартное время жизни магнитной ленты составляет около двух лет), то, возможно, необходимо установить порядок, который предписывал бы использование носителей однократной записи. Отметим выражение "носитель однократной записи". Вспомним урок из главы 1 "Что собой представляет политика информационной безопасности". Если в правилах не записаны конкретные средства для хранения резервных копий, то есть правила безопасности описаны лишь общими терминами, это позволит людям создать архивы на основе оптимальной технологии. Это позволит воспользоваться новейшими технологиями, на основе которых можно архивировать данные на более долгий срок.
Что должно быть защищено
На первых нескольких страницах этой книги неоднократно повторялось, что политика информационной безопасности должна обеспечивать защиту выполнения задач компании или защиту делового процесса. Эти повторения делались по причине того, что общепринятой ошибкой является подход к компьютерам и программному обеспечению с технической точки зрения вместо того, чтобы выяснить, с какой целью они были вообще закуплены. Как мы помним, компьютеры являются средством для обработки интеллектуальной собственности компании, диски предназначены для хранения этой собственности, а сети — для свободного перемещения этой информации и участия ее во всех бизнес-процессах. Если мы примем это во внимание, то сможем разработать логичную, действенную политику безопасности.
Компьютерные преступления
Когда автор писал этот раздел, он просмотрел три различных инструкции для прокуроров, основанные на различных подходах к тому, что подпадает под определение компьютерное преступление. В каждой инструкции делается попытка увязать локальные прецеденты (судебные определения и заключения) с действующим законом. Единственное, в чем они последовательны, это непоследовательность их требований.
Понятие компьютерного преступления в различных судебных округах отличается. Даже в Соединенных Штатах каждый из федеральных судебных округов может по-разному интерпретировать один и тот же закон. Для компании из Ныо-Иорка правовые нормы могут быть совсем не те, что для компании в Силиконовой Долине. Способ определить, что дозволено в этой области, заключается в переговорах с окружным судьей, генеральным прокурором или адвокатом. Они знают судей и принятые стандарты доказательств, чтобы успешно выиграть дело.
Однако, правило, по которому компании следует докладывать обо всех случаях криминальной деятельности, может не отвечать интересам компании. Возьмем хотя бы историю банка, в чьи системы проникли хакеры и похитили около 11 миллионов долларов! Этот банк сразу же принял решение не докладывать об инциденте судебным органам, опасаясь негативной реакции прессы. Имея в активах миллиарды долларов, было нетрудно списать 11 миллионов на убытки.
Однажды этот банк должен был доложить о понесенном убытке в связи с другим судебным иском. Как только пресса узнала, каким образом банк потерял 11 миллионов, этой негативной рекламы стало достаточно, чтобы повлиять на курс акций и вызвать дополнительное расследование со стороны федеральных инспекторов. В результате возникла проблема в связях с общественностью, что обошлось довольно дорого.
К определению того, о чем докладывать, а о чем не стоит, нужно относиться серьезно. Правила, устанавливающие порядок в этой сфере, должны обсуждаться на уровне высшего исполнительного руководства, которое несет ответственность за свои решения при возникновении проблем. С другой стороны, запись о том, что руководство должно принимать решения в этом конкретном случае, вынудит их рассмотреть все правила информационной безопасности. По их реакции можно будет определить, насколько серьезно руководство относится к этой проблеме. Па этой стадии разработки правил неплохо бы знать, насколько реальна поддержка руководства.
Лицензирование COTS
Правила лицензирования коммерческого программного обеспечения COTS (commercial off-the-shelf) должны учитывать, что в большинстве случаев организации не владеют правом собственности на программное обеспечение или данные, регламентированным соответствующими лицензиями. Лицензии COTS разрешают использование программного обеспечения с определенными ограничениями. Это означает, что все правила COTS базируются на соблюдении существующих лицензий.
Индустрия программного обеспечения расширяет правоприменение процедур лицензирования с помощью альянса производителей коммерческого программного обеспечения BSA (Business Software Alliance). Используя обычно сведения, поступающие от недовольных служащих, BSA проводит аудит и докладывает о лицензионном статусе собственнику программного обеспечения. После расследования BSA поддерживает компанию в судебных процессах против компаний, нарушивших законы о хранении и использовании информации.
Строгие правила COTS предусматривают периодический просмотр лицензионных соглашений, нормативов на приобретение прав собственности, подтверждений лицензий на программное обеспечение, а также протоколов регистрации продукции, поступивших от производителей. Кроме того, должны быть разработаны правила, определяющие права копирования, а также установлен строгий контроль за этими ресурсами и отчетность за них.
Обсуждая политику COTS, автор не раз слышал одно широко распространенное суждение: "Лицензии на программное обеспечение являются собственностью и должны рассматриваться в качестве таковой". Эта идея не нова. Такие лицензии представляют собой материальную собственность с определенной стоимостью, которая может быть подсчитана и обесценена так же, как и станочный парк в рабочих цехах. Таким подходом будет доволен финансовый директор компании, если он или она будет учитывать стоимость программного обеспечения при определении суммы амортизационных отчислений на оборудование, установки и материалы.
Обработка данных
Каким образом обрабатывается информация? При разработке правил следует учитывать множество аспектов, касающихся обработки информации. Необходимо определить, каким образом будет осуществляться обработка данных и как будет поддерживаться целостность и конфиденциальность данных. Помимо обработки информации необходимо рассмотреть, каким образом будет осуществляться аудит этой информации. Следует помнить, что данные являются источником жизненной силы организации, так что необходимо иметь средства наблюдения за состоянием этих сил в системе.
А как насчет использования данных третьей стороны, которые могут быть конфиденциальными и запатентованными? Большинство источников информации связаны соглашениями о совместном использовании и контроле информации, которые входят в условия приобретения данных. При учете информационной базы организации в инвентаризационных документах должны быть учтены внешние службы и прочие источники информации. В инвентаризационных документах также необходимо определить, кто работает с данными и на каких условиях собираются и. возможно, распространяются эти данные.
Учет и обработка внешних данных
Данными от внешних источников может являться любая информация, предоставленная источником вне компании. Всякий раз, когда эти данные поступают, они сопровождаются соглашениями об авторских правах и конфиденциальности, в которых указывается, как использовать эту информацию. Независимо от того, являются ли эти данные обычной информацией или последней версией программного продукта, необходимо предусмотреть механизмы для соблюдения соглашений, согласно которым приобретаются и используются эти данные.
Одним из довольно сложных вопросов является сбор информации из источников с общедоступной информацией, которая при работе объединяется с другой информацией. Для служащих не составляет труда вырезать и вставлять информацию с Web-узлов и других источников во внутреннюю документацию. Поскольку согласно стандартам законного использования это вполне легитимно, служащие должны сопровождать эту информацию соответствующей атрибутикой, особенно, если эта информация цитируется дословно.
Они, конечно, должны сами это знать. Тем не менее, это должно быть установлено правилами и быть включено в программу предупредительной безопасности.
Поскольку информацию, используемую организацией, используют совместно и другие компании, организация может также захотеть совместно использовать их информацию. Независимо от того, является ли это соглашением о партнерстве или каким-то иным видом деловых отношений, необходимо обеспечить механизмы защиты рассредоточенных данных или технологий, которые передаются в качестве интеллектуальной собственности. В разрабатываемые правила информационной безопасности могут быть включены следующие пункты, касающиеся защиты рассредоточенной интеллектуальной собственности.
Довольно сложно предугадать, как сложатся обстоятельства бизнеса, и что можно разглашать и на каких условиях, но в правилах должны быть учтены эти процессы. Один из способов выяснить их влияние на политику безопасности заключается в том, чтобы разобраться, каким образом соблюдаются уже существующие соглашения. В качестве выполнения этапа инвентаризации адвокаты, работающие в комиссии, могли бы собрать все эти соглашения и замечания и обсудить их на рабочих совещаниях. Пользуясь такой информацией, можно разработать правила защиты передаваемой информации и технологий компании в виде руководства пользователя.
Обычно трудно разработать подобное руководство из-за необходимости предварительно классифицировать информацию. Одним из широко распространенных методов является использование защитных меток. Несмотря на то, что использование защитных меток несовместимо со всеми операционными системами, базами данных и прикладным программным обеспечением, разработчики руководства должны определить, каким образом маркировать данные согласно их уровням защиты.Это оказывается необходимым во многих случаях. В частности, персонал, работающий с информацией здравоохранения, является кандидатом номер один для маркировки защиты.
Определение целей политики
Теперь, поскольку мы уже знаем, что собой представляют правила информационной безопасности, и располагаем поддержкой руководства, следующим этапом будет выяснение, что именно необходимо защитить. Этот вопрос выходит за рамки аппаратных средств и программного обеспечения, а охватывает всю систему целиком. Очень важно понять суть деловых операций, которые сопровождают технологический процесс. Разработанные нами документы политики безопасности могут остаться на пыльной полке, если они будут препятствовать компании заниматься своим бизнесом.
Определение лиц, от которых необходимо установить защиту
Определение доступа представляет собой процесс выяснения, каким образом осуществляется доступ к каждой системе и компоненту сети. Сеть может иметь систему для обеспечения сетевой аутентификации и другие вспомогательные системы поддержки наподобие intranet. Но необходимо выяснить, все ли системы имеют доступ такого типа? Каким образом предоставлять доступ к данным при обмене информацией между системами? Поняв, как распределяется доступ к информационным ресурсам, можно определить, на кого должны распространяться правила информационной безопасности. Ниже представлены некоторые соображения о праве доступа к данным.
В первую очередь необходимо определить, кто может иметь доступ к ресурсам и на каких условиях. Например, доступ к данным, касающимся трудовых ресурсов, может предоставляться только персоналу, которому разрешен доступ к кадровой информации, но не всем сотрудникам компании. При разработке правил безопасности может быть предусмотрен прямой доступ к кадровой информации, но при этом в них должно быть определено, что означает выражение "прямой доступ". Правилами, естественно, может быть предусмотрено ограничение доступа тем, кто вообще не должен иметь право доступа'к таким данным.
После определения круга лиц, которые могут иметь право доступа, необходимо подумать над тем, какими должны быть механизмы правоприменения и наказания за несанкционированный доступ. Будет ли организация применять закон? Какие дисциплинарные меры будут применяться по отношению к служащим, которые нарушили установленные правила? Что можно сделать с точки зрения закона?
Законное основание действий компании очень важно. В нашем противоречивом обществе важно конкретно обосновывать виды нарушений установленных правил. В некоторых правилах достаточно указать, что служащие могут быть уволены и "преследоваться в судебном порядке с полным применением законных мер". Однако в других формулировках может потребоваться специфический язык, разъясняющий соответствующие законы. Поэтому при разработке правил безопасности было бы неплохо пригласить в состав комиссии юриста.
Этот совет распространяется и на внешний доступ к системам организации. Употребив выражение "внешний доступ", мы говорим об ограничении доступа не только посредством Internet. Доступ можно получить и через виртуальные частные сети (VPN — Virtual Private Network), частные сети, наподобие клиентской сети, которая использует ретрансляцию кадров (Frame Relay) или модемы. Необходимо определить эти точки доступа, а также разработать правила получения права доступа к ним. Поскольку правила, определяющие права доступа, являются весьма важной основой безопасности любой организации, эта тема полностью раскрыта в главе 5 "Аутентификация и безопасность сетей".
По причине того, что нынешний цикл развития программного обеспечения приходится на так называемую "эру Интернета", всем нам приходится считаться с общими для всех изъянами программного обеспечения и общими ошибками пользователей. Речь идет о непреднамеренных вторжениях в защиту сети, которые могут помешать работе по выполнению важных задач. Хотя довольно сложно заранее предусмотреть, что делать в случае отказа в работе или обнаружения ошибок, все же необходимо провести и такой вид анализа. Один из способов рассмотрения непреднамеренного создания проблем и возможных вторжений в системы заключается в использовании метода анализа живучести сети (SNA Method — Survivable Network Analis Method). Для получения более подробной информации о методе SNA см. Приложение Б.
Анализ живучести сети
При анализе сети на живучесть с использованием метода SNA вначале проводятся три этапа, а именно: сбор данных о системе, определение основных характеристик и предварительная оценка уязвимых элементов системы. Эти три этапа очень важны для аналитика — они помогают выяснить сущность целевого назначения работы этих систем и находить необходимые компромиссные решения в проекте системы. В методе SNA для анализа того, как применяется сеть, исследуется архитектура сети и рабочие сценарии.
Суть метода SNA заключается в необходимости определения двух типов рабочих сценариев сети:
1. Стандартные рабочие сценарии (NUS — normal usage scenarios);
2. Рабочие сценарии вторжения (IUS— intrusion usage scenarios).
При анализе NUS определяется, каким образом должна использоваться система и ее компоненты в "нормальных" условиях. Таким образом, все, что не является нормальным, может рассматриваться при анализе вторжения. IUS можно использовать для определения потенциальных воздействий на систему при успешных атаках или аварийных ситуациях. Этот тип анализа очень полезен для понимания того, каким образом компоненты сети взаимодействуют в системе.
Персонал и данные персонала
Организация может набирать персонал и собирать информацию о персонале различными способами. Эти способы затрагивают и общение по электронной почте, в процессе которого собирается информация с WеЬ-узлов. Компании, которые занимаются продажей товаров и услуг, могут собирать данные о клиентах на основе заказов/входных сообщений или звонков в отдел обслуживания покупателей. Даже объявления о продаже или наведение справок потенциальными покупателями могут дать информацию об отдельном лице или компании. Независимо от того, каким образом приобретены эти данные, для каждого типа данных должны быть сформулированы правила, касающиеся использования этих данных.
Политика секретности и государственная политика в Соединенных Штатах
В то время, когда писалась эта книга, создатели государственной политики в Вашингтоне обсуждали практику сбора и обработки данных о персонале в течение цикла их деловой деятельности. В недавних сводках новостей Федеральная торговая комиссия (FTC — Federal Trade Commission) рекомендовала, чтобы конгресс одобрил законы, требующие раскрывать, каким образом компании используют информацию, которую собирают путем доступа к Web-узлам. Этот вопрос встал на повестку после выяснения того, что многие Web-узлы не проводят политику секретности и не соблюдают правила информационной безопасности, описанные ниже.
В настоящее время директивы FTC о секретности представляют собой всего лишь рекомендации и не являются частью государственного законодательства. По просьбе FTC Конгресс рассмотрел эти предложения. По причине множества спорных вопросов прогнозируется, что обсуждение этих предложений затянется очень надолго.
Один из таких вопросов заключается в том, каким образом внедрять политику безопасности, когда ваша организация функционирует вне страны. Компании США, которые занимаются бизнесом в Европе, например, должны соблюдать строгие правовые нормы, охраняющие неприкосновенность личной жизни в Германии и Скандинавии. Несмотря на то, что эти нормы могут быть непопулярными внутри вашей организации, при работе вне Соединенных Штатов следование им может оказаться очень полезным.
Подробная информация об этом содержится в Приложении Б.
Когда речь идет о соблюдении правил секретности, нужно установить, что не только организация должна обеспечивать соблюдение конфиденциальности информации, касающейся служащих или клиентов, но и сами служащие должны соблюдать права конфиденциальности организации. Правилами должно быть установлено, что все, что касается конфиденциальности, права собственности и другой подобной информации не может быть доступным без предварительного согласия.
Дать определение политики секретности не так легко. Поскольку правила представляют собой лишь указания, а не являются рабочими инструкциями, некоторые организации предпочитают определять, что необходимо защитить в рабочей документации. Один из наилучших способов разграничить эти понятия, заключается в том, чтобы выяснить, что должно быть включено в правила соблюдения секретности, и составить одну или несколько общих формулировок. Эти формулировки и являются правилами. Таким образом вопрос о том, как обрабатывать информацию, относится уже к области технологии.
Права интеллектуальной собственности и политика безопасности
Каждая организация независимо от ее функций имеет интеллектуальную собственность, которую необходимо защищать. Даже если организация не проводит политику информационной безопасности, она, возможно, имеет разработанные правила и процедуры для защиты ее интеллектуальной собственности. Однако разные организации определяют эту собственность по-разному. Например, компания, являющаяся ценообразователем на рынке, будет защищать технологические процессы от разоблачения их конкурентами, чтобы те не выяснили, какие проводятся меры для снижения уровня цен.
Для большинства профессионалов информационной безопасности разработка правил защиты интеллектуальной собственности, является одной из самых сложных задач. Не только такие правила влияют на бизнес-процессы, но и совокупность правовых нормативов интеллектуальной собственности, которые могут различаться в разных штатах и странах. Когда планируется и разрабатывается политика в определенной области, весьма разумно проконсультироваться с юристом, который специализируется в данной области. На предварительных стадиях планирования стоит рассмотреть несколько вопросов, касающихся правил защиты интеллектуальной собственности.
Работая с интеллектуальной собственностью, независимо от того, является ли она собственной разработкой организации или приобретена, необходимо четко знать свои права на эту собственность, подтвержденные договором. Например, многие программы позволяют пользователю создавать одну копию с целью резервирования, но не позволяют работу нескольких копий одновременно. Что касается печатных работ, здесь все еще действует закон "от многого немножко", который позволяет делать ограниченное количество копий для персонального пользования. Поскольку печатные материалы используются и для производственных целей, необходимо посоветоваться с юристом о том, каким образом разрешено их использовать.
Технический персонал и интеллектуальная собственность
Существует множество городских легечд, связанных с использованием и защитой интеллектуальной собственности. Один из моих знакомых говорит, что способ обеспечения авторского права без заполнения необходимых бумаг заключается в отправлении десяти копий работы себе по почте. Почтового штемпеля на нераспечатанных конвертах, мол, будет достаточно для фиксирования даты и места выполнения работы.
Технический персонал имеет тенденцию наивно верить, что с помощью этих легенд они смогут заработать много денег. Позже они обнаруживают, что эти схемы не обеспечивают защиту. Интеллектуальная собственность является таким запутанным предметом, что мифы и легенды не должны служить руководством в обеспечении защиты наиболее важных активов организации. Лучше вместо этого переговорить с юристом, который специализируется в этой области. Юрист объяснит, что эти десять конвертов только пополнят казну почтовой службы.
Примерный инвентаризационный список
| Аппаратные средства | Программное обеспечение |
|
|
Один из способов составления карты сети заключается в определении потоков информации в каждой системе. Схема информационных потоков может показать, насколько потоки информации обеспечивают бизнес-процессы, а также показать области, в которых важно обеспечить защиту информации, и принять дополнительные меры по обеспечению живучести системы. В свою очередь, с помощью этой схемы можно определить, где должна храниться информация, включая базы данных, как эта информация должна перемещаться в системе, дублироваться, контролироваться и регистрироваться администратором.
Реагирование на инциденты и судебные разбирательства
Автор этой книги подписался и получает по электронной почте все информационные листки, касающиеся информационной безопасности. В этих сообщениях описываются различные подробности изъянов и других уязвимых мест в защите, которые могут создать проблемы с безопасностью систем и сетей. Некоторые из них представляют интерес для всех, в то время как другие касаются только пользователей продукции конкретного производителя. Большинство из них содержат информацию, представленную пользователями, а некоторые содержат информацию производителя. Автор понимает, что то количество информационных листков, на которое он подписался, чрезмерно для администраторов, но поскольку он работает с клиентами, ему необходимо получать последние сведения в полном объеме.
Однажды, сидя у себя, вы находите просчет в разработанной системе безопасности, и если бы хакер или злонамеренный служащий использовал этот просчет и атаковал систему, то это бы привело к нарушению работы сети организации. Вместо того чтобы забросить эту информацию, постарайтесь опубликовать ее.
Некоторые люди понимают, что информирование об инцидентах является важной службой в сообществе Internet. Поэтому они начинают докладывать о проблемах, которые обнаруживают. Многие организации этого сообщества ввели у себя правило сообщать об инцидентах. Можно отправлять информацию более чем 30 различным организациям, которые занимаются реагированием на инциденты. Чтобы помочь этим службам, ваша организация могла бы проводить политику реагирования на инциденты, поддерживая связь с одной (или несколькими) группой (группами) обработки информации об инцидентах через одного ответственного за эту работу. Возложив ответственность за это дело на одного человека (можно с дублером), можно передавать информацию с единственного официального источника, так что она не будет потеряна в море сообщений.
Координационный центр CERT
Дедушкой всех подразделений реагирования на инциденты является Координационный центр CERT (CERT/CC) в Карнеги Мэллон университете в Питсбурге (Computer Emergency Response Team - группа реагирования на нарушения компьютерной защиты в сети Internet). Основанная в 1988 году как бригада компьютерной "скорой помощи" в кооперации с Департаментом безопасности компании Internet Worm, CERT/CC собирает информацию об инцидентах, касающихся компьютерной безопасности и, проведя исследования, определяет, нужно ли об этой проблеме широко оповещать. Несмотря на то, что методы CERT/CC рассматриваются как несколько спорные, они обеспечивают ценные услуги обществу. CERT/CC является не только службой реагирования на инциденты. В Приложении Б представлен список и других его услуг.
Резервирование, архивация и уничтожение информации
Правила обработки зарезервированной на внешних носителях или внесистемных устройствах информации должны быть столь же строги, как и в отношении обработки доступной оперативной информации. Резервные данные могут содержать финансовую информацию, историю взаимодействий с клиентами и даже копии текущих рабочих документов. Если не обеспечить защиту данных, один бог знает, что могло бы случиться, если бы конкуренты получили и проанализировали эту информацию. А что, если они обнаружат данные, от которых необходимо избавиться? Поэтому правила резервирования должны отражать сами процессы архивирования данных и предоставить инструкции, в которых будет определено, от каких данных и в какое время необходимо избавляться.
В этой главе обсуждались цели
В этой главе обсуждались цели и задачи, определяющие, что именно нужно защищать. Эти цели относятся не только к аппаратным средствам и программному обеспечению, составляющим систему, но и охватывают весь технологический процесс при подготовке производства. Ваша способность обеспечить поддержку решений политики безопасности определит успех документа.
Соображения резервирования
Почему организация дублирует информацию вне своих компьютеров? Для восстановления системы после выхода из строя? Для сохранения важных данных? Хочет ли организация хранить копию состояния системного программного обеспечения? Как часто выполняется резервирование? Осуществляется ли это ежедневно, еженедельно или же раз в месяц? Каким образом это делается? Как часто происходит сверка и пересмотр этого процесса?
Как ответить на эти вопросы, чтобы резервирование обеспечило быстрое восстановление важных бизнес-процессов после аварийного отказа? В описание всего бизнес-процесса необходимо включать процессы восстановления и обработки информации, необходимой для обеспечения его поддержки. Эти сведения помогут ответить на эти вопросы и установить правила этой работы.
Общепринятая ошибка при разработке правил резервирования заключается в предоставлении специальных опций в пакете программного обеспечения, используемого компанией. Определяя, каким образом резервирование поддерживает бизнес-процесс, разработчики правил должны постараться ограничить документ, описывающий, что должно быть сделано, и не конкретизировать процессы резервирования до уровня предоставления специальных опций. Ниже следует несколько вопросов, на которые стоит обратить внимание при рассмотрении правил резервирования.
Стратегия реагирования на инциденты
Другой аспект работы с инцидентами заключается в реагировании на них. Реагирование на инциденты необходимо, когда обнаружен несанкционированный доступ в сеть: когда бригада реагирования обращается к организации и сообщает, что возникла проблема, и им нужно войти в компьютеры организации; или когда кто-нибудь обращается в службу связи с общественностью с сообщением, что в операционной системе или программном обеспечении, которым пользуется организация, имеется проблема.
Подобно отчетности об инцидентах, правилами реагирования на инциденты должна быть определена одна точка для контакта. Это контактное лицо должно отвечать за сбор всех сообщений и готовить меры реагирования на них независимо от того, кто их присылает. Естественно, контактное лицо должно определять, имеет ли сообщение об инциденте какое-то отношение к организации. Правилами безопасности этому лицу могут быть определены полномочия на выполнение всех необходимых действий для решения любой проблемы, возникающей на основе этих сообщений, а также дано право привлекать необходимых специалистов к исследованию этой проблемы.
Работа с независимыми бригадами реагирования подобна работе с любыми независимыми службами за исключением того, что исполнитель работ, заключая с вами договор, может потребовать, чтобы ваша организация работала через отдельное контактное лицо. Например, ваша организация может захотеть, чтобы реагированием на инциденты занимался сотрудник безопасности. Ну, а исполнитель работ может пожелать работать непосредственно с системными администраторами организации, минуя сотрудника безопасности. Разрешение на это требует незначительной корректировки правил, и это должно быть сделано, чтобы обеспечить тесное сотрудничество с бригадой реагирования.
Учет трудовых ресурсов
Наиболее важным и ценным ресурсом компании является персонал, который работает и хранит активы компании, учтенные при инвентаризации. Учет персонала, задействованного в технологическом процессе компании и имеющего доступ к системам, данным и внекомпьютерным ресурсам, обеспечит понимание того, какие правила информационной безопасности необходимо разработать.
Учет персонала можно упростить вплоть до составления типовой схемы организации компании. Но может оказаться весьма обременительным включение тысячи или даже нескольких сотен служащих в один большой документ. Более того, структурные схемы организации пользуются дурной славой негибких документов, не предполагающих изменений или роста в структуре компании. Помимо этого, в инвентаризационный документ может быть включен тип работы, выполняемой подразделением, наряду с уровнем доступа служащих этих подразделений к данным предприятия. Например, если у компании имеется крупный отдел продаж, то создание структурной схемы этого подразделения с указанием имени каждого сотрудника, может спровоцировать самолюбивые устремления служащих, а сама схема перестанет служить по своему прямому назначению. Так что будет лучше, если структурная схема будет включать "Отдел продаж", помеченный отдельным номером, где точно может быть и не указана работа продавцов.
Положительный аспект такой реализации заключается в том, что руководство будет понимать, кто работает в организации и в каком подразделении. В качестве одного из этапов этого процесса руководство может увидеть дублирование работ, определить сильные и слабые стороны персонала, а также выявить узкие места в организационной структуре. Такой анализ похож на анализ живучести сетей с той разницей, что он проводится в социальной сфере. Руководителям не нужно напоминать, что они должны руководствоваться результатами такого анализа.
Уничтожение данных
"Разгребание мусора" является общепринятой практикой индустриального шпионажа для поиска ценной информации. Коллега, с которым автор книги работал в данной области, рассказывал потрясающие истории о том. чего только не выбрасывали в утиль некоторые компании. Однажды ему выпала необыкновенная удача. Он собрал более двух дюжин бобин с магнитной лентой из мусорной корзины конкурента, на которых содержалась конфиденциальная информация компании.
Каким образом организация удаляет данные? Если это делается путем выбрасывания лент без стирания записанной на них информации, то собиратели мусора непременно обнаружат секреты компании. Определение процедуры утилизации данных имеет такую же важность, как и определение того, какие данные выбрасывать. Необходимо быть уверенным, что правилами четко определены процедуры удаления или утилизации данных, а также установлены требования к обеспечению того, что данные не смогут быть считаны.
Один из способов обеспечения гарантий того, что установленные правила будут выполняться, заключается в том, чтобы возложить ответственность по утилизации данных на одно лицо, а контроль за этим процессом — на другое лицо. Правила должны гарантировать, что работа будет вестись согласно регулярному расписанию и по жестким инструкциям, а также обе ответственные стороны смогут обеспечить контроль над тем, чтобы лица, не предусмотренные этими правилами, не смогли получить доступ к данным.
Внекомпьютерные ресурсы
Инвентаризация, как и правила информационной безопасности, должна охватывать не только аппаратные средства и программное обеспечение. Должен еще быть перечень программной документации, документации на аппаратные средства, системы, административную инфраструктуру, а также прочая документация, описывающая все технологические процессы. Эти документы могут содержать информацию относительно особенностей организации бизнеса, а также могут показывать области, которые могут быть атакованы. Следует помнить, что бизнес-процессы могут быть объектами как индустриального шпионажа, так и хакеров и оскорбленных служащих.
Схемы информационных потоков и живучести системы
Жизучесть— это способность системы выполнять свои задачи и важные процессы во время атак, повреждений и аварийных ситуаций. Она основывается на исследованиях, проведенных координационным центром CERT (www.cert.org) университета Карнеги Меллон. Эти исследования показывают, что вместо того, чтобы использовать традиционную модель защиты типа крепости, сети нужно рассматривать как несвязанные независимые объекты с определенными маршрутами коммуникаций и специфическими надежными взаимосвязями.
Анализ системы на предмет живучести включает в себя определение требований к сети, предъявляемых со стороны особенностей ведения бизнеса, архитектуру сети, насколько она удовлетворяет этим требованиям, а также поиск компромиссных решений для обеспечения того, чтобы средства, обеспечивающие живучесть системы, не нарушали бизнес-процесс. Частью такого анализа является исследование потоков информации в системе. Исследование этих потоков и анализ критических процессов помогут выявить точки, в которых должны быть усилены меры защиты, а также показать, какие ограничения на архитектуру системы накладываются требованиями технологии.
Для получения дополнительной информации об исследованиях CERT на живучесть см. Приложение Б "Ресурсы".
Подобным образом должна быть проведена инвентаризация всех формуляров, бланков особого учета организации и других материалов с названием организации, используемых в качестве официальных бумаг. Использование бланков счет-фактур и бланков организации может дать кому-то возможность имитировать официальную деятельность компании и использовать информацию для похищения денег или даже дискредитации организации. Поэтому необходимо учитывать все эти бланки во время инвентаризации, чтобы можно было разработать правила защиты этих активов.
Обязанности в области информационной безопасности
Аудит и контроль
Аудит и контроль важны при внедрении и контроле за соблюдением требований безопасности. Однако если эта работа не будет составной частью бизнес-процесса, то есть вероятность того, что эти меры никогда не будут осуществлены. Необходимо осознать, что эта работа является контролем качества выполнения программы информационной безопасности. В результате работа по обеспечению внутреннего аудита средств управления информационной системы, будет выполняться постоянно, а не отдельными кавалерийскими наскоками.
Позже в этой книге мы поговорим о проведении независимой экспертизы. Однако в этой главе мы ограничились рассмотрением функций того, кто организовывает и следит за проведением такой экспертизы.
Интеграция информационной безопасности в бизнес-процесс организации
Основной целью распределения обязанностей по защите информации является интеграция информационной безопасности в среду бизнеса. В качестве одного из этапов этой интеграции необходимо определить должности, которые обеспечивают безопасность всей работы. Например, один из способов осуществления этого заключается в распределении обязанностей и контроля над активами организации путем координирования работы каждого, включая ответственных за информацию и материально ответственных сотрудников. При таком подходе, не возникнет двусмысленностей относительно того, кто, за что и когда отвечает.
Еще одним аспектом исследований является вопрос, каким образом организовано управление безопасностью в организации. Обычно в организации формируется главная группа управления информационной безопасностью. Главная группа отвечает за внедрение и контролирует исполнение правил безопасности и процедур. Будем рассматривать подход, принятый для неограниченных систем (см. главу 2 "Определение целей политики"), когда главная группа управления информационной безопасностью назначает администраторов безопасности для многопользовательских систем, в которых имеется большое число подразделений. Тогда в каждом подразделении будет свой собственный сотрудник безопасности или посредник, который будет помогать внедрению программы безопасности подразделения. Таким образом можно обеспечить более тесное сотрудничество тех, кто следит за безопасностью, с пользователями Это похоже на институт участковых милиционеров, принятый в милиции.
Тесное сотрудничество сотрудников службы безопасности с остальным персоналом будет полезным и при управлении связями в реальном времени со сторонними организациями. Но утроза безопасности исходит не только от собственных служащих, но и от клиентов, поставщиков, а также от каждого, кто, подключаясь к информационным активам организации, имеет возможность нарушить правила безопасности. Посредники должны отвечать за обучение перечисленных выше аутсайдеров, а также контролировать их деятельность и стимулировать ее.
Так работают в небольших организациях. Во многих из них, особенно в сторонних организациях, немногочисленный персонал делят на "отделы", в которых один человек назначается посредником со службой безопасности.
Тем не менее, это не лучшее решение. Некоторые люди, работающие в организации достаточно большой период времени, могут найти способы разобраться в тонкостях работы системы и злоупотребить этим в каких-то своих целях. Единственный способ предотвратить это заключается в том, чтобы не допускать пребывание сотрудника продолжительное время в роли посредника по безопасности, например, не более одного-двух лет. По завершению этого срока они передают свою работу кому-нибудь другому. Другой способ заключается в том, чтобы установить порядок проверок и учета. Система снабжения организации является одним из управляемых процессов. Даже несмотря на то, что большая часть закупок проходит этап утверждения руководством, часто такое утверждение проходит формально, и оплата проходит без последующих уведомлений. Зато посредник безопасности в бухгалтерии будет следить за нарушениями в порядке закупок и отгрузки заказов.
Один ревизор поделился впечатлениями о своей работе, которую все считают очень сложной. Мало кто способен выполнять эту работу. Ревизор должен знать все тонкости бизнеса, особенности клиентов и поставщиков, знать старые и новые правила делопроизводства, а также - денежные потоки организации. Только зная все это, ревизор сможет разобраться в счет-фактурах и заявках на закупки и определить, нет ли в них каких-то нарушений.
И последним аспектом, который следует учесть в процессе реализации программы защиты информации, является цикл развития программного обеспечения. Независимо от того, разрабатывалось ли программное обеспечение собственными силами или организацией-подрядчиком, или же были закуплены коммерческие программные продукты (COTS - Commercial Off-The-Shelf), целью должно быть создание безопасных систем, в которых можно бы было легко локализовать ошибки или попытки вторжения.Внедрение стандартов кодирования и тестирования также будет содействовать обеспечению качественных производственных процессов. Более того, использование такой парадигмы как живучесть, также может стать основой для проектирования программного обеспечения, с которым не будет проблем при развертывании или в процессе эксплуатации.
Комитет по управлению информационной безопасностью
Один из способов перебросить мост между двумя группами заключается в создании Комитета по управлению информационной безопасностью. В обязанности этого комитета будет входить контроль за изменениями в планировании бизнеса и определение того, каким образом правила информационной безопасности должны отражать эти изменения. Другой целью этого комитета может быть анализ производственных процессов и обеспечение гарантий соответствия их правилам безопасности, а также удовлетворение запросов на исключения из этих правил.
Чтобы комитет работал успешно, необходимо, чтобы в него входили специалисты различного профиля, наподобие состава группы, которая разрабатывает документы, определяющие политику безопасности. Однако разница в том, что этот комитет должен состоять исключительно из представителей руководства, которые будут понимать суть политики безопасности с позиций и экономических, и технических перспектив. Техническое руководство должно осознавать суть проблем бизнеса и иметь доступ к информации для того, чтобы оказывать помощь в принятии правильных решений по вопросам безопасности. Необязательно каждому члену комитета быть руководителем исполнительного уровня, но было бы неплохо, чтобы в комитете были представители и исполнительного персонала.
Конкретные задачи информационной безопасности
Единственным способом, гарантирующим, что любой из работающих в настоящее время в организации или принимаемый на работу служащий, или пользователь будет знать, что обеспечение безопасности является частью его или ее работы, является включение соответствующих записей в должностные инструкции. Изложение функциональных обязанностей и требований безопасности в должностных инструкциях демонстрирует сотруднику важность информационной безопасности и заставляет осознать, что она является неотъемлемой частью его работы. После того, как эти обязанности и требования введены в должностные инструкции, к ним начинают относиться с пониманием того, что они влияют на оценку профессиональной пригодности работника.
Сторонние подрядчики, поставщики или другие лица, которые предоставляют услуги непосредственно в сети компании, должны включать подобные формулировки в свои рабочие предписания (SOW). Как и в случае с собственными служащими, такие записи документально подкрепляют обязательства компании, а также заставляет подрядчиков и поставщиков строго следовать правилам требований безопасности организации, так как по этим показателям будет оцениваться качество предоставляемых ими услуг.
Обязанности ответственных за информацию
Если организация приняла решение распределить права на информацию, необходимо рассмотреть, какие обязанности имеют ответственные за информацию лица. Инструкции, изложенные в правилах безопасности, должны определять круг ответственных за информацию лиц, кому разрешен доступ к особым средствам управления информацией. Слово "особые" подразумевает, что ответственные за информацию имеют доступ к таким средствам управления, с которыми не могут работать все остальные. Подобные формулировки правил могут быть составлены и для администрирования средств управления доступом в рамках тех функций, которые дозволены администратору.
Самая важная обязанность ответственного за информацию заключается в разрешении и отмене права доступа к информации компании. При разработке правил, которые связаны с правом доступа к информации, необходимо учитывать, что в правилах должна быть регламентирована работа и самого ответственного за информацию. Кроме того, в правилах доступа к информации необходимо оговорить возможность восстановления данных и функций управления доступом. Например, в правилах могут быть следующие формулировки.
Следует помнить, что рассматриваемые механизмы являются частью правил безопасности. Нужно избегать соблазна регламентировать последовательность действий ответственного за информацию.
Обязанности руководства
Обязанность руководства заключается не только в материально-технической и организационной поддержке. Недостаточно одного благословения программы информационной безопасности: руководство должно признать программу частью производственного процесса. Признание руководством программы информационной безопасности частью производственного процесса показывает, что отношение руководства к ней точно такое же, как и к другим задачам, стоящим перед организацией.
Обычно, когда такое говорят представителям руководства, их это шокирует и приводит в ужас. Прежде всего, они не обучались технологии или основам информационной безопасности. Им объясняют, что они и не должны понимать, как это работает, но им необходимо быть уверенными, что их бизнес надежно защищен, а решения безопасности не мешают бизнес-процессу. Руководство намечает определенные цели для организации, а большинство профессионалов в сфере безопасности и информационных систем не желают понимать или вникать в эти нюансы. Это не нападки на руководство или на технический персонал, но годы разногласий и непонимания настроили две эти группы враждебно по отношению друг к другу.
Обе группы должны понимать, что безопасность не является чем-то таким, что может быть сложено в красивую папку и поставлено на полку. Она является целью, за осуществление которой должны бороться обе эти стороны. Это становится ясно после анализа степени риска, стоимости и требований гарантии защищенности доступа к информации. Руководящий состав должен нести ответственность за проведение анализа и возложение обязанностей на технический персонал, отвечающий за внедрение правил информационной безопасности.
Обязанности в области информационной безопасности
Те, кто читает эту книгу с первой главы, вероятно, хотел бы, чтобы она сразу начиналась с описания разработки правил безопасности. Однако перед тем как начать разрабатывать правила безопасности, необходимо получить ясное понимание ролей и обязанностей отдельных лиц в организации по отношению к безопасности. Как уже говорилось в первых двух главах, для успеха программы информационной безопасности поддержка руководства является наиболее важным моментом. Наряду с этой поддержкой должна быть и ответственность за дальнейшее участие в этой программе. В этой главе расписываются обязанности руководства и тех, кто претворяет программу в жизнь. Понимание роли этих групп необходимо для успешной реализации программы безопасности. Глава заканчивается обсуждением контрольного инструктажа и материально-технического обеспечения.
Обучение и поддержка в области защиты информации
После разработки правил безопасности необходимо организовать обмен мнениями между разработчиками, руководством и каждым сотрудником организации, чтобы всем разъяснить предписания политики и ее значение. На этом заключительном этапе планирования необходимо запланировать обучение персонала. Это обучение необходимо каждому, кто имеет доступ к компьютерам и сетям компании. Сотрудники должны располагать необходимыми записями, включая программу обучения и сам курс обучения, а также все утвержденные документы принятых корпоративных правил безопасности.
Руководство должно не только выделить время на обучение, оно должно всячески поощрять его. Автор был привлечен в одну компанию для проведения обучения в специально выделенное время, а именно, когда служащие не были заняты с клиентами или не были больны, они должны были посещать занятия. Предписания политики позволяли не выплачивать служащим жалованье до тех пор, пока они не пройдут курс обучения или не просмотрят его на видеопленке. Необязательно доходить до таких крайностей, но такой способ дает гарантию 100%.
Следует помнить, что разработав большое число различных правил безопасности, нужно позаботиться, чтобы все они были применимы в ваших конкретных условиях. Это означает, что невозможно спланировать программу обучения персонала как "одну для всех". Планы обучения должны быть тесно согласованы с политикой безопасности организации. Необходимо также понимать, что не каждому служащему необходимо обучение по всем аспектам безопасности. Например, персоналу технического сопровождения не нужно изучать правила безопасности, установленные для разработчиков программного обеспечения. При разработке планов и программ изучения правил безопасности следует обеспечить, чтобы каждый аспект правил безопасности был изучен соответствующим персоналом.
Понятие управления безопасностью и применения закона
Во время написания этой книги стало известно, что Microsoft, якобы, подверглась атаке хакеров из-за океана. В сообщениях говорилось, что предположительно, хакеры использовали для внедрения в программы вирусы "троянский конь" и смогли извлечь исходные тексты программ, разработанных Microsoft. Имели место и другие известные вторжения и последующее преследование злоумышленников. К сожалению, за исключением нескольких особых случаев, большинство правонарушителей так и не были пойманы.
По сравнению с другими сферами применения закона юриспруденция компьютерных преступлений и информационной безопасности находится в зачаточном состоянии. Как и во времена Дикого Запада, преступники изобретают новые преступления, а полиция должна решать новые проблемы. Прежде всего, проблемы касаются юрисдикции. Среда Internet, многонациональные корпорации и бурный рост всемирных коммуникаций делает условными границы между штатами, провинциями, странами и континентами. Даже если будут найдены злоумышленники, причинившие ущерб компании Microsoft, и выяснится, что они из-за океана, то, собственно, законы какой страны применять по отношению к этим правонарушителям?
Под чью юрисдикцию это подпадало?
В 1999 году компьютерные студенты на Филиппинах создали вирус, который атаковал популярную коммерческую почтовую программу, что причинило убытки на миллионы долларов, исходя из предполагаемых затрат на восстановление программного обеспечения. Когда эксперты вычислили, что сообщения с вирусами приходили с Филиппин, министерство юстиции Соединенных Штатов стало работать вместе с должностными лицами Филиппин, чтобы арестовать хакеров. Представители министерства юстиции заявили, что их юрисдикция распространяется на все преступления, даже если злоумышленники являются гражданами Филиппин. Но власти Филиппин не смогли арестовать преступников, поскольку на Филиппинах не существовало закона, согласно которому можно бы было предъявить обвинения хакерам.
Между Соединенными Штатами и Филиппинами заключен договор об экстрадиции, но достаточно ли он эффективен для того, чтобы хакеры предстали перед судом в Соединенных Штатах? До сих пор хакеры обвиняются в преступлении, но все еще пребывают на Филиппинах. Пройдет немало времени, прежде чем дипломаты осознают, какой вред наносят компьютерные преступления и заключат эффективные договоры, способные защитить национальные и международные инфраструктуры.
Другая проблема заключается в том, чтобы понять, как повлияло на закон появление компьютеров. Несмотря на то, что существует много законов, касающихся компьютерных преступлений, все они написаны и приспособлены для бумажного мира. Даже, несмотря на то, что существуют законы, отражающие развитие телефонии, правоведы все еще набираются опыта, оставляя нас среди множества разнообразных и противоречивых законов.
Но все это сказано не для того, чтобы вы опустили руки, столкнувшись с преступлениями такого рода. Наоборот, необходимо готовиться к тяжелым битвам, чтобы виновные в преступлении все-таки предстали перед судом. Первое, что нужно сделать — это изучить законодательство. Ясно, что администраторы и персонал службы безопасности раньше не изучали законодательство, но существует множество источников, из которых можно узнать, какую защиту обеспечивает закон (ссылки можно найти в Приложении Б "Ресурсы").
Иной важный аспект законодательства заключается в определении того, что требуется в юрисдикции для предъявления обвинения в преступлении. Законы различны не только в разных странах: в различных судебных округах США федеральный закон также применяется по-разному. К сожалению, федеральные окружные суды напоминают феодальные поместья; прецеденты в одном из них никак не влияют на другие до тех пор, пока дело не дойдет до Верховного Суда. Это означает, что необходимо понимать, какие нормы права действуют в округе, в котором будет рассматриваться ваше дело.
Один из лучших способов определить, какие действуют правовые нормы, проконсультироваться у местных юристов. Среди профессионалов в области физической безопасности общепринято обсуждать свои планы с полицией и прокуратурой. Тем не менее, за исключением ФБР, сотрудничества с национальным центром безопасности инфраструктур (NIPC— National Infrastructure Protection Center), может и не получиться, поскольку они могут и не понимать, как можно оказать помощь.
Нуждаемся ли мы в NIPC?
Национальной центр безопасности инфраструктур был организован в 1998 году на основании указа президента, в качестве службы, в которой правоохранительные органы могли бы получать информацию о том, как обеспечивать безопасность появляющихся важных информационных инфраструктур. Несмотря на такую благородную концепцию, кое-кто считает, что ФБР не должно собирать и хранить такую информацию. Некоторые даже с содроганием вспоминают времена Гувера (J.Edgar Hoover), когда в архивах хранились файлы с компрометирующей информацией. Нужно ли привлекать ФБР, если будут собираться данные такого рода?
Работая пока не очень уверенно, NIPC уже предоставил массу полезной информации службам, следящим за соблюдением закона. Программа NIPC InfraGuard разработана для того, чтобы объединить усилия государственною и частного секторов экономики для защиты информационных ресурсов. Успех этого мероприятия зависит от развития сотрудничества в экономике. Тот, кто хочет получить больше информации о NIPC, может посетить Web-сайт www.nipc.gov.
Главное, на чем нужно сосредоточить внимание после совершения преступления — сбор улик. Поэтому, в качестве этапа предварительной подготовки, ознакомьтесь с правилами сбора свидетельских показаний. Эти правила изложены в инструкциях, которыми руководствуются прокуроры при представлении этих показаний в суде. Поэтому, правила информационной безопасности нужно разрабатывать на основании этих инструкций, чтобы уметь правильно обработать данные, системы, сети и системные журналы после того, как было совершено преступление. Это нужно представить в виде четких руководств, прилагаемых к правилам, работая по которым можно быть уверенным в надлежащей защите улик. Нельзя забывать, что без предоставления соответствующих доказательств прокурор может использовать формулировку "за недостатком улик", и преступники окажутся на свободе.
Право на информацию
Одной из самых сложных задач руководства или комитета по управлению является распределение ответственности за информационные ресурсы или средства управления ими, что также называется правом на информацию. Лицо, которому предоставлено право на информацию, становится ответственным за сохранность информационных активов согласно установленным правилам.
Для многих людей право на информацию представляет собой довольно непростую концепцию. В традиционной модели безопасности данные и средства управления ими хранятся на серверах под бдительным надзором администратора или администраторов. Администратор должен понимать, как функционирует система, и как установить средства управления доступом. Проблемы начинаются тогда, когда администратор вынужден иметь дело с набором разнотипных средств управления большим числом разнотипных серверов, баз данных, средств хранения данных или, проще говоря, "ресурсов". Чтобы поддерживать ощущение порядка, администратор следует правилам, пытаясь привести их к единому знаменателю, как-то удовлетворяющему каждой из обслуживаемых им систем.
В этом сценарии типа "безразмерная подгонка на все случаи" администратор устанавливает классификацию, степень важности и средства управления доступом к информации согласно своим представлениям о работе. Нет гарантий того, что эти атрибуты будут соответствовать правилам безопасности в отношении каждого, кто имеет доступ к информации. Могут возникнуть конфликты между пользователями, требующими доступ к информации, и администраторами, которые приняли ошибочные решения.
В качестве альтернативного метода можно было бы предоставлять право на данные и на средства управления. Ответственный за информацию отвечал бы за предоставление доступа к данным и определял бы, каким образом будет осуществляться управление данными. Для управления информационными активами ответственный за информацию работал бы с администраторами безопасности и/или системными администраторами. Он сам бы определял степень важности и классифицировал информацию вместо того, чтобы оставлять это на попечение администратора.
В результате управление информационными активами соответствовало бы нуждам ответственного за информацию.
Ответственный за информацию отвечал бы за отклонения от общепринятой практики обработки информации. Если запрос на получение информации требует действий, нарушающих существующие правила, то в таком случае ответственный за информацию будет отвечать за принятые отклонения от правил и за возможные последствия. В некоторых организациях от ответственного за информацию требуют письменного запроса на отклонения от правил, а также он должен подписать заявление о полной ответственности в случае возникновения потенциальных проблем. Поскольку никто не хочет излишне рисковать карьерой из-за такой ответственности, запросы на отклонения от правил появляются нечасто.
Обратная сторона права на информацию заключается в том, что ответственный за информацию должен обеспечивать доступ к информации в соответствии с требованиями правил безопасности. Более того, некоторые ответственные за информацию считают, что несправедливо требовать от них полной ответственности и заставлять рисковать своей карьерой, поэтому они нарушают инструкции и игнорируют правила. Изначально ответственный за информацию должен осознавать ответственность за информацию, которой он или она наделен. Единственный способ решить эту проблему заключается в надлежащем обучении вопросам безопасности, в поддержке руководства и последовательном строгом контроле за соблюдением требований.
Другая проблема, связанная с правом на информацию заключается в том, что эта схема хорошо работает только в таких организациях, где данные можно распределить среди потенциальных ответственных за информацию. Автор книги не замечал, чтобы такая схема хорошо работала в маркетинговых организациях или в таких компаниях, где данные полностью интегрированы в среде. Право на информацию также может стать проблемой в небольших организациях, в которых недостаточно людей для поддержания этой концепции. Одна из компаний, с которой сотрудничал автор, сделала каждого из 20 служащих совладельцами данных.Несмотря на то, что это было сделано, в первую очередь, в целях поддержки морального состояния, такая мера также помогала поддерживать целостность данных.
Если вашу организацию не удовлетворяет предложенная концепция права на информацию, можно откорректировать правила так, чтобы они предусматривали создание ответственных комитетов. Такие небольшие комитеты выполняют ту же работу, что и ответственные за информацию, но ответственность несет не одно лицо, а группа лиц. Еще лучше, когда весь комитет является ответственной стороной. В этом случае при появлении запросов на отклонение от правил создается ситуация, требующая дополнительных проверок и согласований.
Привлечение консультантов по защите информации
Привлечение внешних ресурсов стало основой деятельности компьютерной индустрии с тех пор, как компании стали предлагать компьютерную обработку информации на мощных компьютерах в режиме разделения времени. Современные внешние ресурсы могут обеспечить компании обработку любого рода информации, включая и обеспечение защиты информации.
Ниже представлены серьезные аргументы в пользу привлечения консультантов или независимых компаний, специализирующихся на защите информации. При определении целей политики безопасности в отношении внешнего окружения необходимо рассмотреть несколько вопросов.
Прочие аспекты защиты информации
Для успеха любой программы защиты информации необходимо охватить ею всю деятельность организации. Программой защиты информации должны быть охвачены рабочие инструкции и должностные обязанности каждого, кто занят в данном бизнесе, описания рабочих процессов, а также методы аудита и сопровождения.
Распределение прав на информацию
Первое правило при распределении прав на информацию заключается в том, чтобы заинтересовать ответственного за информацию, сделав его собственником этих данных. Другими словами, ответственным за финансовую информацию должен быть кто-то, кто подчинен финансовому директору. Такое распределение сделать непросто. Не стоит создавать массу различных подразделений, если это не согласуется с бизнес-процессом. Это также означает, что отдел информатизации не должен являться ответственным за всю информацию, разве что это необходимо для таких операций, как конфигурирование системы, идентификация пользователей, службы именования доменов и т.п.
На одном из этапов этого процесса необходимо переговорить с заинтересованными сторонами. Обсудив право на информацию с теми, кто имеет к ней непосредственное отношение, можно выяснить их соображения по этому поводу. Они могут даже предложить идеи касательно того, как распределить или систематизировать ответственность за информацию.
Права на информацию должны быть распределены на основе систематизации информационных активов верхнего уровня. Можно использовать те же результаты систематизации информации, которая была проведена во время подготовительных работ (описанных в главе 1 "Что собой представляет политика информационной безопасности"). Мы рекомендуем использовать систематизацию верхнего уровня, так как в этом случае не будет слишком много лиц, ответственных за информацию. Это может потребовать дополнительного анализа того, кто и за какую информацию должен отвечать, но ограничение числа ответственных лиц даст возможность управлять этим процессом. Таким образом, в соответствии с классификатором информации каждый важный вид информации должен иметь назначенного ответственного за этот вид информации.
Для успеха программы защиты информации
Для успеха программы защиты информации поддержка руководства имеет решающее значение. Наряду с заявленной поддержкой должна быть и ответственность за успешное проведение в жизнь этой программы. Особое значение мы придаем назначению ответственных руководителей и роли того персонала, кто реализует административные меры внедрения правил безопасности. Программа безопасности будет иметь успех, если персонал и руководители будут хорошо знать свои функции и будут готовыми к решительным действиям. А этого можно добиться только в том случае, если каждый будет хорошо знать правила безопасности, пройдя полный курс по программе изучения информационной безопасности.
обучения.
Роль отдела информационной безопасности
Отдел информационной безопасности отвечает за внедрение и сопровождение всего спектра документов, составляющих правила информационной безопасности организации. стандартов, инструкций и руководств. Этот отдел проводит обучение персонала основам безопасности и контролирует, чтобы каждый сотрудник знал свою роль в проведении политики безопасности. Короче говоря, отдел информационной безопасности обеспечивает механизмы, поддерживающие программу безопасности, намеченную политикой.
Этот отдел должен поддерживать баланс между образованием и административным принуждением. Установить такой баланс довольно сложно. В правилах безопасности для этого отдела должны быть четко определены все обязанности. Отдел должен рассматриваться как партнер в бизнесе, поскольку если он будет заниматься исключительно применением административных мер, то он будет попросту внушать страх. Страх может вызвать негативную реакцию, что будет препятствовать внедрению правил информационной безопасности.
Глава 12 "Согласование и внедрение", как видно из названия, посвящена согласованию и административным мерам как неотъемлемым компонентам обучения основам информационной безопасности. Те, кто до начала разработки правил безопасности хочет иметь больше информации о роли обучения, могут заглянуть вперед и прочитать эту главу.
Инструктаж по вопросам безопасности
Невозможно переоценить важность инструктажа и образования вообще для проведения в жизнь политики безопасности. После разъяснения предписаний политики и инструктажа всех, кого она затрагивает, касательно их роли в ее проведении, служащие будут воспринимать политику безопасности как неотъемлемую часть своей работы. Но добиться этого нелегко. Одна из проблем состоит в том, что уже более десяти лет ведущие компании-производители при выпуске своей продукции демонстрируют свою полную незаинтересованность в вопросах безопасности. В результате выпускается продукция, которая не соответствует полностью стандартам безопасности, а ее применение не позволяет эффективно реализовывать программу информационной безопасности. Эта дихотомия может сбить с толку.
Техническое обучение в области безопасности строится на развитых общественных связях. Организация могла бы нанять в отдел безопасности технически подготовленного специалиста по связям с общественностью. Это лицо занималось бы организацией переподготовки, развитием отношений отдела с пользователями и действовало бы в качестве посредника между пользователями и отделом. Используя опыт такого специаписта по связям с общественностью, можно поднять уровень пользователей в вопросах защиты информации на соответствующий требованиям отдела уровень.
Согласование планов информационной безопасности
При обсуждении обязанностей и служебного соответствия руководителей необходимо уделить внимание тому, как руководство следит за соблюдением правил, а также, как оно реагирует на нарушения правил. Эти условия касаются не только поддержки руководства. Необходимо обсудить роли, которые будет выполнять руководство на арене информационной безопасности.
При проведении обучения присутствие представителей руководства может быть эпизодическим и нерегулярным по сравнению с присутствием прочего персонала компании. Но не стоит разделять руководителей на какие-то категории, лучше посмотреть, нельзя ли объединить их в едином плане безопасности. Постарайтесь сделать руководство активным участником. Если нет необходимости контролировать системные журналы или проводить независимые проверки (хотя это могло бы быть неплохой идеей), руководство может быть привлечено к организации совещаний, а также к рассмотрению дел служащих, которые нарушили правила безопасности. Если же проблемы затрагивают правовые аспекты, члены руководящего состава должны стать активными участниками расследования.
Такой метод бывает трудно преподнести нетехническому руководящему составу. Даже в процессе автоматизации бизнес-процессов руководство, которое не понимает технологии, старается спрятаться за спины технического персонала или консультантов. Несмотря на то, что информационная безопасность на самом деле не является техническим вопросом, все выглядит именно так. Один из способов включить руководство в процесс разработки политики безопасности заключается в том, чтобы сделать руководство ответственным за эти процессы подобно наделению правом на информацию управляющих нижнего уровня. Сделав их ответственными за безопасность, можно быть уверенным, что их деятельность сразу станет плодотворной, а вопросы безопасности не будут попадать под сукно в их кабинетах или гибнуть в проволочках различных управленческих комитетов. Для этого звена руководства, чьи амбиции нуждаются в постоянной подпитке, назначение ответственности будет весьма кстати.
Физическая безопасность
Анализ кадрового обеспечения
Кадровая политика организации направлена на управление трудовыми ресурсами во время их работы в организации. Она охватывает правила учета основного технического персонала и правила инструктажа персонала. Сюда не входят правила найма, правила проведения аттестаций и процедуры собеседований. Эта работа обычно регламентируется правилами управления трудовыми ресурсами. Это следует учитывать, особенно когда отдел кадров возражает против включения этих работ в правила информационной безопасности. В качестве компромисса можно включить эти положения в оба раздела правил.
Перед тем как государственные служащие и подрядчики начнут писать гневные письма автору этой книги, пусть вначале прочтут общее правило, основанное на опыте разработки автором правил безопасности различных компаний. Правительству (гражданскому или военному) и правительственным подрядчикам могут потребоваться правила найма и получения допусков. Даже тогда, когда приходится руководствоваться требованием работать с федеральным правительством и на федеральное правительство, подчинение этим правилам является обязанностью отдела кадров организации.
Доступность системы
Бывают такие случаи, когда отключения необходимы. В общем случае правила, предоставляющие время для профилактических работ, или разрешающие отключить отдельные вспомогательные системы, должны дополняться и ограничиваться рабочими инструкциями, к тому же решение об отключении должно приниматься несколькими ответственными лицами. Эти правила должны ограничивать возможности пользователей задерживать или прерывать работу систем, а также должны определять последовательность действий при замене стандартных ресурсов на резервные для обеспечения стабильного функционирования важных деловых операций. Такие процедуры также называются контрольными заменами (control overrides).
Контрольные замены относятся как к физической категории правил, так и к эксплуатационной. Так как для проведения таких замен требуется ручная работа, предпочтительней включить требования проведения этих операций в правила физического обеспечения работоспособности систем. Следует понимать, что чрезмерное применение плановых замен может говорить о некорректном использовании технических ресурсов. Поскольку контрольные замены применяются в исключительных ситуациях, лучше включить в правила положение, ограничивающее их применение, поскольку такие замены могут привести к отказу в обслуживании систем. Ниже представлен пример формулировки правил.
Необходимо ввести процедуры для ограниченного использования контрольных замен системных ресурсов. Эти процедуры должны определять методы нахождения решений для контрольных замен, которые могут регистрироваться и быть пересмотрены.
Физическая безопасность
В первых трех главах обсуждалась подготовка, которую необходимо провести для разработки правил информационной безопасности. В этой главе мы начнем рассматривать правила физической безопасности. Правила физической безопасности несложны, поскольку каждый понимает идею физической защиты собственности. Но хорошая политика должна охватывать не только стандартные концепции оружия, охраны и пропускных пунктов. При разработке правил также должно учитываться планирование аварийного резерва оборудования и процедуры его восстановления после аварии. В данной главе рассмотрены отдельные вопросы, которые необходимо включить в правила безопасности.
Инвентаризационный учет
Кто может сказать, что должно находиться в помещении для серверов? Должна ли находиться в этом кросс-шкафу телефонная линия? Все, что имеет в своем хозяйстве организация, и где предполагается это разместить, определяется инвентаризационным учетом. Руководствуясь при монтаже оборудования инвентаризационным перечнем, можно быть уверенным, что в помещении не будет установлен какой-нибудь не тот компьютер или коммуникационное устройство.
В правилах инвентаризационного учета должно быть записано, что необходимо составить номенклатуру оборудования с указанием места его размещения. Маркировать оборудование можно с помощью металлических ярлыков или ярлыков из другого прочного материала. Имеет смысл отметить в правилах, что использовать следует ярлыки, которые можно было бы считывать с помощью электронного оборудования, что-нибудь вроде штрих-кодов или встроенных электронных инвентаризационных меток вроде тех, которые используются для предотвращения краж в универсальных магазинах. Эти технологии можно использовать вместе с компьютеризированным оборудованием, обеспечивающим точный учет аппаратных средств и программного обеспечения, что очень важно при проведении инвентаризации информационных активов.
Монтаж оборудования
Физически оборудование будет защищено наилучшим образом в том случае, если организация сама создает новое оборудование или приобретает оборудование, которое может быть модифицировано при установке. Организация может спроектировать распределительные щиты, помещения для серверов и оптимальную схему коммуникаций и расширений, что упростит монтаж оборудования для информационного обслуживания. Даже если организация переживает пока не лучшие времена, в правилах безопасности должна быть предусмотрена установка такого оборудования.
Правила, регламентирующие монтаж оборудования, должны быть простыми и общедоступными. Во-первых, нужно изучить существующее оборудование. Где следует разместить компьютеры, серверы и коммуникационное оборудование? Это надо определить в неспецифических терминах. Например, рассмотрим формулировку правил компании, которая запускает большую вычислительную систему в крупном городе. Главный компьютер этой системы размещен на 10 этаже за несколькими надежно закрывающимися дверями, помещение имеет фальшпол, высокие потолки, лампы дневного света и два пожарных выхода. Эта компания могла бы иметь правила безопасности, предписания которых выражены следующими словами.
Помещение для компьютеров должно иметь достаточную площадь и быть расположено на любом этаже, кроме первого, с несколькими дверями и иметь несколько пожарных выходов.
Заметьте, что в этой формулировке не говорится о фальшполах, высоких потолках и освещении. Эти элементы, несмотря на их важность, можно назвать деталями реализации и описывать их в правилах безопасности вовсе не обязательно. Таким образом, если фальшпол больше не потребуется или появятся новые типы ламп, которые работают лучше старых, не нужно будет делать изменения в правилах.
Язык документов политики безопасности
Очень важно, каким языком написаны правила безопасности, не менее важно, чем при написании этой книги.
Язык, особенно языковой стиль, используемый при составлении формулировок правил, может сказать много о документе, а также о том, как в организации относятся к правилам информационной безопасности.
Можно допустить и ложное толкование документа. Если язык чересчур формален или многословен, то может возникнуть мнение, что правила написаны для них как бы свысока. Если же язык чересчур неформален, то служащие могут и не воспринять эти правила серьезно.Поэтому, здесь нужно искать золотую середину.
В этой книге представлены формулировки правил, написанные простым языком, но формальным стилем. Формулировки составлены без использования модных словечек или жаргона. Формальность связана с тенденцией использовать в формулировках правил повелительные безличные наклонения (в английском варианте слова "shall" и "shall not"). Те, кто работают с федеральным правительством, отметят, что этот стиль похож на стиль, который используется в заявках на : торгах (RFP — Request For Proposals) или в рабочих предписаниях (SOW — statement of work).
Стоит отметить, что в формулировке задается размер помещения без указания конкретных размеров. Выражением "помещения должны иметь достаточные размеры" правило предписывает, чтобы эти помещения для компьютеров были подходящими. Тонкость этого момента заключается в том, что требования этих правил будут гарантировать, что при проектировании новых площадей офиса будет достаточно серьезно учтено обеспечение необходимыми помещениями информационных систем.
Одним из вопросов, которые необходимо учесть при разработке правил монтажа оборудования, является доступность к резервным источникам электропитания и доступ к ресурсам, предоставляемым предприятиями коммунального хозяйства. Под резервными источниками электропитания подразумевается все,. начиная от энергетической компании, обеспечивающей электроэнергией от отдельных энергетических систем, до источников бесперебойного питания (UPS— uninterruptible power supply), которые снабжают компьютеры электроэнергией аккумуляторов, предоставляя администратору время для отключения систем и выполнения всех подготовительных для отключения питания операций. Сложности начинаются при разработке правил, в которые включены требования по электроэнергии.Правила должны отражать физические и экономические реалии, и в то же время определять, что необходимо делать, чтобы обезопасить бизнес-процесс. Например, банк может затребовать полное резервирование электрообеспечения систем, которые обеспечивают автоматическое функционирование банкоматов, но - ограниченное резервирование для систем, которые поддерживают работу этих банкоматов только в рабочее время. Правило могло бы быть следующим:
Компьютерное оборудование нужно размещать в помещениях, в которых имеется несколько дверей и пожарных выходов с полами жесткой конструкции, и в которых предусмотрен доступ к резервным источникам электропитания.
Обеспечение условий в помещении
Когда автору довелось помогать одной организации в определении ее политики безопасности, он поинтересовался у руководителей, что они думают об условиях, созданных в помещении и средствах управления ими. Главный менеджер с удивлением поинтересовался, разве им еще необходимо что-то иметь, кроме кондиционеров. Осмотрев их помещение, автор увидел большие антистатические ковры возле серверов и начал спрашивать о составе атмосферы внутри помещения.
Каждая составляющая, определяющая условия в помещении, должна определяться правилами. Знание того, что необходимо делать для управления уровнем статического электричества в помещении, поддержки надлежащей влажности (главного виновника проблемы статического электричества), температуры и состава воздуха, поможет снять эти проблемы вместо того, чтобы их игнорировать. Формулировка правил может быть довольно проста.
Помещения, в которых размещены серверы, должны быть снабжены средствами поддержания в помещении такой температуры и влажности воздуха, чтобы исключить влияние статического электричества.
Обеспечение стабилизированным питанием, преобразование напряжения и фильтрация, даже потребляемые каждым компонентом информационной системы токи, не обязательно имеют отношение к условиям в помещении. Тем не менее, поскольку мы рассматриваем поддержание определенных условий в помещении, а требования к электропитанию являются необходимым условием внедрения информационных систем, к тому же не нашли отражения в других правилах, вопросы обеспечения стабилизированным питанием можно включить в этот раздел.
Общая безопасность компьютерных систем
Целью разработки правил безопасности универсальных компьютерных систем, является обеспечение работоспособности систем и обеспечение информационной поддержки бизнес-процесса. Поэтому такие факторы, как техническое обслуживание и аварийные отключения (ожидаемые и незапланированные), рассматриваются именно в этом разделе.
Ограничение доступа к компьютерному оборудованию
Обсуждая общие проблемы управления доступом с системными администраторами, всякий раз убеждаешься, что они крайне неохотно уступают управление физическим доступом к "их" системам кому-то другому. Такой подход к распределению ответственности, конечно, приветствуется (см. главу 2 "Определение целей политики"), но иногда он откровенно мешает. Системные администраторы являются ключевым звеном в этом процессе, но иногда лучше, чтобы существовал не зависимый от них процесс управления физическим доступом.
Определение правил физической безопасности для компьютерных и коммуникационных систем требует такого же внимательного подхода, как и при разработке правил физической безопасности для любого другого оборудования. Однако по причине того, что управление этими системами отличается от управления оборудованием общего назначения, есть смысл для этих систем разработать отдельные правила.
При разработке правил физической безопасности для компьютерного оборудования необходимо продумать три основных вопроса.
Даже если в вашем машинном зале стоят накопители на магнитной ленте, обрабатывающие ежедневно мегабайты данных, не стоит прельщаться их демонстрацией или предоставлять физический доступ в машинный зал кому-либо — более важно обезопасить главные информационные активы.
Периодическая система и контроль конфигурации сети
Однажды, группа слежения за противозаконными действиями в Internet, сообщила системному администратору, что с одной из его систем было отправлено множество незатребованных сообщений по электронной почте. При проведении расследования он обнаружил систему, установленную дежурным специалистом для отправки этих сообщений из компании. Никто не знал, что эта система была установлена в серверном зале. Не было также никаких записей о сервере, обеспечивающем эти операции. В ходе дальнейшего расследования администратор обнаружил, что этот сервер был установлен два года назад, и у него было даже собственное зарегистрированное имя домена.
Чтобы больше ничего подобного не произошло, администратор занялся проведением ежеквартальной проверки конфигурации. Конечно, компания располагала планом разработки структурной схемы системы, но в нем не были регламентированы проверки на предмет установки непредусмотренных проектом аппаратных средств. Поскольку этот администратор следил за отклонениями в работе и изменениями конфигурации компьютерной системы, он понял, чтв ежеквартальная проверка конфигурации является хорошей идеей, и он добавил в правила безопасности компании требование проводить такую проверку.
Однако если компания, в принципе, не устанавливает новые аппаратные средства и не проводит существенных изменений в их конфигурации, то проверки можно проводить реже. Рекомендуется, чтобы они проводились не реже одного раза в год. Таким образом, можно составить следующую формулировку правил.
Руководитель группы технического сопровождения должен проводить проверку конфигурации системы и сети, по крайней мере, каждый календарный год. Он может проводить проверки и чаще, если считает это необходимым.
Отметим, что в правилах снова назначается проверка системы без уточнения специфики ее проведения. В зависимости от типа системы, используемой организацией, проведение проверки может преследовать различные цели. Довольно сложно определить в правилах специфику проведения проверки. Если правила меняются в соответствии с утвержденным планом, в котором определено, какой именно тип проверки необходимо проводить, то в формулировку можно внести детали.
Системный администратор должен разработать план проведения проверки конфигурации системы и сети. В этом плане должны быть описаны процедуры проверки конфигурации аппаратных средств, подключений компонентов сети и установленных компонентов системы. План должен быть утвержден комиссией, состоящей из системного администратора и других руководителей отделов. Комиссия должна ежегодно, или по мере необходимости, пересматривать эти процедуры. Проверки должны проводиться, по крайней мере, каждый календарный год. Системный администратор в случае необходимости может проводить проверку и чаще.
Хоть в данную формулировку правил это и не включено, было бы неплохо, чтобы проверку системы проводил кто-то, кто не является сотрудником подразделений обеспечивающих работу системы. Этим будут ограничены возможности проверяющего покрыть собственные нарушения правил безопасности.
Планирование действий в экстремальных ситуациях
Когда террористы пытались подорвать в 1993 году Всемирный Торговый Центр в Нью-Йорке, сотни компаний закрылись на время эвакуации из зданий, известных как Здания-Близнецы. В результате, компании понесли убытки в миллиарды долларов. В течение трех месяцев чуть ли не половина этих компаний обанкротилась. Большинство уцелевших организаций располагало планами действий на случай экстремальных ситуаций, что позволило им или их дочерним компаниям продолжать заниматься бизнесом, пока здания оставались закрытыми. Тот, кто хочет обсудить важность планирования на случай непредвиденных обстоятельств, мог бы переговорить со служащими сотен компаний, которые оказались без работы по причине того, что их компании обанкротились.
Планы реагирования на непредвиденные обстоятельства
Никому не понравится мысль о том, что здание, в котором расположен их офис, может быть взорвано, уничтожено огнем или стихийным бедствием. Но вероятность таких бедствий существует, поэтому лучше подготовиться к ним заранее. Хоть разработка такого плана и выходит за рамки документов, составляющих правила безопасности, тем не менее, в правила можно ввести инструкции, предписывающие разработку такого плана. В этих инструкциях может быть рассмотрена аварийная обработка данных, способы завершения работы систем и меры предосторожности для сохранения жизнеспособности информационных систем и возможности их восстановления. Правило может звучать следующим образом.
Системный администратор должен располагать планом на случай непредвиденных обстоятельств и бедствий, в котором описывается, что при этом делатъ с оборудованием организации. Этот план должен гарантировать целостность данных и возможность быстрого их восстановления. Любой план, составленный на основе этого плана, должен содержать в себе меры предосторожности для предотвращения смертельных случаев, травм и ранений, благодаря разработке нескольких сценариев. В этом плане должно также быть предоставлено служащим право решать, принимать ли им участие аварийных работах или нет, если их жизни угрожает опасность.
Посетители
В каждой организации периодически бывают посетители. Независимо от того, пришел посетитель на встречу или он представляет обслуживающий персонал — в любом случае необходимо разработать правила, регламентирующие поведение посетителей. Общей концепцией для такого рода правил является требование точной идентификации посетителя и его регистрация. В процессе регистрации можно потребовать от посетителя, чтобы он ознакомился с правилами и положениями компании и всегда находился с сопровождающим.
Что же касается вопросов открытого посещения, то следует помнить, что не в каждой организации работают сотни служащих и имеются контракты с федеральным правительством, и поэтому до заключения контрактов требуется разработать многие из этих правил. Однако разработка продуманных правил посещения будет полезна в любой организации. Довольно неразумно позволять посетителям свободно перемещаться по помещениям организации. Возможно, стоит включить в правила формулировку с требованием к служащим не пускать в помещение никого, кто не имеет соответствующего разрешения.
Наличие правил посещения организации представляет собой попытку исключить потенциальную возможность промышленного шпионажа. Следует понимать, что посетитель может пойти на любые шаги, чтобы добиться преимуществ в конкурентной борьбе. Это в равной степени относится как к небольшой компании, так и к правительственной организации. Ниже следует пример формулировки правил посещения организации.
От посетителя необходимо потребовать точной идентификации своей персоны, чтобы войти в любое помещение компании. После того, как посетителю будет разрешено войти, служащий компании должен сопровождать посетителя в течение всего времени его пребывания на территории компании.
Предупреждения об опасности и сигналы тревоги
В планах реагирования на непредвиденные обстоятельства должна быть предусмотрена установка системы оповещения, которая будет сообщать персоналу соответствующей службы об авариях на системах, обслуживаемых этой системой оповещения. В правила, регламентирующие работу систем оповещения и предупреждения об опасности, необходимо включить положение об оповещении администрации. Администрация, в свою очередь, должна отвечать за информирование каждого сотрудника об аварийных ситуациях или ожидаемых аварийных отключениях.
В эти правила обязательно должна быть включена рекомендация сделать постоянно доступной контактную информацию аварийных служб. Если организация имеет непрерывный цикл работы (24/7/365), то в правила безопасности следует включить условия вызова аварийной службы, которая имеет дежурный персонал, работающий и в нерабочее время.
Профилактическое обслуживание
Основной причиной, препятствующей нормальному техническому обслуживанию, особенно в больших системах, является недоступность системы программными средствами из-за сбоев, которые можно было бы предотвратить. Некоторые люди утверждают, что профилактическое обслуживание является общепринятой рабочей процедурой, но автор сталкивался с компаниями, пренебрегающими этой работой. Не имея правила, требующего профилактического обслуживания компьютерных систем, организация рискует столкнуться с фундаментальными проблемами, угрожающими нарушить весь бизнес-процесс. Даже если вы считаете, что профилактическое обслуживание - это всего лишь текущая работа, все равно постарайтесь утвердить ее в виде предписания политики безопасности, чтобы гарантировать выполнение этой работы.
Размещение компьютеров и монтаж оборудования
Двадцать лет назад подготовка к размещению компьютеров означала, что находилось помещение с мощным основанием, устанавливались съемные панели фальшпола, подводилось силовое электропитание, устанавливался кондиционер, а также через стены и потолки пропускались кабели. Нагромождение проводов в офисе было обычным делом. Реконструированные шкафы для хранения инвентаря использовались в качестве кроссовых шкафов. Машинные залы были тесными, с неудобными подходами и плохо спроектированными. На двери был замок, так что только уполномоченный персонал мог туда входить. В принципе, компьютерные системы рассматривались как некие идолы, с которыми общались и приносили им жертвоприношения только жрецы информации.
Во время написания этой главы автор вспоминал также опасности, которые подстерегали всех, кто имел дело с компьютерами, вызванные плохим выбором места расположения машинных залов и распределительных щитов. Один из редакторов издательства рассказывал, что он работал в серверном зале, который находился в двух метрах от водопровода. Другая проблема заключалась в том. что кондиционирование воздуха для этой комнаты было отделено от кондиционирования остальной части здания, и вентиляционная отдушина была предназначена для выхлопа дизельных генераторов, запускающихся в случае непредвиденных ситуаций с электропитанием. Редактор вспомнил, что кто-то даже чуть не умер от ядовитых выхлопных газов, не желая покидать свой пост. Это говорит о том, что кроме сценариев атаки, физическая безопасность должна рассматривать много других ситуаций, которые могли бы повлиять на функционирование систем или сетей.
Революционное наступление персональных компьютеров и бурный рост сетевых систем изменили положение дел. Оборудование стали устанавливать в помещениях со встроенными в стены кабелями, с соединительными разъемами, введенными за пределы офиса. Сетевое оборудование устанавливают в специально спроектированных помещениях или "шкафах", а для серверов выделяется отдельное помещение внутри офиса. Но при таком серьезном подходе к компьютеризации, тем не менее никто особо не ломает голову при выборе места для размещения компьютерных центров. Их размещение в здании рассматривается скорее с точки зрения удобств, а не безопасности.
Многие, прочитав этот раздел, скажут, что это все должно быть и так очень просто и понятно. Нельзя не согласиться с такой оценкой. Но, к сожалению, автору приходилось сталкиваться со случаями, когда важные информационные системы устанавливались в помещениях со стеклянными стенами, с единственным источником электропитания, а также с ненадежными замками и дверями. В таких помещениях важные информационные системы могут легко стать объектом физических атак или аварийных ситуаций.
Правила физической безопасности касаются не
Правила физической безопасности касаются не только вопросов оружия, охраны и пропускных пунктов. При разработке этих правил необходимо также учитывать размещение оборудования, управление им, а также процедуры восстановления после аварийных ситуаций. В этой главе мы обсудили, как формулировать правила физической защиты инфраструктуры организации.
Создание средств управления доступом
Сотрудничая с компаниями различных размеров, включая правительственных подрядчиков, автору приходилось сталкиваться с всевозможными мерами, ограничивающими доступ в здания, компьютерные помещения и к шкафам с оборудованием. Чаще всего используют систему, основанную на идентификации специальных значков с фотографией пользователя и нанесенным на значки кодом, соответствующим предоставленному владельцу значка допуску или его статусу в организации, который соответствует его допуску. Чаще всего эти значки имеют магнитные полосы или другие метки, считываемые электронными устройствами.
Для небольших организаций такой тип управления доступом может быть и не обязателен. Однако это не означает, что вообще ничего не нужно предпринимать. В конце концов, вряд ли вам понравится, если кто-то зайдет к вам на узел и что-нибудь испортит. Следует помнить, что средства управления доступом устанавливаются для того, чтобы не допустить того, кому не положено, в запрещенные для них места. Так что независимо от размеров организации не стоит игнорировать разработку таких правил.
Независимо от наличия соответствующего правила, в организации необходимо регистрировать тех, кто имел доступ к оборудованию организации. Для этого служат и специальные пропуски в отдельные офисы, где можно получить доступ к компьютерам, используемым рядовыми служащими, или получить доступ к вспомогательному оборудованию типа кабельного хозяйства и коммуникационного оборудования. Если есть возможность физического доступа посторонних людей к коммуникационному оборудованию, то следует опасаться, что кто-то установит "жучки" или какое-нибудь другое прослушивающее устройство. В таком случае вся сеть будет скомпрометирована.
Правила доступа и промышленный шпионаж
О случаях промышленного шпионажа мы слышим ежедневно. Независимо от того, занимаются ли этим крупные корпорации, мелкие "выскочки", или даже правительственное шпионское ведомство, промышленный шпионаж представляет собой попытку одной компании (или страны) похитить информационные активы другой.
Существует масса способов хищения информации. Один из методов заключается в полунении доступа к сети и серверам, где хранится интересующая информация. Идея разработки правил управления доступом состоит в том, чтобы не допустить к информационным активам тех, кто занимается шпионажем. Для этого персонал, обеспечивающий безопасность компании, должен знать, кому разрешен доступ.
Одним из требований может быть проверка протоколов управления доступом, включая проверку журналов, в которых записываются те, кто посещал охраняемые зоны. Следует отметить, что это стандартные требования для тех, кто работает над секретными проектами федерального правительства. В любом случае в правила управления доступом должна быть включена четкая формулировка, требующая вести такие журналы и протоколы.
Управление доступом к оборудованию должно обеспечиваться автоматической идентификацией сотрудников, которая предусматривает процедуры добавления или исключения персонала из баз данных или списков. Эти процедуры должны быть контролируемые. Более того, должны храниться записи о том, кому дозволен доступ в каждую зону, где установлено определенное оборудование, а также журналы, по которым можно идентифицировать каждого, кто входил и выходил из охраняемой зоны.
Следует обратить внимание, что в этой простой формулировке правил не определены никакие технологии или процедуры. Таким образом, остается свобода выбора необходимых процедур. Если вопросами управления доступом в организации занимается отдел кадров, чтобы наделить его соответствующими полномочиями, можно дополнить формулировку:
...что касается разрешения доступа к оборудованию. Процедуры для управления доступом должны быть определены отделом кадров...
Что делать, когда ответственный работник, который занимался управлением доступом, подал заявление на увольнение? Естественно, вы захотите ограничить его или ее право доступа, но до какой степени? В некоторых компаниях уволившимся служащим позволено прийти в свой офис, чтобы забрать личные вещи.В других - для этого требуются сопровождающие и, в случае, если дело касается зон, требующих правительственного допуска, может даже потребоваться вооруженная охрана. Независимо от конкретной ситуации в вашей организации, в правилах должны быть учтены подобные моменты, касающиеся доступа. Следует учесть, что отдел кадров мог бы также заниматься этими вопросами, поэтому необходимо поработать с ними для включения в документ правил безопасности приемлемой для них формулировки.
Средства управления доступом
Чтобы лишние люди не могли попасть в помещение, можно построить стены и перегородки, но теперь нужно определить, кому разрешено входить в это помещение? Для того чтобы учесть в правилах безопасности все аспекты, касающиеся доступа, в них необходимо включить положения, касающиеся управления доступом, а также регистрации тех, кто имел доступ к информационным средствам. Те, кто пока не понимают, как эти положения правил дополняют друг друга, пусть попробуют перед разработкой правил монтажа оборудования написать правила доступа к оборудованию.
Восстановление после аварии
В приведенной выше формулировке правил говорится, что системный администратор должен располагать планом на случай непредвиденных обстоятельств. Не имеет значения, кто будет проводить в жизнь этот план. Даже в том случае, если ваша организация воспользуется наработками комитета по этому вопросу, все равно в правилах должна быть определенная формулировка, касающаяся разработки плана действий после аварии и реализации такого плана. Как и в случае со всеми остальными процедурами, необходима возможность периодического контроля и обновления этих планов. Таким образом, в формулировку правила можно добавить следующее.
Данный план восстановления после аварии должен подвергаться периодическому пересмотру в разумные сроки, с интервалом между пересмотрами не менее одного года. В процедуру пересмотра и контроля должен быть включен план по тестированию самой процедуры.
Замки и перегородки
Когда автор говорил представителям организаций о таких простых вещах, как двери и замки, в ответ, обычно, раздавался дружный смех. Чаще всего двери, замки и другие запорные приспособления не принимаются в расчет при монтаже оборудования. Однако, если вы собираетесь написать правила, гарантирующие, сохранность информационных активов в защищенных помещениях, не забудьте упомянуть в них о дверях и других запорных приспособлениях. Ненадежные двери могут оказаться слабым звеном в программе физической безопасности. Так что необходимо позаботиться, чтобы двери и другие запорные приспособления были неприступны для атаки (взлома).
При рассмотрении этих вопросов станет понятно, что надежность дверей по важности стоит на втором месте после управления доступом. Огнестойкие двери и перегородки могут предотвратить или снизить вероятность нанесения ущерба. Пожар вне комнаты не попадет внутрь, а пожар внутри помещения будет оставаться внутри и, возможно, будет ликвидирован не распространившись. Эти двери должны быть герметичными, стоит даже подумать об автоматически закрывающихся дверях, потому что они по-прежнему считаются надежным заслоном в случае пожара. В правилах нужно не только упомянуть о пользе использования дверей такого типа, но необходимо также включить формулировку, в которой говорится, что эти двери не должны быть постоянно открыты.
Администрирование электронной почты
То, как организация оперирует электронной почтой, также важно, как и использование системы. Правила безопасности и инструкции при подходящем случае становятся темой судебных процессов, основанием для жалоб и прочих хлопот, которые мешают работе организации или пользователей.
Другие аспекты работы с электронной почтой, будь то содержание посланий или их обработка, обычно не воспринимаются серьезно. А они являются реальными вопросами, так как находят порой отражение в скандальных делах и проблемах, связанных с электронной почтой и отражающихся на безопасности организации. Правила безопасности электронной почты должны устанавливать определенные обязанности и для пользователя, и для администратора.
Следует заметить, в этом разделе речь идет о том, что организация сама управляет собственными службами электронной почты. Если организация пользуется внешними услугами для обеспечения работы электронной почты, то следует проверить контракт, чтобы убедиться, что провайдер услуг управляет системами электронной почты в соответствии с принятыми в организации правилами. Однако, если организация пользуется онлайновыми услугами провайдера, такого как AOL (America Online), то правила будут регламентировать, в основном, пользование этими услугами и почти не затрагивать администрирование.
Архивирование электронной почты
Не стоит легкомысленно относиться к хранению и обновлению заархивированной электронной почты, поскольку если бы компания Microsoft руководствовалась собственными правилами, то сообщений, используемых правительством, могло бы уже и не существовать. Это не означает, что автор книги поддерживает использование электронной почты для якобы незаконной деятельности. Но если организация собирается разработать правила, то следует позаботиться, чтобы они были реалистичными, и руководствоваться ими в работе.
Правила архивирования и хранения содержат два компонента. Во-первых, нужно декларировать, что электронная почта будет архивироваться. Во-вторых, необходимо установить временные параметры хранения электронной почты. Также, как это делалось при разработке других правил, лучше было бы перенести вопросы, касающиеся используемых типов памяти и объемов хранимой информации, в документы по внедрению. Однако, необходимо включить в правила некоторые указания.
Организация должна сохранять и архивировать все сообщения электронной почты, которые проходят через ее сервер. Архив должен храниться на включенном в сеть запоминающем устройстве. Администраторы должны переносить архивированные сообщения на автономное запоминающее устройство каждые шесть месяцев, удаляя эти сообщения из оперативных запоминающих устройств.
Организация должна сохранять сообщения на этом автономном запоминающем устройстве, по крайней мере, два года, но может, по решению руководства, хранить его и дольше. Сообщения на автономном запоминающем устройстве должны быть стерты, или носитель должен быть уничтожен в соответствии с принятой для этого носителя технологией.
Некоторые более крупные организации, в особенности правительственные подрядчики, могут столкнуться с проблемами при создании единого правила для архивирования и хранения. От них, на основании контракта, могут потребовать руководствоваться правилами, отличными от тех, которые разработаны в организации. В таком случае организация может включить следующую формулировку в правила.
Организация должна дополнить правила, чтобы удовлетворить требования контракта, но без пересмотра правил. Данные изменения должны касаться только тех полъзователей, которые выполняют работу по настоящему договору, и организация должна уведомить этих пользователей о внесенных изменениях до их внедрения.
Цифровая подпись электронной почты
Еще одна особенность в использовании электронной почты заключается в том, что сообщение может быть сформировано, не показывая реального отправителя. Это называется спуфингом или имитацией соединения. Несмотря на то, что он используется теми, кто отправляет по собственной инициативе большое количество незатребованных сообщений (широковещательная рассылка сообщений), этот метод можно также использовать в качестве средства промышленного шпионажа. По такому сценарию сообщения отправляются пользователям организации так, будто они приходят из знакомого источника, пытаясь спровоцировать пользователей на отправку в ответ патентованной информации.
Пользователи могут установить контакт с подозрительным адресатом, запрашивающим информацию, чтобы убедиться в том, что запрос отправлен именно этим пользователем. Но культура электронной почты настолько доверительна, что такую операцию выполняют очень редко. Единственный способ гарантировать, что сообщение является корректным запросом, — сопроводить сообщение цифровой подписью. Цифровые подписи являются составной частью системы шифрования, которая использует криптографические алгоритмы для создания числовой величины, уникальной для вашего сообщения. Как и шифрование, правила управления цифровыми подписями лучше ввести в документы правил шифрования. Опять-таки, можно вставить дежурную формулировку в правила безопасности.
Любой запрос на патентованную информацию должен сопровождаться цифровой подписью, и зта подпись должна сверяться.
Пользователи, пересылающие патентованную или секретную информацию, должны "подписывать" сообщения цифровой подписью, чтобы продемонстрировать получателю, что сообщение, легитимно и зарегистрировано.
Использование цифровой подписи должно осуществляться в соответствии с принятыми в организации правилами шифрования.
Использование электронной почты для конфиденциального обмена информацией
Не любого легко убедить, что сообщения электронной почты являются электронным эквивалентом почтовых открыток. Информация, которая передается через Internet, проходит в виде читабельных байтов, доступных каждому, кто может их считать. Поскольку трафик проходит от одной сети к другой, вероятность того, что кто-нибудь прочитает сообщение, увеличивается. Кроме того, если сообщение по ошибке попадает не в тот почтовый ящик, то можно непреднамеренно раскрыть информацию, которую раскрывать нельзя.
После того, как сообщение покидает систему, отправитель не может контролировать, кто может прочитать сообщение, и даже не знает, попало ли оно по назначению. По этой причине некоторые организации создают правила, которые не разрешают отправлять по электронной почте конфиденциальную или патентованную информацию. В других организациях принимают правила, разрешающие пользователям пересылать конфиденциальную информацию только внутри организации, но запрещающие отправлять такую информацию сторонним пользователям.
Обработка электронной почты
Клиент стал беспокоиться о разработке правил эксплуатации электронной почты после того, как бывший служащий затеял судебный процесс против организации. Это была небольшая компания, насчитывающая менее 70 пользователей, и вопрос касался добавления в правила информации об архитектуре. После изучения этого запроса автор книги получил копию приказа о смещении с должности системного администратора. Юрист истца запрашивал, каким образом организация управляет маршрутизацией электронной почты, и записано ли это в правилах безопасности.
Автор книги просмотрел приказ об увольнении и другую вспомогательную документацию и пришел к выводу, что в системе, построенной на самой передовой архитектуре, можно найти детали, которые могут стать уликами против организации. Автору пришлось написать формулировку правил, которая позволяла бы организации разработать архитектуру системы, но такую, чтобы ее технические решения не могли стать зацепкой в суде. Она выглядела следующим образом.
Системные администраторы и администраторы безопасности должны совместно разработать архитектуру системы электронной почты таким образом, чтобы обеспечить надлежащую доставку сообщений как внутри организации, так и в Internet. Помимо всего прочего эта система должна допускать использование посреднических программ, переадресации, шлюзов и ручного вмешательства в управление этой службой.
Несмотря на то, что данная формулировка очень обобщенная, она удовлетворяет любое архитектурное решение и удовлетворит юристов организации.
Ограничение размеров сообщений электронной почты
Пользователи электронной почты сильно способствуют пользователям сети в создании изощренных сообщений и, тем самым, пересылке большого объема данных тем, что отправляют почту, присоединяя к сообщению файлы, хранящиеся в системе или сети. С каждым новым форматом файлов объем информации, заполняющей полосу пропускания сети, увеличивается. В одном хорошо известном университете установили, что больше половины сообщений электронной почты, проходящих через его серверы, содержали вложения, записанные в новейшем и популярном аудиоформате.
Это проблема не только университетов. В некоторых организациях было замечено, что пользователи посылали документы коллегам по электронной почте, не используя сетевые файловые серверы в качестве общего запоминающего устройства. Для управления ресурсами, используемыми электронной почтой, в некоторых организациях обновляют правила безопасности электронной почты, включая в них ограничения на размер пересылаемого файла.
Правило ограничения размеров сообщений электронной почты может просто сводиться к тому, чтобы запретить отправлять сообщение, превышающее определенный размер. Однако, бывают случаи, когда необходимо сделать исключение. В одной из организаций, с которой сотрудничал автор книги, библиотекарю нужно было отправлять и получать объемные сообщения от клиентов. Организации необходимо было иметь более гибкие правила, а не просто установить для всех одинаковое ограничение размера сообщения. Поэтому они приняли решение разработать правило, включающее формулировку, в которой говорилось, что руководство может делать исключения. Формулировка выглядела следующим образом.
Размер сообщений электронной почты, отправляемых и получаемых пользователями, в целом, не должен превышать 40 Кбайт. Исключения делаются для пользователей, условия работы которых требуют больших размеров сообщений. Администратор должен расматриватъ и разрешать исключения индивидуально.
Правила безопасности электронной почты
Мы быстро внедряем новые технологии, если они служат улучшению коммуникаций. Бурное развитие электронной почты только подтверждает это. Но электронная почта не является панацеей для всех. Помимо того, что электронная почта облегчает обмен информацией между людьми, ее используют для пересылки конфиденциальной информации, она является источником беспокойства для других пользователей, вовлечения их в нелегальную деятельность, а также ее информация может служить уликами против компании в судебных процессах.
За последние годы действительно было несколько судебных процессов, которые основывались на доказательствах, извлеченных из архивов электронной почты. Недавно в антимонопольном судебном процессе Соединенные Штаты против компании Microsoft государственные юристы использовали заархивированную электронную почту администрации Microsoft в качестве улики против компании Microsoft. Это заставило многих сфокусировать внимание на правилах использования и обработки отправленной и принятой электронной корреспонденции.
Электронное послание является эквивалентом почтовой карточки. По этой причине требуются особые подходы к электронной почте. При разработке правил безопасности электронной почты организация должна рассмотреть массу вопросов, начиная с архивного хранения и заканчивая инструкциями по оформлению содержимого посланий.
Правила использования электронной почты
Электронная почта появилась одновременно с Internet. Сообщения отправляются практически в реачьном времени и совершенно ненавязчиво. Получатель не должен немедленно читать сообщение, потому что это не телефонный звонок. Такой подход даст отправителю возможность тщательно сформулировать сообщение.
Но эта "освященная веками" пересылка информации накладывает определенную ответственность, о чем не должны забывать разработчики правил безопасности. При создании правил безопасности электронной почты рекомендуется, чтобы основные правила работы и инструкции, которыми должны руководствоваться пользователи, были изложены в правилах безопасности электронной почты в первую очередь. Один клиент решил, что для привлечения внимания пользователей ему стоит включить "Десять заповедей использования электронной почты". Использование формулировок правил безопасности такого типа представляет собой творческий путь создания впечетляющих правил, предписания которых будут выполняться. Хотя пришлось их подредактировать, чтобы соблюсти конфиденциальность клиента, ниже представлены эти заповеди.
Сообщения электронной почты являются эквивалентом
Сообщения электронной почты являются эквивалентом почтовых открыток. По этой причине требуются особые подходы при разработке правил безопасности электронной почты. При разработке правил безопасности электронной почты организация должна рассмотреть массу вопросов, начиная с архивного хранения и заканчивая инструкциями по оформлению содержимого посланий.
Шифрование электронной почты
Третьим вариантом является разработка правила, требующего шифровать перед отправлением конфиденциальную и патентованную информацию. Зашифрованное сообщение может быть прочитано только тем получателем, кому оно предназначено. Однако, использовать шифрование и оперировать им нужно обдуманно. Существует много вопросов, таких как распределение ключей, возврат ключей и ограничение пересылки ключей, которые выходят за рамки правил работы с электронной почтой. Несмотря на то, что правила шифрования будут рассмотрены позже (см. главу 9 "Шифрование"), в правила безопасности электронной почты можно включить формулировку, подобную следующей.
Патентованная информация, отправляемая сторонним пользователям, должна шифроваться перед отправлением. Использовать шифрование нужно, руководствуясь действующими в организации правилами шифрования информации.
Сканирование электронной почты
Последние несколько лет электронная почта использовалась для распространения вирусов в Internet. Для борьбы с такими проблемами многие администраторы устанавливают в своих сетях средства сканирования вирусов. Это может оказаться хорошим решением, но существует ли правило для установки таких средств? В нашем противоречивом мире могут и не разрешить что-то делать с информацией, извлеченной без разрешения, записанного в официальном документе.
Правила сканирования содержимого позволяют организации просматривать содержимое сообщений. По разным причинам некоторым организациям необходим контроль содержимого электронной почты, чтобы предотвращать проблемы или утечку конфиденциальной информации. Проблема заключается в том, что правила сканирования содержимого задевают этические проблемы. Ощущение такое, словно организация заглядывает через плечо пользователям, поскольку она им не доверяет. В некоторых организациях, которые создавали в коллективе "семейную" атмосферу, было заметно, что коллектив не одобряет эту практику. В других организациях это воспринималось как необходимое зло.
Решение заключается в составлении формулировки правил, которая позволит организации сканировать всю электронную почту с учетом целей, которые поставлены успешным проведением бизнеса. Если организация проводит сканирование в поисках вирусов или других проблем, то это должно быть оговорено в правилах. Независимо от правил, если организация приняла решение сканировать электронную почту, то должно быть что-то вроде открытого доступного документа, в котором разъясняется, с какой целью проводится сканирование.
Для проведения сканирования в поисках вирусов формулировка правил может быть следующей.
Организация должна сканировать каждое сообщение электронной почты, которое проходит через сервер, чтобы проверить его на наличие компьютерных вирусов, "червей" или других исполняемых файлов, которые представляют угрозу безопасности сети. Инфицированная электронная почта не должна доставляться пользователю.
Администраторы должны разработать процедуры обработки инфицированных сообщений электронной почты.
Для сканирования содержимого формулировка может быть такой.
Организация имеет право сканировать содержимое каждого сообщения электронной почты, которое проходит через ее серверы, на основе заранее установленных критериев. Если сообщение не соответствует критериям, то оно не должно доставляться полъзователю.
Администраторы должны разработать процедуры для обработки забракованных сообщений. Руководство должно располагать средствами для внедрения таких правил, включая, помимо всего прочего, дисциплинарные меры для пользователей или правовые санкции для лиц, не являющихся пользователями.
И, наконец, к любому разделу можно добавить следующее.
Организация должна сделать доступным перечень того, что будет сканироваться на сервере.
Введение права на контроль электронной почты
Самое распространенное приложение Internet может оказаться и самым опасным. Электронная почта может использоваться для пересылки секретных данных, оскорблений и создавать проблемы для службы безопасности. Все проблемы можно решить, если организация контролирует трафик электронной почты и содержимое посланий, а также архивирует сообщения, чтобы в будущем можно было разобраться в возникшей проблеме. Если в чем-то вы сомневаетесь, то необходимо проконсультироваться с юристом, чтобы выяснить, что законно, а что противопоказано в этой работе. Если этого не делать, то право на мониторинг, так же как весь режим работы электронной почты и архивирование сообщений пользователей, должно быть установлено правилами безопасности, а периодический просмотр электронной почты может быть основой контроля за их соблюдением.
Правила безопасности Internet
Адресация сети и архитектура
Довольно сложно понять, как можно использовать в программе безопасности сетевую архитектуру и схемы адресации. Стедует помнить, что целью обеспечения живучести сети является обеспечение передачи информации даже в случае сбоев, атак и других происшествий. Правильно выбранная сетевая адресация и архитектура сети поможет в достижении этих целей с помощью правил, требующих тщательного планирования, и особого внимания к элементам адресации сети, а также к возможности расширения сети.
Адресация сети
Никаких магических формул использования адресации сети для зашиты информации нет. Существует определенная защита, которая скрывает или маскирует адреса сети. Одним из ключевых элементов информации, который могут использовать для определения слабых мест сети, является доступ к списку задействованных адресов. Задействованные адреса могут существенно облегчить задачу по выяснению того, какие системы могут быть активными и подходящими для атаки. Существует два способа решения этой проблемы: конфигурация службы именования доменов и преобразование адресов сети.
Аутентификация и безопасность сети
Безопасность сети охватывает не только Internet, но и любое сетевое подключение или интерфейс. Насколько строго обеспечивается защита любых интерфейсов, зависит от требований, предъявляемых к ним, их функционального назначения и степени доверия между обеими сторонами подсоединения. Правила защиты всей сети и внутрисетевых подключений являются частью программы безопасности сети, которая охватывает такие вопросы, как адресация сети, подсети и средства управления подключениями к сети.
Доверительные взаимоотношения устанавливаются путем четкого определения того, какую информацию можно передавать через внутренние соединения. Что касается доступа к информационным ресурсам, то стержнем проблемы управления доступом является обеспечение доступа к системе и ко всей сети. Аутентификация используется для подтверждения этого права доступа. В данной главе обсуждаются вопросы, как формировать политику, которая бы рассматривала архитектуру сети в качестве механизма защиты. Мы обсудим различные аспекты аутентификации и управления доступом к сети, а также все, что необходимо для защиты удаленных точек доступа.
Безопасность регистрации
Итак, к сети применены все меры предосторожности, архитектура поддерживает бизнес-план компании и политику безопасности, а оборудование защищено физически. В конечном счете, мы находимся у места регистрации, где пользователь или служба идентифицирует себя и предъявляет какой-то тип мандата для вхождения в систему. Отсутствие четких правил регистрации подобно строительству наилучшей атомной подводной лодки с использованием ширмы в качестве люка.
Безопасность связи по телефонным каналам
Когда речь идет об информационной безопасности, модем ничем не отличается от других точек доступа к сети. Модемы являются точками входа в сеть и, несмотря на то, что правилами может быть не разрешено, но входящий звонок может быть набран необязательно законным пользователем, в общей программе безопасности это должно быть обязательно учтено.
В первую очередь необходимо рассмотреть управление телефонными номерами. Как правило, большинство компаний не публикуют номера, закрепленные за модемами. Однако одна из компаний, с которой сотрудничал автор, опубликовала эти номера, поскольку хотела, чтобы в любое время клиенты имели возможность установить контакт с ее представителями. В результате, была опубликована телефонная книга с перечнем "МОДЕМ 1", "МОДЕМ 2" и т.д. Вскоре после публикации на эти модемные линии стало поступать необычное количество звонков. Поэтому, с точки зрения здравого смысла, стоит включить в правила следующую формулировку.
Телефонные номера, используемые для входящих модемных линий, не должны публиковаться ни в каких каталогах, которые могут быть доступны каждому, кто не имеет права доступа.
Другой пункт правил защиты модемов устанавливает требование периодической замены телефонных номеров. Есть компании со строгим доступом и жесткими требованиями службы безопасности менять телефонные номера доступа всякий раз после реорганизации штата служащих или завершения проектов. Однако, проведение такой политики требует очень напряженной работы руководства. Ведь помимо изменения номеров нужно информировать и тех, кому необходимо знать об этих изменениях. Кроме того, надо позаботиться о том, чтобы номера были выбраны из списка незадействованных номеров. Да и материально-техническое обеспечение процедур данного типа может бьпь настолько сложным, что проведение такой политики неприемлемо для большинства предприятий.
В дополнение к стандартным средствам управления доступом, можно рассмотреть возможность расширения системы аутентификации, необходимость в которой появляется при подключении к сети посредством модемов.
В качестве примера можно привести использование одноразового пароля или алгоритма защиты с применением ключей для защиты пользователей модемов. Однако, это не единственный способ, позволяющий обеспечить доступ в сеть только разрешенному удаленному пользователю. Прежде, чем зафиксировать это в правилах, необходимо познакомиться с технологиями, которые применяются в вашей организации. Обычно с ними знакомятся в процессе обследования объекта. Даже если еще не установлены расширенные системы аутентификации, в правилах должно быть отражено только то, что уже есть в наличии, или просто нужно составлять формулировки правил доступа в общем виде, оставляя подробности на усмотрение администратора.
Получение доступа к сети посредством модемов, подключенных к телефонным каналам, должно сопровождаться дополнительным этапом аутентификации, чтобы гарантировать законность этого доступа.
Другие проблемы адресации
Некоторых людей шокирует количество вопросов, которые им необходимо рассмотреть, чтобы постичь то, что на первый взгляд кажется довольно простым. Но если иметь четкие правила адресации каждого важного элемента сети, можно избавить администраторов сети от необходимости управлять различными схемами. Правила адресации должны учитывать способ назначения адресов. Ниже перечислено, что должно быть учтено при назначении адресов.
Все эти схемы имеют свои преимущества, но общепринято использовать постоянные или предписанные адреса даже в том случае, если они получены с помощью DHCP. Обновляя карту адресов сети, сетевые диспетчеры (люди или автоматизированные системы) смогут легко определить, кто отвечает за сетевой трафик. Чтобы пользоваться такой схемой, в правила может быть включена следующая формулировка.
Адреса сети должны быть предварительно определены для каждой системы и сетевого устройства и могут загружаться заранее или быть сформированными перед подключением к сети.
Те же выводы могут быть сделаны относительно адресации сети, не использующей IP-адреса. Например, IPX-адреса в среде Novell Netware или сформированные с помощью WINS (Windows Internet Naming Service— служба межсетевых адресов в среде Windows) для сети Microsoft также имеют подобные свойства и должны подчиняться тем же правилам.
Кроме того, в правила формирования адресов можно добавить строку, дающую право защищать адреса и серверы от тех, кто не имеет права доступа к ним. Эти правила могут быть написаны так, чтобы они подходили и для других адресных серверов и контроллеров, таких как устройство NAT или DNS. Формулировка правил может быть следующей.
Серверы сетевых адресов и серверы, которые используются для формирования адресов, должны быть защищены всеми доступными для этих устройств способами.
Хранение паролей
Основное правило заключается в том, что пароли нельзя хранить так, чтобы каждый имел возможность их прочитать. Правилами в этом деле оговаривается шифрование паролей с применением сгенерированных ключей или даже способы хранения паролей систем или сетей, где они могут быть считаны с использованием основных методов доступа.
Это — формальное определение. В большинстве случаев вам не удастся управлять хранением или пересылками паролей. Пока не разработано собственное прикладное программное обеспечение, управление паролями обычно возлагается на операционную систему или на используемое программное обеспечение. В таком случае нет необходимости включать в правила формулировку, касающуюся хранения паролей. Однако для полноты картины стоит все-таки привести следующую формулировку.
Хранить пароли нужно, исходя из требовании системы, сети или используемого программного обеспечения. В эти требования должно быть включено условие неизменяемости приемов сохранения паролей в тайне.
Конфигурация службы именования доменов
Служба имен доменов (DNS— Domain Name Service) используется для преобразования системных имен в цифровые адреса. Ее также можно использовать для обратного преобразования цифровых адресов в системные имена. Тот, кто сумеет узнать имена или адреса, сможет использовать DNS для преобразования их во что-то более понятное. Несмотря на то, что многие люди представляют себе это как довольно неопасную форму атаки, однако имена могут дать атакующему огромное количество информации. Например, если кто-то имеет сетевые адреса организации и все точки отображения системных адресов, именуемые кадры (hr) или расчет (acct), он может попытаться проникнуть в эти системы в целях поиска информации. Кроме того, у взломщиков появится возможность определить архитектуру сети. Эта информация, полученная внешними пользователями, может помочь им определить структуру организации независимо от ее размеров и сферы деятельности. Когда автор работал с компанией, в которой было не более 100 пользователей, свободно обменивающихся информацией, было обнаружено, что в главную систему было осуществлено несколько вторжений пользователями Internet. Эта система являлась "главным сервером" компании и содержала много информации о компании. Даже после того как система была отделена от сети, поставлен маршрутизатор и написаны правила, разрешающие доступ к ресурсам только внутренним пользователям, попытки взлома этой системы продолжались. Посте проведенной в компании работы по преобразованию системных имен и изменению адресов для многих серверов была создана система 2-DNS.
Главная причина создания системы 2-DNS заключалась в организации службы преобразования имен внутренних пользователей в осмысленные имена, и в то же время в обеспечении преобразования имен в "обезличенные" имена для Internet в соответствии со стандартом DNS. В этом двойном подходе DNS внутренний сервер имен становился недоступен из Internet, и в то же время устанавливались системные имена, которые были понятны пользователям организации.
При конфигурировании систем организации следовало учитывать, что они должны пользоваться сервером имен для преобразования адресов. Вторая часть системы была установлена так, чтобы быть доступной из Internet, но содержала другой набор имен для внешних пользователей. На рис. 5.2 показано, как это может быть реализовано.
Некоторые более мелкие организации пользуются услугами сторонних организаций для связи с Internet, и не имеют прямого доступа к собственным входам DNS. Это не является проблемой, пока администратор может запрашивать, какие были сделаны изменения. В любом случае было бы лучше разработать политику, которая предусмотрела бы создание в системе открытой части, в которой предоставлялось бы информации не больше, чем это необходимо. Можно включить в политику следующую формулировку.
Для обеспечения групповыми именами доступных внутренних систем необходимо следующее: служба сетевых имен должна обеспечить пользователей Internet условными именами, понятными для внутренних систем, а достоверные имена присвоить пользователям для работы во внутренней сети организации.
Рис. 5.2. Использование двухсистемной DNS для сокрытия внутренних имен
Перед осуществлением таких изменений организация должна рассмотреть множество вопросов. Некоторые из них касаются того, как внутренняя DNS будет преобразовывать адреса, размещенные в Internet, для внутренних пользователей, а также соглашений о присваивании имен и доступности к каждой системе DNS. Есть и другие вопросы. Необходимо рассмотреть последствия проведения такой политики - как это отразится на внедрении мер безопасности. Несколько разделов было посвящено именно этой теме. Возможно, это не самый лучший подход для вашей организации, поэтому нужно удостовериться, что это имеет смысл именно для ваших условий.
Ограничение количества регистрации
После того, как пользователь зарегистрировался в системе, может возникнуть необходимость ввести определенные ограничения на его или ее сеанс работы в системе. Если пользователь работает с важной информацией, то может появиться необходимость ввести в правила предписание, требующее блокирование доступа этого пользователя к информации других пользователей, или же выход из сети одновременно с другими пользователями. Те, кто имеет доступ к важным данным, должны понимать, какие возможны последствия, если зарегистрированную рабочую станцию оставить без присмотра при просмотре документов. В дополнение к правилам необходимо проводить инструктаж пользователей, чтобы они ни при каких обстоятельствах не нарушали секретность своего сеанса работы в системе.
Другим хорошим инструментом ограничения сеанса является ограничение времени работы пользователя в системе (например, только в течение рабочего времени) или же автоматический выход из системы посте истечения определенного времени бездействия станции, или выход в определенное время дня. Зачастую правила ограничения времени холостой работы рабочей станции или времени сеанса могут оказаться бесполезными. Во многих случаях они комбинируются с другими ограничениями сеансов работы в системе, чтобы создать основательную формулировку правил.
Пользователи обязаны разрегистрировать свою рабочую станцию, когда не работают на ней. Администраторы должны разработать процедуры, гарантирующие безопасность неиспользуемых рабочих станций путем их автоматической разрегистрации или другими способами, ecли они не являются активными в течение определенного периода времени, установленного во время обследования объекта.
Отчетность при регистрации
Существует два типа требований по отчетности, которые рекомендуется добавлять в документы, составляющие политику безопасности. Первый заключается в протоколировании в системном журнале каждой попытки войти в систему. Обычное протоколирование или специальные средства обнаружения вторжений могут использоваться администратором, чтобы следить за выполняемыми операциями. Их также используют для наблюдения за работой системы и для разработки шаблонов применения средств обнаружения. Эти шаблоны могут использоваться более сложными средствами для обнаружения уязвимых мест системы.
Другое требование заключается в том, чтобы пользователь имел возможность определить, когда и откуда была сделана последняя попытка войти в систему. Несмотря на то, что многие пользователи игнорируют эту информацию, есть шанс, что необычные попытки получения доступа будут отмечены. Один из администраторов, с которым пришлось сотрудничать автору, пытался помочь пользователю, у которой были проблемы с рабочей станцией. Когда он стал протоколировать каждую регистрацию пользователя в системе, в сообщении о "последней регистрации" было обнаружено, что пользователь была зарегистрирована в 4 часа утра, в воскресенье. Это выглядело довольно странно, поскольку в это время она отсутствовала в городе, так как выезжала в горы кататься на лыжах. Администратор смог на основе этой информации определить, что кто-то взломал сеть. В документах политики безопасности этот момент не был учтен, поэтому, когда выяснилось, насколько легко пробить защиту, этот момент добавили в соответствующие правила.
Ответственность служащих
Если бы мы жили в идеальном мире, то можно бы было верить в то, что все служащие будут выполнять свою работу правильно и честно. Но поскольку мы живем в мире, далеком от совершенства, приходится заботиться о том, чтобы служащие, работая вне офиса, выполняли все правила и инструкции компании. Чтобы это было узаконено, добавьте приблизительно такую формулировку в правила информационной безопасности.
Служащие, которым предоставлен удаленный доступ к сети организации, должны руководствоваться в работе правилами и инструкциями защиты оборудования, данных и сетевого доступа так же, как если бы они работали на основной площадке организации.
Однако, этого может оказаться недостаточно. Работающие вне офиса должны также быть ознакомлены с инструкциями по удаленному контролю, с правилами лицензирования программного обеспечения, с правилами создания резервных копий и прочими инструкциями, действующими в организации. Чтобы усилить формулировку правил, можно добавить следующее.
При работе вне офиса пользователи должны использовать только лицензионное программное обеспечение, исполнять все инструкции по созданию резервных копий, а также руководствоваться в своей работе существующими в организации инструкциями.
Пароли
После имен пользователей пароли становятся второй линией защиты против незваных гостей. Можно тщательно назначать и поддерживать пользовательские имена, но в один прекрасный день неудачно выбранный пароль может позволить кому-нибудь войти в сеть. Правила назначения паролей делятся на две категории: какую структуру имеют действующие пароли и способы хранения этих паролей.
Планирование сети
Уровень планирования сети зависит от размера организации. Организация с небольшим количеством узлов может работать в объединенной сети с простыми сетевыми технологиями. Они основываются на доверительных отношениях, базирующихся на непосредственных контактах. Однако даже небольшим организациям имеет смысл использовать архитектуру сети, базирующуюся на управлении доступом.
Другой подход к этому вопросу называется "управлением трафиком". Сетевые планировщики могут помочь в ограничении доступа к секретным и важным данным, изолируя системы поддержки и сети от основного сетевого трафика. Для этого существует множество технологий, в том числе ограничительные шлюзы, брандмауэры и воздушные зазоры (air gaps). Тем не менее, независимо от используемой технологии, можно разработать правила, предписания которых будут гарантировать, что в планировании сети будет рассматриваться использование архитектуры в качестве механизма защиты информации.
Например, можно строить политику безопасности, используя определенную архитектуру сети в небольшой компании, в которой меньше 50 пользователей, очень немногочисленный персонал и маленький отдел бухгалтерии. Системы в таких компаниях содержат важную информацию, которая, по крайней мере, в отношении трудовых ресурсов, должна быть защищена законом. Изначально администраторы размещали такие системы в сети и полагались на создание подсети, используя адреса и сетевые маски. Входящий и исходящий трафик связывал такие системы с единой сетью, в которой были расположены другие системы офиса. Компания хочет обеспечить более высокий уровень управления потоками информации между этими системами. Это решается путем отделения административных систем от остальных систем организации и использования шлюза для управления трафиком. На рис. 5.1 изображена сеть и предлагаемые изменения в ней. Чтобы они были осуществлены, необходимо дополнить правила безопасности формулировкой, наподобие следующей:
Отдел кадров, бухгалтерия и другие административные системы должны быть физически отделены от основной сети, чтобы таким образом управлять входящими и исходящими потоками информации в этих системах.
Рис. 5.1. Сеть, включающая подсети, реконфигурированная для отделения административных систем. Обратите внимание, что реконфигурированная сеть не требует специфических адресов
Отметим, что в формулировке правил ничего не говорится о том, каким образом должно быть осуществлено это отделение. Это позволяет использовать новые технологии или оригинальные подходы без необходимости изменений в документах политики. Кроме того, ничего не говорится о том, каким образом будет осуществляться управление информацией. Автор в практической своей работе столкнулся со случаями, когда некоторые люди предлагали составить формулировку правил, которая устанавливала бы определенные требования к типу фильтрации или маршрутизации. Не стоит вводить такие требования, поскольку они могут измениться вместе с технологией, и придется обновлять документы политики.
Пользовательский интерфейс
Обычно пользовательский интерфейс зависит от алгоритмов, заложенных в базовой операционной системе или в программном обеспечении. За некоторыми исключениями, когда есть серьезные основания для изменения интерфейса, правила безопасности могут требовать, чтобы интерфейс пользователя оставался неизменным. Однако системы, построенные на основе расширенных интерфейсов, например, некоторые сетевые операционные системы или системы с инфраструктурой открытого ключа (PKI — public key infrastructure) позволяют делать замены или дополнения к алгоритмам операционных систем, благодаря чему они воспринимаются как более безопасные версии интерфейса.
В зависимости от конкретных условий в формулировке правил управления интерфейсом может быть написано, что интерфейс, предоставленный разработчиком системы аутентификации, изменять нельзя. Альтернатива заключается в том, чтобы алгоритм, используемый для аутентификации, строился на основе других правил.
Областью, в которой ограничения могут быть довольно эффективными, является определение процесса ввода паролей. Чтобы были гарантии того, что во время ввода нельзя перехватить пароли, правилами можно ограничить отображение паролей во время ввода, требовать, чтобы пароль был введен за определенный промежуток времени, разрешать ограниченное количество сбоев при вводе, а также требовать, чтобы пароли не пересылались в читабельной форме.
Интересный вопрос заключается в том, что отображать при введении пользователем пароля. Некоторые виды программного обеспечения выводят звездочки или другие символы при каждом нажатии клавиши. Однако если кто-то заглянет через плечо пользователя, пытаясь увидеть пароль, то он сможет увидеть длину введенного пароля. Зная, какое количество клавиш было нажато, т.е. ограниченный набор комбинаций, кто-то может попытаться определить пароль. Давайте рассмотрим этот вопрос с математической точки зрения. Если пароль состоит из любых печатаемых символов набора ASCII (American Standard Code for Information Interchange — Американский стандартный код для обмена информацией), то существует 96 возможностей для каждой позиции символа. Если пароль не короче 6 символов и не длиннее 10 символов, то количество возможных комбинаций символов будет следующим: 966+967+968+969+9610.
Это составляет более 6.7x1019 возможных комбинаций. Теперь, если нам известно, что пользователь ввел только семь символов, то количество комбинаций уменьшится до 7.5x1013. Однако, если мы видели, что пользователь в качестве первого символа нажимает клавишу "S", то количество комбинаций уменьшится до 2(7,8x1011).
В большинстве случаев мы не можем контролировать методы, применяемые программным обеспечением или операционной системой при вводе пароля. Однако можно разработать правила, предписания которых требуют, чтобы интерфейс не отображал количество символов пароля.
И, наконец, интерфейс должен быть таким, чтобы после ввода пароля он не передавался в систему в читабельной форме. Одна из проблем аутентификации по умолчанию, используемой в интерфейсах всемирной "паутины" (Wold Wide Web), заключается в том, что они передают пароль через Internet в форме, которую легко расшифровать. Эти пароли могут быть перехвачены и тайком использованы. Если это возможно, правила не должны разрешать ввод паролей такого типа, особенно для производственных систем. Один из способов, применение которого можно оговорить в правилах, заключается в применении одностороннего криптографического хэша (hash). По этому методу хэш-функция преобразовывала бы пароль в числовое значение фиксированной длины на базе введенной пользователем информации. Это значение фиксированной длины передавалось бы затем на сервер, где подвергалось другому хэш-пересчету, а потом сопоставлялось с информацией, хранящейся в системе. Таким образом, передается и хранится на сервере только хэш, а не сам пароль.
Использование одностороннего криптографического хэша является лишь одной из деталей реализации. Можно к этому добавить и другие концепции, чтобы формулировка правил имела, приблизительно, такую форму.
Пользовательский интерфейс при вводе паролей должен позволять пользователям вводить свои пароли без показа каких бы то ни было характеристик ввода. Эти пароли не должны передаваться в сеть в читабельной форме.
Несмотря на то, что правилами
Несмотря на то, что правилами вроде бы было предусмотрено, что пароль не сможет быть использован повторно в течение двух лет, ошибкой создателей этой базы данных было то, что они рассчитывали на изменение пароля ежемесячно согласно истечению его срока действия. Однако, поскольку автор книги использовал свое присутствие в системе и, соответственно, пароль для тестирования, он в течение трех месяцев заполнил базу назначенных паролей, чем продемонстрировал несостоятельность таких допущений.
Независимо от используемого критерия, необходимо, чтобы действие его было обеспечено для всех пользователей одинаково.
На основе всех этих соображений можно составить образец формулировки правил наподобие следующей.
В учетной записи каждого пользователя должен содержаться его собственный пароль. Действующий пароль должен состоять из комбинации букв, цифр или специальных символов; состоять, не менее чем из восьми символов, и оставаться действующим в течение 90 дней после последнего изменения. Пароль нельзя использовать повторно, по крайней мере, в течение 24 месяцев после его последнего использования.
Правила назначения действующих паролей
Хорошие правила назначения действующих паролей предусматривают генерацию паролей, которые разгадать непросто. Несмотря на то, что концепция сложности разгадывания выглядит несколько абстрактно, общепринятая установка заключается в том, что пароль должен представлять собой смесь букв, цифр или особых символов, а не просто слово, которое можно найти в словаре. Другой способ предотвращения разгадывания паролей заключается в хранении так называемых "социальных словесных конструкций" для каждого пользователя. Эти конструкции можно применять в качестве шаблона при сопоставлении с ними вводимых паролей, и пользователям не будет позволено использовать эти данные в своих паролях. Эта информация может содержать имена супругов, детей, домашних животных, место рождения, юбилей, день рождения и т.д.
В некоторых организациях, например, связанных с оборонным комплексом, может предъявляться требование генерировать автоматически пароль для каких-либо пользователей. Обычно при генерации таких паролей используется разное количество печатных знаков. После генерации такой пароль передается пользователю. К сожалению, такой пароль нелегко запомнить. Пользователи имеют тенденцию записывать эти пароли на клочках бумаги, которые могут быть утеряны или похищены. Если вами используются дополнительные методы контроля за назначением паролей, то стоит попытаться разработать правила, позволяющие генерировать более читабельные пароли для пользователей.
Другая важная особенность заключается в сроке действия пароля. Если срок действия пароля не определен, то похищенный пароль может использоваться постоянно. Но если пароль имеет определенный срок действия, то в случае компрометации пароля, остается шанс, что проблема разрешится сама собой после изменения пароля в назначенный срок.Несмотря на то, что это звучит несколько наивно, данная методика похожа на периодическое изменение комбинации цифр на замке, чтобы выяснить, кто знает эту комбинацию.
Можно ли повторно использовать пароли, которые были изменены? Одна из компаний, с которой сотрудничал автор книги, поддерживала базу данных с последними 24 паролями, чтобы пользователь имел возможность посмотреть, не назначает ли он старый пароль при очередной замене пароля.
Правила расширения сети
Поскольку технологии становятся все более гибкими и всеобъемлющими, расширение сети неизбежно. При расширении сети было бы неплохо ввести инструкции для гарантии того, что не только расширение сети проходит, как следует, но и сохраняется оборудование сети. В главе 1 "Что собой представляет политика информационной безопасности" говорилось, что все это может быть сделано во время оценки степени риска. Кроме того, в других случаях эти знания могут существенно помочь в поддержании работоспособности сети и обеспечении администраторов схемой сети, позволяющей отслеживать сетевой трафик.
Правила расширения сети должны быть записаны обобщающей формулировкой, например, такой.
Необходимо разработать методики, позволяяющие реконфигурировать сеть организации. В этих методиках должны быть отражены все изменения, касающиеся непосредственно всех внутренних и внешних точек доступа.
Несмотря на то, что желательно не детализировать излишне методики, так как это ограничит область их применения, все-таки есть смысл привести список предлагаемых методик. Если вы сочтете нужным включить в документы политики такой список, то он может выглядеть так.
Преобразование сетевых адресов
Другой способ скрыть конфигурацию внутренней сети заключается в использовании одних адресов для внутренних систем и преобразовании их при связи с Internet или другими внешними сетями. Такой механизм называется преобразованием сетевых адресов (NAT— Network Address Translation). Основная функция NAT заключается в использовании особого алгоритма формирования адресов при работе во внутренней сети организации, которые перед посылкой их в Internet должны быть преобразованы в другие адреса.
Почему необходимо преобразование сетевых адресов
Когда в начале 90 годов началось повсеместное использование Internet, стало очевидным, что такой бурный рост числа пользователей приведет к нехватке адресов доступа. Пытаясь замедлить этот процесс, рабочая группа инженеров Internet (IETF - Internet Engineering Task Force) опубликовала RFC 1631, Преобразователь сетевых адресов протокола IP (NAT- The IP Network Address Translator). В этом документе объяснялось, как создавать сеть, в которой используется отдельный список адресов для незарегистрированных систем, которые могут быть преобразованы в зарегистрированные или "реальные" адреса, маршрутизированные в Internet. После аннонсирования этого RFC профессионалы безопасности стали призывать использовать NАТ, чтобы прятать сетевую конфигурацию и масштаб работ организации, не изменяя открытой информации об организации или открытых сведений о ее инфраструктуре.
Один из распространенных способов использования NAT заключается в назначении сетевых адресов для систем организации, не пользующихся Internet, из отдельного блока, установленного для скрытых сетей, которые будут преобразовываться в легальные адреса. Адресами скрытых сетей являются:
При использовании NАТ пользователь получает стандартный доступ в Internet, но адрес скрытой сети перед передачей должен быть преобразован системой, которая обеспечивает подключение и модификацию адреса перед отправкой (рис. 5.3).
Устройства системы NАТ не являются посредником в сеансах. Однако представлять NАТ в качестве промежуточного звена довольно удобно.
Рис. 5.3. Преобразование адресов с помощью NАТ
Не в каждой организации есть смысл применять NAT. Одна из проблем заключается в том, что если сеть разрастается, то может оказаться недостаточно легальных адресов для доступа в Internet. Администраторы сети должны провести тщательный анализ и решить, нужно ли использовать NAT. Но в том случае, если NAT будет использоваться, необходимо составить формулировку для документа политики в наиболее обобщенном виде, чтобы обеспечить архитекторам и администраторам сети максимальную свободу выбора. Формулировка может выглядеть следующим образом.
Адреса внутренней сети организации должны оставаться скрытыми. Когда системы запрашивают доступ к другим сетям, скрытые адреса перед передачей должны быть преобразованы в легальные зарегистрированные адреса.
Приглашенные и прочие пользователи
Необходимо назначить имена для приглашенных пользователей и прочих, таких как подрядчики и обслуживающий персонал, чтобы они тоже могли получить доступ в сеть. Несмотря на то, что они обслуживают организацию, они все равно являются аутсайдерами. В правила назначения пользовательских имен для этих сторонних пользователей можно включить предписание, с которыми пользователи должны ознакомиться и следовать им. Также нужно включить в правила требования контроля, предназначенные для поручителя этих аутсайдеров.
Одно общее требование правил заключается в определении условий присваивания пользовательских имен приглашенным пользователям. Одно простое требование, общее для всех правил, в разработке которых приходилось участвовать автору книги, заключается в разрешении поручителю организации запрашивать доступ к администратору. Поручитель и администратор будут вместе отвечать за обследование объекта и его соответствие установленным правилам. Проведение такой политики делает процесс обследования объекта более коротким, чем тогда, когда в правилах записано, что для осуществления обследования требуется создание специальной комиссии. Это намного выгодней потому, что для обслуживающего персонала требуется срочный доступ к системе.
Если принято решение использовать эти рекомендации, то можно записать в правила набор формулировок следующего характера.
Приглашенные noльзователи и прочие пользователи, не являющиеся сотрудниками организации, получают доступ к сети и ее ресурсам у поручителя организации и назначенного системного или сетевого администратора. Администратор разрабатывает процедуры для предоставления, отмены и пересмотра права доступа приглашенньм пользователям и прочим пользователям, не являющимся сотрудниками организации.
Поручитель предоставляет пользователям право доступа к пpaвилам безопасности организации и процедурам и разъясняет им, что они обязаны соблюдать эти правила. Поручитель и администратор отвечают за контроль соблюдения правил приглашенными пользователями.
Пользовательские имена должны присваиваться приглашенным пользователям только на то время, пока им необходим доступ в систему. Имена пользователей должны быть аннулированы, как только доступ им станет ненужным.
Привилегированный режим работы
Труднее всего разработать правила, в которых описываются скорее исключения, чем правила. Особые привилегии являются исключениями из правил, и такие предписания требуют особого подхода к работе и специальных инструкций, потому что они не должны нарушать другие правила и инструкции безопасности. Правила привилегированного режима работы должны быть написаны таким образом, чтобы не только разрешить работу в привилегированном режиме, но и в общих чертах описать, какие должны быть разработаны инструкции, и какими способами они должны внедряться. При разработке правил необходимо учесть, какими методами будет поддерживаться привилегированный режим. Нужно быть очень осторожным, разрабатывая правила такого рода. Ниже приведена очень простая формулировка, но вам необходимо учесть конкретные требования вашей организации и привести эту формулировку в соответствие с этими требованиями.
Для привилегированного режима работы должны быть написаны соответствующие инструкции, гарантирующие их четкое выполнение техническим персоалом организации. В этих инструкциях должны быть определены условия контроля выполнения, управления и пересмотра требований доступа.
Проверка полномочий вспомогательных систем
Перед тем как продолжить, важно вспомнить, что каждый из шлюзов или каждая вспомогательная система является точкой входа в сеть организации. В любой точке входа должны каким-то способом проверяться полномочия потока данных, входящих и исходящих из сети. Один из вопросов, которые необходимо рассмотреть, заключается в требовании санкционирования внешних подключений к вспомогательным системам сети. Это может оказаться проблемой для вспомогательных систем, которые подключены к сети постоянно. Для таких вспомогательных систем необходимо определить, каким образом будет осуществляться санкционирование их присутствия в сети. В действительности, даже временные подключения к сети, такие как подключения входящих модемов, могут иметь строгие требования по аутентификации.
В этом разделе правила требования по аутентификации не должны описываться— они обсуждаются в следующем разделе "Безопасность регистрации". Здесь же можно только отметить необходимость требований к аутентификации. Правила, касающиеся стандартов аутентификации, будут рассмотрены в следующем разделе. Однако, для обеспечения гарантий того, что для вспомогательных систем будет решен вопрос аутентификации, в пункт правил для межсетевых подключений можно добавить следующее.
Приложения, необходимые для работы шлюзов, должны подвергаться аутентификации в сети. Если само приложение не может быть аутентифицировано, то правила аутентификации, описанные в данном документе, должны распространяться на вспомогательные системы, подключенные через шлюзы.
Регистрационные баннеры
После назначения имен пользователей в правила безопасности можно включить условия и инструкции для регистрации и аутентификации пользователей. Во-первых, в рабочих инструкциях полезно иметь регистрационные баннеры. Регистрационные баннеры представляют собой важнейшую часть информации, которая сопровождает на экране появление предложения зарегистрироваться. Баннеры могут содержать информацию о системе, включая тип операционной системы, или информацию о компании. Независимо от того, какая информация содержится в баннере, кто-нибудь, желающий взломать систему, может использовать эти сведения. Информация о типе операционной среды может помочь квакеру найти уязвимые места в системе. Если система или сеть является внутренней или для организации это не имеет значения, то нет и необходимости регламентировать правилами использование регистрационных баннеров. В противном случае формулировка правил может быть следующей.
Все регистрационные экранные сообщения, отображения данных и другие экранные формы, появляющиеся во время регистрации или аутентификации и сопровождаемые баннерами, не должны содержать никакой информации об операционной среде.
Баннеры существуют не только для регистрации
Тем, кто разрабатывает правила применения регистрационных баннеров, важно помнить, что баннеры применяются не только при регистрации. Солидный баннер может быть строкой приветствия при отправлении электронной почты с помощью протокола SMTP (Simple Mai! Transfer Protocol - упрощенный протокол электронной почты). Большинство программ, отвечающих на запросы SMTP, выводят регистрационные баннеры, которые идентифицирует систему и даже версию используемого программного обеспечения. Хакер может использовать эту информацию, чтобы найти способ "протестировать" конфигурацию на предмет уязвимых мест. Несмотря на то, что какая-нибудь рабочая программа может быть предметом вашей гордости (особенно та, которая упаковала и отправила электронную почту), все-таки лучше ее спрятать от широкой публики.
Одним из видов информации, который можно включить в регистрационный баннер, является сообщение о том, кто может использовать систему. Это простые неразглашаемые формулировки о том, кому' разрешено пользоваться системой. Они могут варьироваться от полноэкранных формулировок до простой одиночной строки, наподобие следующей.
Использование этой системы разрешено при условии соблюдения правил и методик компании.
Если одно из нечасто выполняемых действий выходит за рамки предписаний, то будет нелишне отразить это соответствующим пунктом правил. Обязательно нужно рассмотреть, желательно с привлечением юриста, возможные изменения существующих правил. Таким образом, мы можем модернизировать предыдущую формулировку правил, включив в нее предписание о неразглашении:
Баннеры, которые выводятся на экран при регистрации и аутентификации, должны содержать следующее сообщение: "Использование этой системы разрешено при условии соблюдения правил и методик компании."
Соглашение о неразглашении в баннерах
Использование баннеров неразглашения не является необходимостью, несмотря на то, что многие организации используют их для информирования потенциальных пользователей о том, что система ограничена для использования, и их действия могут контролироваться и записываться. Однако некоторые суды в Соединенных Штатах выносили решения, в которых говорилось, что, поскольку при регистрации на экране отсутствовало предупреждающее сообщение, нельзя считать, что злоумышленники проникали незаконно в систему, а следует считать, что они были туда приглашены. Эти вердикты выносились на основании законов, применяемых в привычном мире. Несмотря на то, что существуют новые законы, которые обеспечивают использование в подобных случаях более совершенного инструмента для обвинителей, наличие прецедентов, в которых выносились противоположные решения, вынуждает судей, не знакомых с киберпространством, принимать во внимание эти прецеденты. Нужно поинтересоваться у юриста, нужно ли создавать подобные баннеры для вашей правовой защиты в случае возникших проблем.
Сетевая безопасность имеет отношение не
Сетевая безопасность имеет отношение не только к безопасности Internet, но и к защите каждого сетевого подключения и интерфейса. Это означает установление определенных взаимоотношений между информацией и теми, кто ее запрашивает. Основой управления доступом является аутентификация. Аутентификация представляет собой передний рубеж защиты для любой системы или сети, где реквестор на основании предъявленных полномочий получает разрешение на вход в систему. Мы пытаемся решить проблемы защиты информации, опираясь на знание архитектуры сети и применяя различные способы аутентификации.
сетевых адресов (NАТ), чтобы спрятать адресацию.
информации.
- С помощью имен пользователей определяется, кто или что получает доступ к сети или пытается получить доступ. Пользовательские имена могут являться источником информации, поэтому благоразумней использовать пользовательские имена, привязанные к фамилии, имени, отчеству пользователя, а не к его функциональным обязанностям. В правилах должно быть отражено, что
делать с пользовательскими именами, назначенными операционной системой при ее установке. - Имена приглашенных пользователей и пользователей, не являющихся сотрудниками организации, должны особо тщательно контролироваться. В правила присвоения таких имен необходимо включить требования по контролю за ними и их аннулированию.
- Регистрационные баннеры могут выглядеть вполне безобидными, но они могут нести информацию об операционной среде, которая может быть использована теми, кто захочет попытаться взломать систему и сеть. Можно записать в правила требование ограничить информацию, выводимую в баннере, или записать просто формулировку о неразглашении.
- В правила необходимо включить соображения о многократных/однократных сеансах идентификации, а также требования, касающиеся систем положительной идентификации.
- Протоколирование как успешных, так и безуспешных попыток зарегистрироваться в системе может быть использовано средствами обнаружения вторжений. Добавление примечания о времени и дате последней регистрации в системе, которое сможет просматривать пользователь, создаст новый уровень
отчетности о нарушениях безопасности. - В правила ограничения числа сеансов регистрации необходимо добавить требование автоматического выхода из системы (по истечении промежутка времени, по времени суток и т.п.), при этом важная информация должна оставаться доступной без разрегистрации. Кроме того, необходимо ввести предписания тем, кто имеет доступ к важной информации, выходить из системы при оставлении рабочих станций без присмотра.
- Правила администрирования пользовательского доступа могут предписывать минимальный уровень требований для управления назначением и распределением пользовательских имен. Сведение к минимуму требований, включенных в правила, дает возможность разрабатывать дополнительные инструкции в том случае, если необходимо расширить круг требований, но при этом разрешает администраторам
при необходимости расширять список пользовательских имен. - Правила работы в привилегированном режиме - это тщательно расписанные требования, на основании которых разрабатываются инструкции, определяющие требования к доступу в систему, а также требования контроля за предоставлением привилегий.
- 4. Пароли.
- Правила, относящиеся к действующим паролям, следят за структурой пароля и сроком его действия. Эти правила также запрещают использовать повторно старые пароли.
- Правило хранения паролей устанавливает, что пароли должны храниться таким образом, чтобы обычные пользователи не могли их считывать. Хранение паролей осуществляется операционной системой; также можно записать в правила, что защита, устанавливаемая системой по умолчанию, не может быть ослаблена.
- Правила назначения специальных паролей требуют менять или удалять пароли, установленные поставщиком по умолчанию, а также назначать и использовать принудительные пароли — когда кого-то принудили ввести пароль, включается сигнализация для правоохранительных органов.
- 5. В пользовательском интерфейсе для введения паролей необходимо учитывать использование алгоритмов, предоставляемых системой или системным программным обеспечением. Можно разработать правила, определяющие, что должно отображаться на экране, а также, как защитить пароли во время пересылки их в сеть.
- 6. Правила управления доступом определяют системы или ресурсы, доступ к которым должен контролироваться или ограничиваться. Поскольку эти правила довольно разнообразны, предлагается разработать отдельный документ для каждой части системы, которая имеет свой специфический доступ. Чтобы новые системы располагали соответствующими правилами управления доступом, необходимо записать в отдельное правило, что хранители информации обязаны разработать правила управления доступом к новой системе до ее инсталляции.
- 7. Средства телекоммуникации и удаленного доступа управляют удаленным доступом к сети служащих организации и другого, имеющего право доступа, персонала.
- В некоторых организациях вводят необязательные правила, регламентирующие использование разрешенного в данной операционной среде оборудования по выбору сотрудника организации. В других организациях компьютеры и оборудование предоставляются служащим компанией. Эти организации могут ввести правила, согласно которым поставляемое оборудование должно использоваться без изменени1 так, как оно было установлено. Пользователь не может вносить изменения.
- В правила управления защитой данных при удаленном доступе должно быть записано требование, что удаленный пользователь обеспечивает надлежащую защиту компьютерного оборудования и данных на дополнительных рабочих узлах. В этих же правилах должно быть записано, что организация является владельцем всей интеллектуальной собственности, используемой или созданной в среде удаленного доступа.
- Чтобы придать правилам удаленного доступа больше веса, можно включить в них конкретное предписание, чтобы служащие несли ответственность за поддержание структурированной рабочей среды, а также исполняли все инструкции, касающиеся безопасности удаленных систем (лицензирование программного обеспечения, создание резервных копий и т.д.).
- Правила эксплуатации средств телекоммуникации и удаленного доступа определяют режим работы модемов и, если используется, туннелирования Internet. Этими же правилами регламентируется распределение телефонных номеров для телефонных линий, а также расширенная аутентификация для доступа любого типа.
Руководящие принципы эксплуатации оборудования
Некоторые организации не вводят ограничения на оборудование, используемое для телекоммуникаций или удаленного доступа. Правила эксплуатации оборудования требуют от служащих использовать оборудование, предоставленное организацией. В иных случаях организация не устанавливает свои правила в этой области, а предоставляют сетевым администраторам самим определять руководящие принципы в виде рабочих инструкций. Организации, которые поставляют компьютеры и оборудование, должны устанавливать правила, требующие использовать системы в том виде, в каком они поставлены, и запрещающие пользователю вносить изменения в программы или конфигурационные установки.
Руководящие принципы защиты информации при удаленном доступе
Одной из проблем, которые приходится решать при выдаче разрешения служащим работать вне офиса, является защита как самого компьютера, так и данных на дополнительных рабочих узлах. Поэтому, в принципе, не мешало бы разработать правила, определяющие безопасность работы вне офиса. Эти правила могут быть разработаны, исходя из тех же соображений, что и правила для пользователей в офисе.
В некоторых организациях необходимо провести предварительное обследование территорий, где будут расположены удаленные рабочие места. Несмотря на то, что сам автор не сталкивался с подобными правилами, но слышал, что такие требования выставляются со стороны федерального правительства к подрядчикам, чтобы обеспечить выполнение требований национальной безопасности.
Помимо собственно вопросов безопасности существуют проблемы с правами на интеллектуальную собственность, созданную в организации. Для защиты прав организации на эти информационные активы будет неплохо добавить правило владения этой собственностью в программу развития интеллектуальной базы организации?
Шлюзы
Шлюзы являются пунктами, в которых сетевой трафик передастся из сети организации в другую сеть. В отношении шлюзовых пунктов правила управления доступом должны учитывать природу сети, в которой устанавливается мост.
Весь телефонный доступ в сеть должен быть защищен с помощью средств строгого контроля аутентификации. Модемы необходимо сконфигурировать для одного из доступов dial-in или dial-out, но ни в коем случае не для обоих. Администратор сети должен обеспечить процедуры гарантированного доступа к модемным системам. Пользователи не должны устанавливать модемы в других точках сети бел соответствующих санкций.
Как и для любых правил, нужно ожидать, что будут появляться запросы на изменение правил управления доступом. Независимо от причин, требующих корректировки правил, следует предусмотреть возможность вносить исключения в правила с помощью механизма пересмотра правил. Если согласно предписаниям политики был создан комитет управления безопасностью (см. главу 3 "Обязанности в области информационной безопасности"), то можно потребовать, чтобы комитет пересматривал правила.
Любой шлюз, предлагаемый для установки ь сети компании, если он может нарушить правила или процедуры, предписанные этими правилами, не должен устанавливаться без предварительного утверждения комитетом управления безопасностью.
Специальные пароли
В конце 70 - начале 80 годов многим заказчикам поставлялся очень популярный мини-компьютер, в котором для обслуживающего персонала были назначены пользовательское имя FIELD и пароль SERVICE. Этому пользовательскому имени был разрешен доступ к различным диагностическим пакетам, многие из которых могли нанести ущерб при неправильном обращении. Разъезжая по командировкам в качестве консультанта, автор книги был потрясен количеством систем, к которым он мог получить доступ, используя пароль по умолчанию. На это следует обратить внимание, поэтому мы снова и снова подчеркиваем необходимость установить правилами требование к администраторам изменять пароли, установленные по умолчанию для стандартных системных пользователей.
Однажды вечером автор вместе с другом находился в крупной брокерской фирме, когда устройства звуковой сигнализации (beeper) стали подавать сигналы тревоги. Через считанные секунды друг и несколько вооруженных охранников вошли в помещение, где обнаружили человека, лежащего на рабочей станции. У несчастного был сердечный приступ. Для вызова скорой помощи он зарегистрировался в системе и ввел специальный пароль, и этим подал сигнал системе наблюдения за сетью о том, что кто-то принудил его ввести пароль.
Поскольку брокерская контора ворочает ежедневно ценными бумагами на миллиарды долларов, было установлено правило принудительного пароля, на тот случай, если кто-то вздумает ворваться в здание и будет принуждать брокера войти в систему. Если введен принудительный пароль, тут же активируется служба физической безопасности конторы. В данном случае офицер смог оказать первую помощь, пока не прибыла служба скорой помощи.
Принудительные пароли довольно сложны, поскольку они должны разрешать пользователю входить с систему, при этом вызывая неслышный сигнал тревоги, показывающий место, где возникли проблемы. Формулировка правил для такого случая должна просто говорить о необходимости иметь принудительные пароли, или же просто описывать, что из себя представляют принудительные пароли, не описывая сути их функционирования.
Средства регистрации
Средства регистрации способствуют процессу аутентификации. Они обеспечивают выполнение инструкций для обеспечения положительного результата аутентификации (биометрия, PKI, Kerberos и т.д.), а также выбор многократных или однократных сеансов. В правилах положительной аутентификации не нужно конкретно определять протокол или тип сервиса, а только требования их наличия. Если не конкретизировать правила, разработчики и администраторы получают возможность использовать наилучший сервис для организации. Простая формулировка правил может выглядеть следующим образом.
Службы регистрации должны обеспечивать положительную аутентификацию. Это даст гарантию того, что законный пользователь получит доступ к системе или сетевому окружению.
Для некоторых организаций выбор однократных или многократных сеансов аутентификации не представляет особых проблем. В операционной среде сервера, обслуживающего типовые рабочие станции, система с сетевой структурой может инициировать многократные сеансы так, как требует операционное программное обеспечение. Однако, при использовании универсальной машины или любого другого сервера с разделением времени/монопольным сервером может возникнуть желание ограничить количество сеансов, которые может инициировать пользователь.
Пользователям с правом доступа к производственной сфере нельзя разрешать инициировать многократные сеансы аутентификации.
Средства управления доступом
Средства управления доступом сводятся не только к аутентификации, но с их помощью определяется, кто имеет доступ к ресурсам организации. Средства управления доступом предусматривают несколько способов реализации. Наиболее распространенные алгоритмы привязаны к тем, что предлагаются операционными системами или программным обеспечением, поддерживающим работу предприятия. Это значит, что правила управления доступом привязаны к технологии, используемой для поддержки бизнеса.
Правила управления доступом должны быть сфокусированы на том, где использовать управление доступом, а не декларировать его использование. Специфика разработки правил управления доступом заключается в том, чтобы широкая формулировка правил не могла быть приложена к тому, что не требует управления доступом. Например, правила управления доступом, которые ограничивают доступ к информации организации, хранящейся в базе данных, не должны быть приложимы по отношению к документам, доступным через Intranet.
Таким образом, первым шагом в определении того, где требуются правила управления доступом, заключается в выяснении областей, в которых необходимо использовать компьютерные системы управления доступом, или требуется управление доступом на базе пользовательских имен/паролей. Чтобы это осуществить, необходимо вернуться к этапу инвентаризации ваших систем и отметить, где и как они используются. На основе такой информации можно разработать правила, соответствующие используемым вспомогательным системам.
Одной из проблем такого подхода является то, что между разработкой правила и его последующим пересмотром может появиться какая-нибудь новая система или новое требование ведения бизнеса, которые требуют введения новых правил управления доступом. Вместо пассивного ожидания последующего пересмотра правил лучше создать для каждого средства управления доступом свои правила в виде отдельного документа и добавить еще один документ, в котором говорится о следующем.
Ответственные за информацию лица, желающие установить новые системы или программное обеспечение для поддержки новых или уже существующих требований ведения бизнеса, для которых требуются собственные средства управления доступом, должны еще до инсталляции этих средств разработать правила управления доступом для этих систем. Эти правила должны пересматриваться таким же образом, что и уже существующие.
После рецензирования новых правил они добавляются к другим документам политики и становятся частью общей программы безопасности.
Телекоммуникации и средства удаленного доступа
И, наконец, в правилах должно быть отражено, каким образом организация желает защитить свои активы, используемые удаленными пользователями, имеющими доступ к сети организации. Как правило, это правила эксплуатации модемов и телефонных линий, к которым подключены модемы. Однако, с появлением новых технологий в организации может быть разрешен доступ с использованием Internet.
Телекоммуникации и удаленный доступ
С каждым годом количество людей, пользующихся средствами телекоммуникации, растет. Независимо от того, служат они одиноким родителям, потерявшим трудоспособность служащим или в качестве случайно подвернувшегося средства, использование телекоммуникаций требует четкой стратегии для гарантии того, что время связи полезно используется, и деятельность служащего так же продуктивна вне офиса, как и во время его работы в офисе.
Иной аспект правил удаленного доступа заключается в том, что они должны обеспечивать доступ в сеть служащим и клиентам, находящимся вне месторасположения их организации. Обычно эти правила определяют доступ к сети извне по телефонным каналам. Но новые технологии могут вынудить вас разработать иные правила, обеспечивающие доступ в сеть с помощью новых средств.
Требования к регистрации и процедуры регистрации
Первой информацией в любой регистрационной последовательности должна быть посылка, идентифицирующая того, кто запрашивает разрешение на доступ в сеть. Независимо от используемых протоколов необходимо знать, кто пытается получить доступ к сетевым системам или, в некоторых случаях, в качестве кого они хотят представиться сетевым службам.
Итак, что собой представляют ключи идентификации пользователей, которые используются для регистрации в системе или сети? В некоторых хорошо защищенных системах, таких как военные ведомства, идентификация пользователей производится на основе случайной последовательности символов. В других организациях предпочитают использовать методы, которые позволяют однозначно идентифицировать пользователя, не обращая внимание на то, каким образом созданы имена пользователей.
Если имена пользователей могут предоставить информацию об организации, то хорошей идеей могут быть произвольные имена. Однако использование случайной последовательности символов может привести к тому, что пользователи станут записывать эти имена на клочках бумаги. Если они записывают имена, то они вполне могут записывать и пароли. Чтобы предотвратить это, можно разрешить использовать имена пользователей, которые легко запоминаются.
Несмотря на то, что сама организация назначает имена пользователей, правилами должен определяться их вид. Например, в одной из компаний, с которой автору книги пришлось сотрудничать, для создания имен пользователей использовали табельный номер служащего, перед которым ставилась дополнительная буква. Правила, которые были разработаны в этой компании, гласили.
Идентификационные имена пользователей должны состоять из пятизначного табельного номера служащего, присвоенного отделом кадров, перед которым нужно поставить одну дополнительную букву.
Возникают и другие вопросы, связанные с правилами назначения имен пользователей. Правилами должно быть предусмотрено наличие системных имен и обработка имен пользователей, назначенных по умолчанию. Эти вопросы возникли тогда, когда появились новые операционные системы, в которые поставщик для удобства включил множество имен для различных вспомогательных систем.
Если не удалить эти имена, то есть вероятность, что они при случае могут создать проблемы с безопасностью. Несмотря на то, что большинство поставщиков решили эту проблему, введение соответствующего пункта в правила поможет администраторам учитывать эти моменты еще до того, как что-нибудь случится. Ниже представлен пример формулировки правил, регламентирующей использование имен пользователей в системе.
Системным именам и именам пользователей, присвоенным по умолчанию, назначенньм самой операционной системой, должен быть присвоен пароль, отличный от того, который был назначен при загрузке операционной системы.
Имена пользователей, назначенные вспомогательным системам без учета требований регистрации, должны быть сконфигурированы так, чтобы не позволять им регистрироваться в системе. Имена пользователей вспомогательных систем, которые не используются должны быть удалены из системы.
Туннелирование через Internet
Несмотря на то, что выбор доступа в сеть с использованием средств зашиты Internet имеет много преимуществ, во многих организациях побаиваются использовать Internet до тех пор, пока протоколы и технические средства не станут достаточно защищенными. Но если использование Internet является частью бизнес-плана вашей организации, то в документы политики следует включить минимальные требования к безопасности подключений. Например, можно потребовать, чтобы информация, пересылаемая между пользователями и сетью, шифровалась. Можно также потребовать аутентификацию пользователей Internet наподобие аутентификации внешних пользователей, получающих доступ по телефонным каналам. Не важно сколько требований будет включено в правила, важно, чтобы они не мешали администраторам изменять инструкции при введении новых технологий безопасного туннелирования через Internet.
Управление доступом к сети
Перед обсуждением аутентификации пользователей сети необходимо разработать правила управления доступом к сети. Сети уже не являются монолитными объектами. В большинстве случаев имеется одна внешняя точка доступа — подключение к Internet посредством ISP (Internet Service Provider — поставщик услуг Internet). Правила упраатения доступом к сети будут определять, какую защиту необходимо установить на входных точках в сеть.
Управление пользовательским доступом
Наряду с созданием пользовательских имен необходимо разработать директивы совокупного управления пользовательскими именами. Управление пользовательскими именами состоит из директив, которые предписывают, как создавать и аннулировать эти имена. Кроме того, в задачи управления входят следующие.
Несмотря на то, что эти задачи в правилах не определяются, можно включить список, наподобие представленного выше, в виде рекомендаций введения всех или некоторых этих требований в административные инструкции. Независимо от того, как разрабатываются правила, следует расписать эти моменты таким образом, чтобы административные инструкции не были сведены лишь к этим рекомендациям.
Виртуальные частные сети и экстрасети
Увеличение количества сетей в организации вынуждает искать новые варианты подключения удаленных офисов, клиентов и упрощения доступа обслуживающих контрагентов или потенциальных контрагентов. Этот рост породил два типа внешних соединений: виртуальные частные сети (VPN — Virtual Private Network) и экстрасети. VPN представляют собой недорогой способ установить информационную связь между двумя и более подразделениями организации, расположенными на разных территориях. Организации создают VPN путем подключения всех подразделений к Internet и установки устройств, которые будут осуществлять шифрование и дешифрование информации в обоих связывающихся между собой подразделениях. Для пользователей работа через VPN будет выглядеть так, как будто оба подразделения находятся на одной территории и работают в единой сети.
Правила безопасности электронной почты
Административные обязанности
После того, как разработаны правила подсоединения к Internet, самое время сконцентрироваться на специфических областях, которые влияют на использование этого подключения. Начнем с правил администрирования. За исключением самых простых правил, о правилах администрирования забывают, поскольку разработчики правил полагают, что все эти вопросы рассматривались в других областях. Это может быть и так, но все же имеет смысл их здесь описать.
Аутентификация транзакций Internet
С нарастанием популярности Web-технологий мы сталкиваемся со старыми проблемами в новой форме. При предоставлении услуг посредством Web используется модель, в которой применяется так называемый обмен блоками (block mode transfer). Широко применяемый в старых вычислительных системах обмен блоками функционирует следующим образом: пакуется блок данных с экрана, передается на удаленную систему, а затем блок данных принимается взамен. Однако, в среде Web соединение между сервером и клиентом прерывается после завершения передачи данных.
Аутентификация представляет собой идентификацию пользователя в системе, на сервере или в программном обеспечении, разрешающую ему использовать эти средства. Аутентификация осуществляется многими способами, но общепринято требовать, чтобы пользователь вводил идентификационные данные и пароль. Сущность блочной передачи данных при работе в Web представляет интересные проблемы не только в отношении аутентификации транзакций, но и при создании среды, где пользователь не должен каждый раз идентифицироваться при подключении к серверу.
В правилах аутентификации должно быть записано, что ответственные за данные и процессы лица обеспечивают определение личности тех, кто обращается к данным. Речь идет не только о пользователях Internet, но и о партнерах, которые могут иметь доступ через виртуальные частные сети. В правилах также должны быть учтены все транзакции Internet, включая пересылки Web, подключения к базам данных и терминальным службам. Типичная формулировка правил выглядит следующим образом.
Ответственные за данные и процессы лица должны гарантировать, что реквизиты всех пользователей патентованных данных проверяются и принадлежат этим пользователям. Ответственные за данные и процессы лица должны разработать процедуры подтверждения и отмены права на выполнение этих операций.
Доступ из Web к сети и инфраструктуре
Основная цель службы информационной безопасности — следить за тем, как организация обслуживает свои Web-серверы и системы, которые обеспечивают работу в Web. Постоянно появляются новые критерии безопасности, новые уязвимые места и хакерские средства. Web-узлы повреждаются, похищается информация, и организация рискует из-за этих инцидентов получить негативное паблисити.
Помимо искажения информации существуют проблемы, связанные с воровством информации наподобие тех, которые случаются с содержимым кредитной карточки. Это говорит о том, что существуют слабые места в обслуживании таких записей или в доступе к инфраструктуре, где хранятся эти записи. Тот, чьи узлы были взломаны, знаком с данными проблемами.
Существует столько же способов зашиты данных и сетевой инфраструктуры организации, сколько вариантов реализации Web. В ракурсе разработки правил довольно сложно предложить формулировку, которая удовлетворяла бы конкретной системе. Однако, если не обращать внимания на особенности реализации, то можно найти что-то общее во всех реализациях и изложить это в правилах.
Например, один из способов защиты данных заключается в установке серверов после внутреннего брандмауэра (см. рис. 6.1) и применении специальных методов обеспечения более качественной связи между системами. Несмотря на то, что детали такой схемы должны быть изложены в инструкциях, в качестве руководства для тех, кто внедряет эту систему, нужно разработать правило. Формулировка правила может быть следующей.
Все системы с собственными и клиентскими данными, которые поддерживают Web-сервер, не должны устанавливаться на том же сегменте сети, на котором установлены Web-серверы. Эти вспомогательные серверы должны устанавливаться таким образом, чтобы доступ был возможен только к Web-серверам. Организации следует установить надлежащие средства контроля для обеспечения гарантий того, что вспомогательные серверы могут быть доступны только таким способом, который согласуется с функциями, на которые они запрограммированы.
Другая проблема заключается в выполнении программ, сценариев или иных вспомогательных процедур на Web-сервере. Некоторые организации не испытывают таких проблем и разрешают запускать сценарии, которые работают как часть общего шлюзового интерфейса сервера (CGI — Common Gateway Interface). В других организациях испытывают беспокойство при разрешении запуска всего, что отличается от тестовых страничек сервера. Необходимо быть очень осторожным при утверждении таких правил, поскольку они будут сильно влиять на архитектуру вспомогательных систем Internet вашей организации. Чрезмерная жесткость правил будет неприемлема для организаций, которые пользуются услугами внешних вспомогательных систем.
На Web-серверах должны запускаться только проверенные программы и сценарии, которые функционируют как часть общего со вспомогательными Web-системами шлюзового интерфейса (CGI). Все другие программы должны выполняться на иных системах, не связанных с Web-системами, на которых эти сценарии работают как посредники для такого выполнения.
Сервлеты, аплеты и динамическое содержание
Требования к Web-серверам по выдаче более содержательной информации все увеличиваются: по мере появления новых технологий, создаваемых для распространения этой информации. CGI является всего лишь верхушкой айсберга. В настоящее время, с появлением языка программирования Java, небольшие приложения, называемые аплетами, помогают обеспечить доступ к содержимому на Web-узлах. Но и это не все. Появляются технологии, которые позволяют динамически генерировать содержимое по запросам пользователя. Кроме того, начинают появляться небольшие приложения, размещенные на сервере или сервлеты, а также страницы со встроенными командами, которые выполняются на сервере.
Несмотря на то, что эти технологии расширяют возможности Web-серверов, они создают дополнительные проблемы с безопасностью. Во-первых, новые технологии работают в той же системе, что и Web-сервер. Сбои или другие помехи могут вызвать много различных проблем с защитой сервера.Во-вторых, эти размещенные на сервере программы не имеют отдельного интерфейса, безопасность которого можно было бы оговорить в правилах, ограничивающих доступ к вспомогательным системам.
Организация должна оценить целесообразность применения таких новшеств в соответствии с создаваемыми ими потенциальными проблемами, а также разработать правила их применения. Конечно, вы можете решить, что модель производственной деятельности вашей организации не может обойтись без их применения. В таком случае необходимо обеспечить разработку таких правил безопасности, которые обеспечивали бы соблюдение норм безопасности теми, кто внедряет вспомогательные системы, обеспечивающие безопасный интерфейс для конфиденциальных данных.
Доступ пользователей к Web
Правило номер один при создании правил доступа пользователей заключается в том, что пользователям доверять нельзя. Других правил, собственно, и не существует. При отсутствии правил и ограничивающих инструкций организации столкнутся с большими сложностями, потому что пользователи будут посещать любой сайт, загружать любые программы, будут иметь доступ к аплетам и заполнять любую форму, какую пожелают.
Во многих организациях принято работать по правилам, которые включают фильтрацию содержимого. Фильтры содержимого обычно не допускают посещения пользователями сайтов, которые компания считает незаконными или, в каком-то смысле, аморальными. Кроме того, они предоставляют кэши содержимого на шлюзах Internet, чтобы ускорить загрузку информации. Другие возможные фильтры содержимого могут не допускать использование аплетов корректировки содержимого.
Независимо от сферы деятельности организации правила должны четко разъяснять, каким образом управлять трафиком в Internet. Пользователям необходимо давать разъяснения скорее с точки зрения законности действий, чем с каких-то других. Нужно сказать о том, что организация контролирует трафик или может даже проводить аудит, чтобы определить, какая информация передается через интерфейс Internet. Если не сообщить об этом, а также не предупредить о дисциплинарных взысканиях, утвержденных правилами, то организация может оказаться втянутой в судебные процессы, инициированные служащими. Ниже следует примерная формулировка правил.
Пользователи, имеющие доступ к Internet, не должны посещать сайты, которые созданы с нарушениями закона или содержат оскорбительную информацию о пользователях. Организация должна сохранить за собой право блокирования доступа ко всем сайтам, которые считаются неприемлемьми, а также делать регистрационные записи о посещении сайтов всеми пользователями, на основании которых в любое время можно провести аудиторскую проверку. В качестве этапа процесса фильтрации содержимого организации должно быть разрешено установить систему кэширования.
Когда автор книги помогал одной организации, являющейся провайдером внешних услуг, разрабатывать правила безопасности, ее представители выразили беспокойство, не будут ли правила ограничивать их пользователей в создании Web-страниц. Они утверждали, что это является расширением их творческой активности, и, по этой причине, не хотели останавливать такую практику. У автора книги данная, так называемая, практика вызвала некоторые подозрения. Почему провайдеры были так уверены, что кто-то не злоупотребляет своими привилегиями?
Позже автор начал исследовать сеть организации извне. Во-первых, используя некоторые стандартные средства, удалось обнаружить все серверы, обслуживающие WеЬ-системы. В результате тестирования были обнаружены серверы на нестандартных портах. На основе этой информации были преобразованы адреса поиска, чтобы установить, какому имени какой адрес соответствует. Обнаружилось, что один из адресов имеет резервное имя, зарегистрированное в InterNIC (Internet Network Information Center— информационный центр сети Internet). Используя новое имя и броузер, автор получил доступ к сайту. То, что удалось обнаружить на этом сайте, шокировало людей, с которыми он сотрудничал. Информация совершенно не соответствовала целям организации и могла считаться запрещенной.
Поскольку мы пребывали только на этапе разработки правил, не было никакой возможности наложить дисциплинарное взыскание на конкретного служащего. Конечно, можно было бы применить некоторые санкции, но не столь серьезные, как хотелось бы. Это подтолкнуло к разработке правила, которое выглядит так.
Служащим организации нужно разрешить создавать неофициальные сайты в сети организации. Эти Web-сайты должны быть доступны только внутри организации. Пользователи, которые хотят, чтобы содержимое их сайтов было доступно из Internet, должны, прежде чем сделать свои страницы доступными, предоставить их для просмотра комиссии, возглавленной арт-директором. Арт-директор должен использовать правила в качестве руководства, по которому производится ревизия сайта, он также отвечает за решения об отказе в праве доступа к сайту или разрешении.
Это правило было сформулировано для организации, в которой насчитывалось меньше 75 пользователей, чьи Web-серверы размещены у ближайшего провайдера услуг. Внедрение данного правила в дальнейшем избавило организацию от проблем с генерируемым пользователями содержимым.
Электронная торговля
При бурном развитии Internet наиболее распространенной формой электронной торговли стала покупка и продажа товаров через Internet. Однако, задумывался ли читатель о правилах и практических шагах, которые необходимы для обеспечения безопасности систем электронной торговли? Проблема многих организаций состоит в том, что, желая как можно быстрее установить узел электронной торговли, они не включают в свою стратегию вопросы обеспечения безопасности этих процессов. Поэтому правила и технология могут не соответствовать планам электронной торговли.
Электронная торговля до Internet
До Internet в бизнесе проводились поиски способов автоматизации закупки товаров и услуг. Раньше такие службы, как CompuServe, предлагали потребителям способы проведения торговых операций в онлайновом режиме, поскольку для заключения соглашений и сделок был создан электронный обмен данными (EDI — electronic data interchange). Несмотря на существование и этих и других форм электронной торговли, мы будем концентрировать свое внимание на тех формах, которые используются в настоящее время в Internet. Их можно применить также в качестве образца при разработке правил для других форм электронной торговли.
Сведения о проблемах регулярно документируются в серийно выпускаемых изданиях. Истории о похищении кредитных карточек, переводе денег на офшорные счета или даже похищение товаров и услуг являются всего лишь частью проблем. Руководство организации может прочитать эти истории и ужаснуться: а сможет ли оно справиться с этими проблемами!
В последнее время, когда пришлось помочь одной организации в разработке правил электронной торговли, мы приняли решение, что наилучшим подходом будет создание отдельного документа правил и руководств. У этой организации были те же проблемы, что и у других: они усиленно инициировали введение электронной торговли и игнорировали необходимые меры защиты. Фактически, в то время, пока мы разрабатывали эти правила, группа разработчиков системы электронной торговли руководствовалась правилами, в которых предлагалось разработать план модернизации их служб, чтобы привести их в соответствие с требованиями безопасности, записанными в старых правилах.
Независимо от выбранного подхода к правилам электронной торговли существует несколько принципов, которые необходимо рассмотреть.
Если организация при ведении электронной торговли пользуется внешними источниками, то управление узлом будет не столь сложным, как это предлагается выше в списке. Однако, для обеспечения защиты своего сервиса можно работать с провайдером услуг. Необходимо проверить соглашение между организацией и провайдером услуг. В нем должно быть предусмотрено, что вы имеете право проводить аудит этого узла, чтобы убедиться в надлежащей защите сервера, работающего с вашей организацией.
Корректировщики содержимого
Корректировщики содержимого представляют собой языки программирования и языки подготовки сценариев, называемые run anywhere enhancers. Сценарии и аплеты загружаются с сервера для корректировки содержимого при интерактивном взаимодействии с пользователем. Проблема заключается в том, что в броузерах, обеспечивающих соответствующий сервис, найдены уязвимые места в защите. Проблемы приводят к тому, что некоторые организации вынуждены отказаться от использования серверов Internet.
Можно найти технические решения, чтобы программы корректировки содержимого не включать в сеть. К сожалению, пользователи могут и не иметь возможности пользоваться узлами, которые оснащены этими корректировщиками. Несмотря на развитие технологии и уменьшение количества проблем с защитой, организация должна рассмотреть общее влияние на безопасность при включении таких корректировщиков в сеть.
Фильтрующие аплеты
Настоящая индустриальная война ведется между Java и ActiveX за право распространения своего программного обеспечения для аплетов, создающих содержимое серверов. Java говорит о безопасности, a ActiveX говорит о том, что может создавать гибкое динамичное содержимое. Несмотря на то, что обе фирмы серьезно озабочены вопросами безопасности, они обе предоставляют провайдерам информации слишком большую гибкость во взаимоотношениях с пользователями. Обе технологии нацелены на поддержку потребителя, создавая чаты, а также проявляя инициативу на рынке электронных услуг. Эти вопросы необходимо рассмотреть до принятия решения, использовать или нет фильтрующие аплеты.
Модемы и прочие лазейки
Еще один способ расширить доступ к своим сетям заключается в использовании модемов. Некоторые организации эксплуатируют модемные накопители, управляемые отдельными серверами, которые защищают и поддерживают соединения с внешними пользователями. Другие устанавливают модемы на специальных серверах, которые предоставляют доступ минимальному количеству пользователей. Независимо от применяемого метода, общим является то, что администраторы контролируют модемный доступ централизовано.
Профессионалы в области безопасности считают, что централизованное управление модемами является ключевым моментом в управлении устройствами, обеспечивающими временный доступ. Таким образом, они могут контролировать и управлять процессом, не прерывая предоставление услуг. Чего они не желают позволить, так это установки модемов в разных местах сети. Модем, установленный в системе пользователя, которая сконфигурирована для ответов на входящие звонки, является потенциальной точкой доступа для тех. кто хочет взломать сеть.
Пользователи часто подмечают, что они могут установить модемы в своих системах, в которых работают программы, которые могут обеспечить удаленный доступ к их файлам. Эти программы представляют хорошо известные проблемы для информационной защиты, позволяющие любому, кто подключается к модему, получить доступ в систему и к сети, к которой эта система подключена. Более того, поскольку эти модемы не контролируются, администраторы никогда не смогут остановить взломщика до нанесения ущерба.
Помимо атак на отказы в обслуживании (denial of service attacks) существует проблема, которая может вынудить администраторов не спать по ночам - это модем, установленный в сети, которая неправильно сконфигурирована. Если требуется пользователям разрешение для подключения к сети, то администраторы предпочтут иметь правила, позволяющие им управлять доступом. Они потребуют внести в правила запрет на установку модемов без их разрешения. В таком случае в правила можно включить следующее предложение.
Пользователи не должны устанавливать модемы в своих системах или в любом месте сети без соответствующих санкций.
Отметим, что эта формулировка допускает исключения, но они должны быть санкционированы. В данных правилах не уточняется, что представляют собой "соответствующие санкции". Остается руководствоваться принятыми в организации инструкциями по проведению контроля (см. главу 3 "Обязанности в области информационной безопасности").
Не каждой организации нужен модемный доступ к сети. Некоторые организации могут установить всего несколько модемов и разработать правила, обеспечивающие требуемую конфигурацию и соответствие стандартам безопасности. Другие организации поддерживают большое количество модемов, позволяющих пользователям наборный доступ, соединение с сервером и аутентификацию непосредственно в сети. Независимо от требований организации правила безопасности должны поддерживать роль администраторов в контролировании и обслуживании вспомогательных систем.
Если в организации используется модемный накопитель, подключенный к централизованно управляемому серверу, который обеспечивает строгую аутентификацию, формулировка правил может быть следующей.
Системы коммутации должны устанавливаться и управляться системными администраторами. Пользователи, желающие получитъ доступ в сеть посредством модема, должны при подключении проходить аутентификацию. В эту аутентификацию необходимо включитъ компонент безотказности.
В формулировке не указывается, насколько строгим должен быть подход к аутентификации. Вводя лишь "компонент безотказности", вы не связываете внедрение аутентификации только с одним ее типом. Это предполагает, что будет использован некий строгий алгоритм привязки процесса к определенному пользователю. Он может быть каким угодно, начиная с алгоритма PKI и заканчивая аутентификацией с использованием устройств идентификации. Гибкость заключается также в том, что когда биометрия станет доступным средством, то может быть использована технология на ее основе, и не будет необходимости изменять правила.
Надежность загружаемой информации
Из истории известно, что департамент безопасности финансировал исследовательские работы ARPANET (Advanced Research Project Agency network — сеть Агентства перспективных исследовательских разработок) с целью создания способа распределения информации. Открытость ARPANET новым идеям и способность распределять информацию делают эту организацию популярной среди технологов, которые пользуются ее услугами.
С развитием Internet положение не изменилось. Множество узлов Internet хранят миллионы гигабайт программного обеспечения различной степени полезности для каждого. Проблема заключается в том, что существуют узлы, на которых выставлены "более чем опасные" программы, замаскированные под что-то полезное. Среди них попадаются и полезные программы, но содержащие дефекты, которые могут причинить ущерб системе и сети. И, наконец, существуют узлы, которые предлагают программное обеспечение, предназначенное для преднамеренного повреждения системы или сети.
С учетом всего этого существует тенденция разрабатывать правила, запрещающие использование всего загружаемого из Internet программного обеспечения. Однако, если это сделать, то пользователи не смогут загружать последние обновления Web-броузеров. Поиск способа избежать проблем с загружаемым программным обеспечением путем создания действенных правил является, в некотором смысле, вызовом. Можно не хотеть допускать вседозволенность, но и можно было бы написать такую формулировку, которая бы предотвратила проблемы.
Пользователи могут загружать программное обеспечение из Internet, которое поможет им выполнять свои функции в организации. Пользователи, которые загружают программное обеспечение, должны делать это в системе, которая защищена постоянно обновляющимися антивирусными программами. Пользователи не должны отключатъ антивирусное программное обеспечение при запуске загружаемого из Internet в систему пользователя программного обеспечения. Если для инсталляции программного обеспечения необходимо отключить антивирусные программы, то пользователь должен провести полное антивирусное сканирование системы после завершения инсталляции.
Обязанности пользователей
Правила, устанавливающие обязанности пользователей, служат в организации для того, чтобы пользователи знали, каким образом разрешено им работать в Internet. В некоторых организациях из тех, с которыми сотрудничал автор, данный раздел служил для определения характера и стиля правил, особенно касающихся тех аспектов, которыми больше всего интересуются пользователи.
Обучение
Пользователи могут полагать, что им не нужен инструктаж для получения доступа к Internet, но здесь имеется в виду инструктаж не о том, как им получить доступ в Internet, a об их ответственности за работу в Internet. Организации должны быть осторожными при разрешении какого-то типа трафика, потому что посредством его можно со стороны получить представление об организации. Очень важно, как воспринимается организация внешней средой, и это должно быть поставлено во главу утла в вашей программе обучения.
Все организации могут проводить тот или иной инструктаж. Самые мелкие организации могут использовать простую программу обучения наподобие собеседования, когда кто-нибудь непосредственно беседует с пользователем. Есть такие организации, в которых инструктаж является элементом программы набора новых служащих, а также есть организации, которые составляют в расширенной форме правила безопасности для ознакомления с ними пользователей. Как вы организуете инструктаж, от этого зависит восприятие его пользователями. Но в первую очередь необходимо зафиксировать это в правилах.
Пользователи, имеющие доступ к Internet, должны предварительно пройти программу обучения, где будет разъяснена политика компании в сфере безопасности и ответственность пользователей за представление компании в мировой сети. Пользователи не должны пользоваться Internet до тех пор, пока полностью не пройдут установленную программу обучения.
Ответственность за приложения
По большей части, ответственные за данные и процессы лица не столь осведомлены в тонкостях технологии, как программисты или администраторы. Даже те, кто начал свою карьеру как "технарь", сейчас обнаруживают себя во власти приложений, которые развертывают и с которыми работают в системе информационной безопасности организации.
Правила работы в Internet, касающиеся приложений, должны касаться только защиты данных и пересылки файлов, а также аутентификации во время этих пересылок. Прочие аспекты безопасности приложений следует включить в правила, относящиеся к другим сферам деятельности, таким как разработка программного обеспечения организации собственными силами (см. главу 10 "Правила разработки программного обеспечения"). Если не усложнять эти вопросы, то можно будет сфокусировать свое внимание в пределах сферы своих интересов.
Пересылка данных и файлов
Каждый протокол обеспечивает определенный способ пересылки данных между пользователями с различной степенью защищенности. Несмотря на то, что все протоколы служат всего лишь для пересылки данных, некоторые протоколы не гарантируют, что данные дойдут по назначению. Мы используем их для того, чтобы быть уверенными в достоверности пересылаемых данных. На самом деле, это вовсе не так. Надежное завершение передачи данных и файлов зависит от протоколов верхних уровней, взаимодействия программ, а также вмешательства людей.
Ситуация с безопасностью усложняется еще и тем, что есть вероятность, что кто-нибудь (человек или программа) может перехватить пересылаемую в Internet информацию и прочитать ее. Данные организации могут быть считаны любым, кто имеет доступ к инфраструктуре Internet во время передачи. Обычно его называют человеком в центре атаки.
Прочитав последние два абзаца, кто-нибудь, возможно, задастся вопросом: "А где здесь, собственно, говорится о правилах безопасности?" Суть заключается не в создании правил, регламентирующих защиту. Правила должны рекомендовать ответственным за информацию осознать, какую роль играют приложения при пересылке файлов, а также обеспечить защиту этих данных. Это довольно просто сделать, написав формулировку правил, подобную следующей.
Ответственные за информацию и процессы лица должны оценивать все приложения с точки зрения того, обеспечивается ли безопасность пересылки данных и файлов в соответствии с требованиями, выдвигаемыми бизнесом. Помимо всего прочего, в защиту пересылаемых данных необходимо включить обеспечение гарантий, что данные доходят по назначению и не могут никем быть считаны в процессе их пересылки.
Эта формулировка правил написана в самом обобщенном виде и подразумевает применение для обеспечения безопасности пересылки только шифрования. Тем не менее, этого вполне достаточно, чтобы ответственные за развертывание приложений и за распространение данных организации лица учитывали последствия от принятых ими решений.
Пересылка важной информации
В последнем разделе в правилах говорилось о том, чтобы не пересылать конфиденциальную информацию "без соответствующих мер предосторожности". Определение соответствующих мер предосторожности зависит от того, как составлены правила, и от требований организации. Требования организации зависят от многих факторов, включая договорные обязательства. Например, подрядчики федерального правительства вводят ограничения на информацию, которую могут пересылать, даже внутри своих локальных сетей.
Другой вопрос, на который необходимо обратить внимание, это непреднамеренное раскрытие информации. Пользователи, которые "бегают" по сети, заходят на узлы, на которых для получения информации требуется заполнить онлайновые формы. Эти формы могут запрашивать некоторую информацию. Поэтому, если много людей посетит этот узел, совокупная информация, которую они все вместе дают, может предоставить кому-то сведения об организации.
В идеале, можно написать правило, следуя которому при запросе пользователя группа безопасности организации заполняет онлайновые формы или сама осуществляет онлайновые запросы, полностью контролируя сообщения. Но на деле все происходит иначе. Можно с уверенностью сказать, что если кому-то потребуется отправить официальный документ компании, сомнительный с точки зрения службы безопасности, вряд ли он захочет представить свой запрос на утверждение. Что же касается правил, то в них необходимо внести такую формулировку, которая будет исполняться, и рассчитывать на то, что обучение персонала, наблюдение и контроль за сетью обеспечат неразглашение важной информации.
Некоторые люди видят два пути решения данной проблемы. Наиболее распространенный способ заключается в обновлении учебных программ, в которых предусмотрена более тщательная проработка этих вопросов. Другое популярное правило требует установить фильтры, которые будут просматривать содержание всей корреспонденции, которая отправляется в Internet. В отношении таких фильтров существуют технические проблемы, которые в этой книге не рассматриваются. Но для некоторых организаций решение настоящей задачи является важным делом. Учитывая это, формулировка правил может выглядеть следующим образом.
Пользователи не должны передавать никакой информации, которая раскрывает сведения об интеллектуальной собственности или деловой активности организации. Пользователи не должны преднамеренно пересылать документы или другие данные клиентам или сторонним лицам без соответствующих мер предосторожности. В меры предосторожности, помимо всего прочего, необходимо включитъ шифрование, пересылку по выделенному каналy и санкционирование лица, ответственного за эту информацию.
Подход к Internet
Логично начинать писать правила, подходя к теме с парадного входа. Ваш подход к Internet может основываться на одной из нескольких технологий и требовать особой конфигурации аппаратных средств. После подключения к Internet этот подход станет основным для всех вспомогательных служб и сделает доступным для внешнего мира некоторые или все сети организации, а также предоставит сотрудникам вашей организации доступ к внешним сетям. Когда автор книги сотрудничал с различными компаниями по разработке правил безопасности Internet, он выделял два основных вопроса в этой работе.
Понимание возможностей, предоставляемых Internet
Когда автор помогал организациям разрабатывать правила безопасности, он старался удержать их от попыток включить в правила формулировки, которые являются частью программы инструктажа. Одним из таких понятий, которые не должны попасть в правила, является разъяснение того, что значит для организации соблюдение правил безопасности. В организации хотели, чтобы это понятие было записано в правилах, потому что этот документ утверждается высшим руководством. Такую логику, конечно, трудно оспорить.
В процессе тщательного анализа выявляются два пункта, которые должны присутствовать в данном разделе. Во-первых, формулировка должна разъяснять, что, получив доступ к ресурсам Internet, сотрудники для окружающего мира являются уже представителями организации. Независимо от того, приходит запрос с IP-адреса или в письменном виде, трафик пользователей, их слова и действия отражаются на деятельности организации.
Другой вопрос заключается в том, какая информация организации становится доступной при работе пользователей в Internet. В предыдущих главах описывалось, каким образом с помощью протоколов может разглашаться информация о сети организации. Все, что сделано для защиты сети, может стать бесполезным, если пользователь пересылает информацию, которая не должна разглашаться. Кроме того, пользователи вообще должны быть осторожны при распространении информации, причем речь идет не только об информации организации, но и о личной информации.
Эти формулировки правил необязательно конкретизировать, но они должны очень четко разъяснять, какой информацией организация может быть представлена в сети. Ниже представлена формулировка, которая была написана для одной организации.
Пользователи должны помнить, что, поскольку они имеют доступ к ресурсам Internet, они будут представлять организацию через TCP/IP протоколы. Поэтому, пользователям следует получать доступ к ресурсам в соответствии с их должностными инструкциями. Пользователи могут получать доступ к узлам в личных целях, но этот доступ нужно свести к минимуму.
Пользователи не должны обращаться к узлам, которые содержат запрещенную, сексуальную и прочую информацию, получение которой противоречит данному и другим правилам, принятым в организации.
Работая в онлайновом режиме пользователи должны быть осторожны в вопросах предоставления информации. Им следует помнить, что посланная по электронной почте информация не является приватной, и все, что они отсылают, может быть прочитано по пути прохождения информации. Кроме того, пользователи не должны пересылать никакой информации, которая может нанести ущерб репутации организации или их личной. Конфиденциальная информация, как это сказано и в других правилах, не должна пересылаться без соответствующих мер предосторожности. Пользователям следует принимать такие же меры предосторожности и при пересылке личной информации.
Стоит также отметить формулировку из первого абзаца ограничений. Хотя ограничение доступа к определенным узлам будет описано в этой главе позже, данные формулировки служат в качестве еще одного подтверждения тому, что можно ожидать от пользователей. Остальные формулировки относятся к другим правилам.
Правила безопасности Internet
С развитием технологий Internet каждая организация стремится подключить к Internet свои системы и инфраструктуры. Эта книга полезна для тех, чья организация вошла в мир пользователей системы реального времени, и, поэтому, необходимо позаботиться о ее защите от вмешательства извне. Проблема в том, что многие разработчики политики безопасности организации рассматривают правила безопасности Internet как руководство по всеобщей защите сетей организации. Те, кто прочитал предыдущие главы, уже знают, что предпочтительней разрабатывать несколько документов правил, которые охватывают различные аспекты программы защиты информации. Правила безопасности Internet являются всего лишь частью этой программы.
Общепринятая точка зрения на разработку правил безопасности Internet заключается в том, что их довольно легко написать, поскольку об Internet знает каждый. В ряде случаев это действительно так. Тем не менее, поскольку технологии меняются очень быстро, а в некоторых организациях сильна тенденция бросаться внедрять все "сенсационные" открытия, довольно сложно написать правила, охватывающие все нововведения. Несмотря на то, что охватить все аспекты безопасности Internet довольно сложно, можно использовать прагматичный подход, чтобы быть уверенным, что правилами охвачены все необходимые вопросы. Также, как было сделано с политикой безопасности вообще, правила безопасности Internet можно разбить на логические группы в соответствии с различными технологиями Internet. В этой главе описаны логические группы, на которые разбиваются технологии Internet, а также дается объяснение, каким образом технологии отражаются в разрабатываемых правилах.
Правила работы в WWW
Здесь речь идет о сфере деятельности настолько знакомой, что это приводит к упущениям в правилах. О Web знают все. Каждый использует Web и имеет свой собственный взгляд на правила работы с ней. Web может быть мощным помощником, а также источником проблем. Целью разработки правил работы в Web является обеспечение информационной безопасности организации во время работы в Web и, в то же время, не перегрузить правила ненужными для пользователей и невыполнимыми запретами и ограничениями.
Правила управления входящим трафиком
Первое, о чем думают люди при обсуждении управления поступающим от Internet информационным потоком, — это брандмауэр. Брандмауэр представляет собой устройство, которое помогает управлять трафиком, обеспечивая реализацию жестких правил, устанавливающих, что допускается к поступлению в сеть и что может выходить из сети. Средствами управления сетевым трафиком являются не только брандмауэры. При разработке правил управления трафиком необходимо учитывать размещение брандмауэра в сети и режим его работы.
Несмотря на то, что существует множество способов сконфигурировать подключение к Internet, я предлагаю любой организации рассмотреть только два типа архитектуры, позволяющих разделить трафик Internet и сеть организации. Они изображены на рис. 6.1 и рис. 6.2. Оба эти метода основываются на создании сегмента сети, который обеспечивает защиту от Internet и является дополнительным элементом защиты сети организации. Архитектура такого типа подразумевает создание так называемой демилитаризованной зоны (DMZ— DeMilitarized Zone) или защищенной локальной сети (LAN — Local Area Network), которая является одним из типов изолированного сегмента сети. На рис. 6.1 изображена общепринятая архитектура, в которой для изоляции сегмента сети создается DMZ с помощью двух брандмауэров. В данной архитектуре брандмауэр Internet используется в качестве фильтра для ограничения трафика из Internet, а внутренний брандмауэр обеспечивает дополнительную защиту локальной сети организации.
Другой способ обезопасить сетевой трафик — создать сегмент DMZ, который направляет трафик Internet в отдельную часть сети (рис. 6.2). Преимуществом такой архитектуры является то, что требуется только один брандмауэр, который направляет трафик так, что он не попадает в сеть организации. Какую бы архитектуру вы ни выбрали, важно создать участок сети, обслуживающий запросы Internet, который защитит внутреннюю сеть организации от нежелательного трафика, но при этом позволяет пользователям организации получать доступ к Internet.
Рис. 6.1. Архитектура сети, в которой DMZ создается с помощью двух брандмауэров, чтобы изолировать системы, обслуживающие пользователей Internet
Рис. 6.2. Архитектура сети, в которой DMZ создается с помощью одного брандмауэра, чтобы создать изолированную сеть, обслуживающую пользователей Internet
Варианты архитектурных решений
Вариант с использованием DMZ подразумевает, что в организации имеется своя собственная служба internet, использующая один из типов постоянного подключения. В действительности могут использоваться различные типы вспомогательных систем, для которых должны быть разработаны свои собственные варианты правил. Например, если в вашей организации имеется хост-система, то необязательно разрабатывать правила архитектурных решений. Прежде, чем формулировать правила для конкретной организации, необходимо удостовериться, что они могут быть претворены в жизнь, особенно в том случае, если у вас не получится внедрить архитектурные решения, принятые вашим Internet-провайдером (ISP) (Internet Service Provider — Internet-провайдер, или поставщик услуг Internet).
Правило конфиденциальности
Наиболее спорный аспект, касающийся Web-серверов, заключается в том, как распоряжаются информацией ответственные за нее лица после ее получения из соответствующих вспомогательных систем. Эксперты в области безопасности обеспокоены тем, что мы выдаем стишком много личной информации при поисках нужного содержимого и удобства пользования. Создается впечатление, что каждый беспокоится о конфиденциальности и занимается поиском собственников Web-серверов, чтобы продемонстрировать свое добропорядочное гражданство, а также раскрыть, каким образом он использует собираемую информацию. Это раскрытие определяется правилом конфиденциальности.
Следование правилу конфиденциальности несколько отличается от следования правилу раскрытия информации. Правило конфиденциальности представляет собой общедоступную формулировку и разъясняет пользователям, какую личную информацию можно собирать, и как организация собирается распорядиться этими данными. По причине непостоянства правила конфиденциальности не рекомендуется включать его в документы правил информационной безопасности. Однако, необходима рекомендация, как создать документ, доступный каждому для прочтения. Формулировка правила могла бы выглядеть следующим образом.
На Web-cepвepax должно находиться общедоступное правило конфиденциальности, разъясняющее, какую информацию можно собирать, и что организация может делать с этими данными. Правило конфиденциальности должно быть общедоступным на основе подключения к обслуживаемым, страницам.
Преобразование сетевых адресов
В главе 5 "Аутентификация и безопасность сети" обсуждалось использование преобразования сетевых адресов (NАТ— Network Address Translation) в качестве инструмента системы безопасности, обеспечивающего сокрытие внутренней структуры сети организации от внешних пользователей. Если организация приняла решение, что NАТ должно стать частью программы информационной безопасности, то можно заново вставить формулировку в правила безопасности Internet, например, такую.
Адреса внутренней сети организации должны оставаться скрытыми. Когда системам необходим доступ к другим сетям, то перед передачей скрытый адрес может быть преобразован в открытый, зарегистрированный адрес.
Применение PKI и других средств контроля
Может быть, читатель слышал об инфраструктуре открытого ключа (PKI— public key infrastructure), которую называют "чашей Грааля" в идентификации и аутентификации пользователей. В PKI используются технологии криптографии с открытым ключом для аутентификации пользователей и защищенного обмена данными. В PKI используются цифровые сертификаты для идентификации пользователей, предъявляющих такие сертификаты.
Что такое криптография с открытым ключом?
Криптография является наукой, разрабатывающей алгоритмы, использующие зашифрованные данные для хранения или пересылки информации. В шифровании эти алгоритмы используются для преобразования данных в непонятную форму. Выражаясь общими терминами, в шифровании используется секретный ключ, то есть секретные величины для выполнения математических действий с данными, чтобы сделать их непонятными для постороннего наблюдателя. По традиции, для шифрования и дешифрования данных требуется один и тот же ключ. Этот метод называется симметричным шифрованием.
Криптография с открытым ключом отличается только тем, что математические функции могут использовать два различных, но математически связанных ключа. С помощью математических функций генерируется два ключа: один хранится в секрете, а другой может передаваться открыто. Если кто-то захочет отправить вам зашифрованный файл, он зашифрует его с помощью вашего открытого ключа. Для дешифрования сообщения нужно использовать только свой секретный ключ. Этот метод называется асимметричным шифрованием.
PKI использует криптографию с открытым ключом, используя цифровые сертификаты, которые создаются для подключения секретного ключа. Секретный ключ может быть сверен только вместе с открытым ключом.
Создать сетевые компоненты проверки РК1 довольно непросто. Существует множество коммерческих пакетов, которые могут помочь в этом, но ни один из них не обеспечивает целостный процесс. Кроме того, для работы с PKI нет единого стандарта.
В настоящее время наиболее распространенный способ использования компонентов PKI основан на электронных коммерческих инициативах, доступных через броузеры. Поскольку при этом не рассматривается "реальное" PKI, мы не учитываем такой способ при разработке правил работы с PKI.
Так как стандарты для PKI и технологии постоянно меняются, довольно сложно разработать единое правило, касающееся PKI. Если организация развертывает PKI, то рекомендуется писать отдельный документ правил и процедур PKI. Это позволит учесть то, что может оказаться полезным для программы безопасности организации.
Тем. кто хочет больше узнать о PKI, рекомендуем найти книгу Understanding PKI, написанную Карлайлом Адамсом (Carlisle Adams) и Стивом Ллойдом (Steve Llovd) (Macmillan Technical Publishing, 1999. ISBN: 1-57870-166-X).
Профилактическое обслуживание
Первая обязанность, о которой нужно поговорить, — это профилактическое обслуживание. В правилах должно быть требование к системным администраторам проводить регулярное обслуживание для поддержания порядка в общедоступных данных. Хоть и звучит это довольно обыденно, есть организации, которые не проводят обслуживание Web-серверов, ftp-архивов и других, требующих обслуживания систем. Не выдвигая такого жесткого требования, в некоторых организациях просто игнорируют общедоступные в информационном плане части системы. Друг автора книги работал в компании с небольшим Web-сервером, чья загрузочная область стала местом хранения средств хакеров. Сервер никогда не проверялся, и Web-сервер был взломан для того, чтобы на нем можно было хранить файлы.
Эти проблемы касаются не только организаций, имеющих собственные серверы. Организации, получающие услуги Internet со стороны, должны иметь правила с требованиями о том, чтобы в договоры на услуги были включены соглашения об обслуживании или профилактических работах, которые позволят администраторам организации проводить такой тип обслуживания. В любом случае следует записать в правилах, что обслуживание должно проводиться, но не должно быть записано, как это обслуживание будет проводиться. Это относится к процедурам, а не к правилам.
Разрешенные вспомогательные процедуры
Вместо того, чтобы привязывать разрабатываемые правила к определенным аппаратным средствам или типам брандмауэров, лучше разработать правила, в которых обозначены вспомогательные процедуры, которые разрешены брандмауэрам. Определение в правилах вспомогательных процедур или даже вариантов предполагаемого трафика не ограничивает организацию в выборе решений.
Существует два способа составления правил, определяющих доступные вспомогательные процедуры. Один из них заключается в написании правила, в котором говорится, что вспомогательные процедуры определяются как часть процедур администратора сети, предназначенные для управления брандмауэрами. Такая трактовка правила дает возможность определять в организации вспомогательные процедуры, поддерживающие бизнес-процесс, и которые могут быть при случае пересмотрены внутри организации. Такое правило также позволит организации добавлять при необходимости новые вспомогательные процедуры, не внося изменений в документ правил. Если организация приняла для себя правила такого типа, то можно написать формулировку наподобие следующей.
Вспомогательные процедуры, поддерживаемые шлюзом Internet, должны назначаться комиссией, ответственной за использование необходимых вспомогательных процедур на шлюзе, соответствующих требованиям технологии.
Другой способ определения того, работу каких вспомогательных процедур разрешать на шлюзе, заключается в регламентации их в документе правил. Многие организации предпочитают определять вспомогательные процедуры в правилах, чтобы придать им больший вес. При разработке правил использования специальных вспомогательных процедур необходимо определить назначение вспомогательных систем протоколом, а также, распространяется ли действие правил на входящую информацию (например, поступающую из Internet) или на исходящую (из организации в Internet). В табл. 6.1 приведены общепринятые вспомогательные системы, которые могут быть учтены в правилах.
Таблица 6.1. Вспомогательные системы, рассматриваемые при разработке правил
| Вспомогательные системы для работы с входной информацией | Вспомогательные системы для работы с исходящей информацией | Типы ICMP |
| Службы именования доменов (DNS) | Службы именования доменов (DNS) | Отображение |
| HTTP/HTTPS | HTTP/HTTPS | Time Exceeded In-Transit |
| SMTP, POP, IMAP | SMTP | Недоступный хост (Host Unreachable) |
| FTP | FTP, NTP | Необходимое разбиение (Need to frag) |
| LDAP | Telnet/SSH | |
| Виртуальная частная сеть и терминальные системы | NNTP | |
| Потоковое аудио (Реальное аудио) |
Шлюз Internet должен предотвращать пропуск UDP-пакетов из Internet в сеть организации ЗА ИСКЛЮЧЕНИЕМ UDP-пакетов, запрашивающих общедоступные службы именования доменов, доступных на порте 53.
Отметим, что такая формулировка правил предназначена для "входящих" процедур, поскольку в ней сказано "из Internet в сеть организации". Она не накладывает ограничений на исходящие процедуры. Как правило, в организации стараются не обращать внимание на то, каким образом их пользователи получают доступ к исходящим процедурам. Однако, при такой формулировке правил ответы внешних UDP-систем, направленные пользователям организации, будут блокироваться. Это не всегда плохо, но если работа организации с клиентами зависит от таких служб, как сетевая файловая система (NFS — Network File System), или других служб, обслуживающих сетевые имена, то придется откорректировать правила, чтобы обеспечить работу этих служб.
Для некоторых организаций разрешение исходящих процедур UDP выглядит вполне безобидно. В процессе поисков в Internet можно найти программу, которую следует использовать для замены служб на основе UDP. Но природа UDP. не ориентированная на установление соединения, все еще представляет собой проблему, поскольку реально не существует целостности соединения для защиты передачи информации. У многих таких систем имеются известные уязвимые места, которые представляют угрозу целостности сетевых данных.
Другая проблематичная область политики заключается в разработке правил использования протокола управления сообщениями в сети Internet (ICMP — Internet Control Message Protocol). ICMP используется для передачи сообщений об ошибках между компонентами сети. ICMP передается на уровне IP и используется только между компонентами сети. Можно зафиксировать работу ICMP с помощью программ типа ping и traceroute (или tracert). Однако, эти сообщения об ошибках можно использовать для составления карты сети, определения того, работает ли система и доступна ли она из сети, а также они могут представлять и другие интересные сведения для потенциального взломщика (см. "ICMP-вторжения").
Проблема, связанная с использованием ICMP, заключается в том, что после того, как вы узнали о проблеме, появляется желание написать правило блокирования ICMP на брандмауэре. При осуществлении данного желания теряется возможность получения ICMP-сообщений host unreachable (недоступный хост) и need to frag (необходимо разбиение). Для управления исходящим трафиком организации необходимо иметь возможность получать эти сообщения. Ввиду сложности таких решений рекомендуется не включать эти вопросы в документы, определяющие политику. Однако, если есть желание упомянуть об этом, то можно составить следующую формулировку.
Инструкции для систем, базирующихся на использовании ICMP, должны определять, каким образом можно манипулировать процедурами ICMP для создания злоумышленного трафика, который может пройти незамеченно.В этих инструкциях должны быть учтены типы процедур ICMP, необходимые для управления трафиком между сетью организации и Internet.
ICMP-вторжения
Рассмотрение всех проблем, связанных с применением ICMP, выходит за рамки этой книги. Но можно получить информацию об опасностях применения ICMP в книге Стивена Норткатта (Stephen Northcutt) и Джуди Новак (Judy Novak) Network Intrusion Detection: An Analyst's Handbook, Second Edition (New Riders Publishing, 2000, ISBN 0-7357-1008-2). Там же можно найти информацию о технических аспектах обнаружения вторжений.
Правила безопасности Internet довольно сложно
Правила безопасности Internet довольно сложно разрабатывать из-за быстрого изменения технологий. Вместо того, чтобы разрабатывать одно общее правило, разработчик может подойти к разработке правил безопасности Internet, разбив известные технологии на логические группы и создавая правило для каждой области применения.
- Хранение данных
- Идентификация и аутентификация
- Защита пересылки данных
- Методы обработки заказов
- Даже если организация при ведении электронной торговли пользуется внешними источниками, разработанные вами правила безопасности могут быть основой для составления контрактов вашей организации с провайдерами услуг.
Сетевые конференции Usenet
Автор всегда избегал обсуждения специфических правил для систем специального назначения. Если они не описывались в других разделах, то всегда возникало сомнение, стоит ли включать их в документы, определяющие политику. Включение этих деталей в документы политики не позволит быстро вносить изменения в систему, необходимые для поддержания соответствующей среды. В большинстве случаев процедуры можно обновить за несколько минут, но изменение и экспертиза правил безопасности потребуют длительного времени.
Однако, для сетевых конференций можно сделать исключение. Созданная в 1979 году студентами-выпускниками университета в Северной Каролине и королевского университета Usenet превратилась из инструмента Internet, предназначенного для распределения информации, в то, чем она является сегодня. Для некоторых из нас, кто пользовался Usenet с самого начала, эта эволюция не является предметом особой гордости. Несмотря на то, что существует множество производственных сетевых конференций, которые предоставляют полезную информацию, Usenet стала катализатором множества проблем, с которыми мы сталкиваемся в Internet.
Usenet не является только службой, относящейся к определенной категории, но именно это больше всего бросается в глаза. Сетевые конференции Usenet требуют от организации поддержки множества ресурсов. Даже если для Usenet выделен отдельный сервер, дисковое пространство, требуемое для поддержки необходимых архивов, может оказаться большим, чем то, с которым оперирует небольшая или средних размеров организация. Так что при анализе информации, которой обмениваются, можно сделать вывод, что для большинства организаций большая часть трафика не обеспечивает функционирование их бизнеса.
После такой информации большинство организаций хотят ввести в правила предписания, запрещающие доступ пользователей к сетевым конференциям Usenet. Однако, полный запрет использования Usenet может лишить организацию доступа к некоторым очень полезным ресурсам. Система информационной безопасности и штат системного администратора могли бы извлечь выгоду из доступа к сетевым конференциям, где могли бы обмениваться информацией с коллегами, а также пользоваться другими ценными источниками.
Найти золотую середину довольно непросто. Если у организации есть желание разрешить доступ пользователям к Usenet, то необходимо прежде оценить свои возможности. Организация может содержать собственный хост или иметь доступ к серверам провайдера услуг, или же использовать внешний сервис так, чтобы трафик Usenet не влиял на сеть организации. В любом случае в правилах должно быть отражено, что приемлемо для использования сетевых конференции Usenet.
В качестве примера предположим, что организация разрешила ограниченный доступ к новостям Usenet без ограничений на то, каким образом будет обеспечен доступ к конференциям. Предписания политики разрешат сетевые конференции, которые будут полезны для бизнеса, а также позволят вносить в любое время поправки в список пользователей, кому предоставляются эти услуги. Можно написать формулировку правил наподобие следующей.
Организация поддерживает ограниченный доступ к сетевым конференциям Usenet. Эта поддержка распространяется на подсписок конференций, которые могут быть использованы для обеспечения деловой деятельности организации.
Список конференций, к которым пользователи могут иметь доступ, регламентируется администраторами сети. Этот список может быть изменен только по письменному заявлению. В заявлении должна быть указана причина, по которой деловая деятельность заявителя требует доступа к конференциям. Запросы не будут удовлетворены, если не будет аргументирована производственная необходимость доступа к конференциям. Наблюдательная комиссия периодически корректирует этот список.
И, наконец, если разрешен доступ к новостям Usenet, может возникнуть желание проинструктировать своих пользователей. Так же. как и при работе с электронной почтой и в других сферах деятельности, где пользователи могут не только получать информацию, но и вносить свою лепту, их замечания могут отражаться на имидже организации. В данной книге описываются правила инструктирования тех, кто работает в других областях. Но здесь можно включить общую формулировку.
Пользователи, имеющие доступ к конференциям Usenet, должны пройти предварительный инструктаж и записать, в чем состоит польза от их участия в конференциях Usenet. В инструктаж необходимо включить описание того, каким образом организация предоставляет доступ пользователям к сетевым конференциям. Кроме того, пользователей необходимо проинструктировать об использовании запантентованной в организации информации и интеллектуальной собственности.
Соглашения с внешними источниками
Соглашения с внешними источниками представляют собой довольно интересную проблему, поскольку организации вообще могут не управлять серверами. Это также становится проблемой для организаций, которые могут поддерживать собственные серверы, но управление отдельными их функциями передать внешним источникам. В таком случае достаточно иметь инструкции, но в правила следует включить требование того, чтобы обслуживание входило в условия контракта. Некоторые организации используют формулировку правил, подобную следующей.
Администраторы несут ответственность за процедуры обслуживания серверов, предоставляющих информацию или усгуги пользователям Internet. Совместно используемые серверы или принадлежащие внешним провайдерам также должны обслуживаться по инструкциям, согласованным в контрактах на предоставление услуг.
Управление содержимым
В предыдущих главах говорилось о праве на информацию. Концепция заключалась в том, что одно лицо или ведомство назначается ответственным за информацию, относящуюся к определенному бизнес-процессу. Таким образом, создается система защиты данных и устанавливается ответственность за ее целостность и безопасность. В отношении Web-серверов все должно быть точно так же. Даже в том случае, если организация заключает договор о Web-услугах, кто-то из организации должен отвечать за содержимое.
В каждой Web-системе имеется несколько способов управлять содержимым. Поэтому довольно сложно составить правила, в которых в достаточной мере будут учтены все способы управления данными. Проблема заключается в том, что правила должны определять не только ответственных за содержимое, но также и то, каким образом это содержимое изменять и управлять им.
Виртуальные частные сети, экстрасети, внутренние сети и другие туннели
В результате расширения Internet, а также Internet-технологий появились новые возможности расширения сетевой инфраструктуры организации за счет подключения удаленных офисов, покупателей и даже для связи служащих друг с другом через общедоступные сети. Мы осуществляем эти дополнительные услуги путем создания туннеля между локальной сетью и удаленным узлом.
В сетевой терминологии туннель использует Internet в качестве отдельной частной защищенной сети, определяемой возможным прохождением трафика. Обычно, для предотвращения прослушивания, эти туннели шифруются, но шифрование не является обязательным требованием. В конце концов, протокол двухточечной связи РРР (point-to-point protocol) является протоколом туннелирования. Однако, если организации собираются расширить свои сети на множество офисов или для предоставления доступа клиентам, то шифрование предназначается для создания виртуальных частных сетей (VPN — Virtual Private Network).
Туннелирование нужно не всем организациям. Если же организации это необходимо, то можно написать очень простую формулировку правил, в которой будут определены основы того, что хочет использовать данная организация. Формулировка может быть следующей.
Администраторы данных и процессов, которые используют туннелирование, должны гарантировать, что, применяя шифрование, пересылаемая информация не будет прочитана нигде, кроме удаленной системы.
Внедрение
Администраторы также могут нести ответственность за внедрение. Даже в тех организациях, которые содержат собственный штат, ответственный за безопасность, администраторы находятся на передовой линии обороны. Они знают все о системах, сетях, а также им известны нормативы и те недостатки в сети, на которые нужно обратить внимание. Даже в более мелких организациях, где администраторы выполняют всю работу, они все равно находятся на передней линии внедрения. Несмотря на то, что в других правилах должны полностью определяться роли по внедрению, имеет смысл составить правило с формулировкой требований по внедрению наподобие следующей.
Администраторы должны внедрять правила в соответствии с утвержденными инструкциями. Инструкции администрирования должны регламентировать контроль информации, а также защиту информации путем применения соответствующих санкций. Помимо всего прочего в эти инструкции необходимо включить требования по сохранению фактов нарушения служащими дисциплины, а также требование по применению юридических санкций в отношении внешних нарушителей правил безопасности.
Вопросы архитектуры
Правил безопасности интерфейса с Internet может быть разработано столько же, сколько существует различных технологий для подключения организации к миру Internet. Независимо от используемых технологий неизменным остается то, что интерфейсные протоколы не предоставляют никакой защиты. Существуют и дополнительные вопросы, касающиеся протоколов туннелирования, но их мы обсудим позже в разделе "Виртуальные частные сети, экстрасети, интерсети и другие туннели". Целью разработки правил определения архитектуры является обеспечение безопасности интерфейса во время связи через Internet, и, в то же время, чтобы безопасность не являлась препятствием нормальному доступу к Internet.
Одна из проблем, с которыми можно столкнуться при разработке правил работы в Internet для вашей организации, заключается в необходимости учитывать уже существующую архитектуру вместо того, чтобы создать ее по "лучшему образцу". Если вы захотите существенно модернизировать архитектуру, вполне вероятно, что возникнет очень сильное противодействие вашим предложениям. Следует помнить, что правила и процедуры претворения их в жизнь представляют собой эволюционный процесс, и легче достигнуть своей цели путем пошаговых изменений, которые можно было бы предлагать во время каждой очередной модернизации системы.
Защита и обслуживание CGI и других сервисных программ
Мы говорим о производительности, которой располагает Web-сервер для пересылки динамической информации через различные интерфейсы. Эти интерфейсы запрограммированы с использованием сценариев, встроенных команд или языков программирования, которые создают определенные проблемы при защите серверов. Наибольшая опасность заключается в том, что в таких программах могут быть случайные ошибки, алгоритмические ошибки или другие проблемы, связанные с языком программирования. Языки сценариев имеют команды, выполняющиеся внешними программами, в которых могут быть свои ошибки, бреши в защите или незадокументированные особенности, которые тоже могут привести к нарушениям безопасности.
В наше время, когда цикл разработки системы происходит в "эпоху Internet", возникает множество неожиданных проблем в программах в связи с тем, что они эксплуатируются пользователями, а поставляются разработчиками. Не вдаваясь в тонкости развития программного обеспечения, правила должны учитывать современную практику с требованиями присутствия программного обеспечения "вчерашнего дня". Эти правила также не должны быть связаны с правилами разработки программного обеспечения.
При разработке правил для этих вспомогательных программ необходимо рассмотреть два аспекта.
Ревизия программ на предмет выявления ошибок и брешей в защите обычно представляет собой важный этап процесса разработки программного обеспечения, но существует тенденция сдавать в эксплуатацию программное обеспечение, не проведя надлежащего тестирования. Разработав правило, требующее провести такую ревизию, можно надеяться, что разработчики потратят немного дополнительного времени на обеспечение гарантий того, что с этими программами не будет проблем. Формулировка правил может выглядеть следующим образом.
Вспомогательные программы для Web-cepвepoв должны подвергаться тщательной проверке всех компонентов.
Во время ревизии проверяются рабочие характеристики этих программ на предмет непредвиденных результатов по причине сбоев в работе. Кроме того, в процессе ревизии необходимо рассмотреть возникшие проблемы безопасности системы и сети.
Теперь необходимо сосредоточиться непосредственно на элементах программного обеспечения. Существуют два аспекта, по поводу которых стоит беспокоиться. Во-первых, если какой-либо элемент программного обеспечения не используется, то он не должен загружаться или нужно выбрать такую конфигурацию, чтобы сервер его не использовал. Другая проблема состоит в том, что когда эти элементы используются, то следует позаботиться о проблемах безопасности, выявленных исследовательскими группами безопасности, поставщиками и взломщиками. Иногда создается впечатление, что предостережения касательно брешей в защите серверов или программ, генерирующих содержимое, появляются сами еженедельно.
Правила в этих областях довольно сложно трактовать. Если ваша организация использует внешние WеЬ-серверы, то определить их потенциальные проблемы довольно сложно. Можно попробовать заключить соглашение при подписании контракта, которое согласовывалось бы с вашими правилами, но все равно это будет намного сложнее, чем если бы ваша организация имела собственные Web-серверы. Ваши администраторы не могут просто проводить новые патчи или менять конфигурацию, так как не могут быть уверены в том, что эти обновления не приведут к неправильной работе или к выходу из строя сервера или программного обеспечения.
Существует слишком много вариантов, поэтому невозможно решить эти проблемы, составив всего лишь одну формулировку правил. В следующем примере из нескольких различных правил извлечены общие положения и составлена одна общая формулировка. Предлагается в вашей организации использовать нижеследующий пример в качестве руководства по разработке собственного правила, а не в качестве образца, который можно вставить в правила.
Web-серверы должны быть установлены и сконфигурированы так, чтобы обеспечить функционирование только тех вспомогательных систем, которые необходимы для поддержки операционной среды.Администраторы должны отслеживать сообщения систем оповещения о нарушениях безопасности на предмет обнаружения уязвимых мест в установленных компонентах системы. Для тестирования и проведения патчей в установленных компонентах системы администраторы должны работать совместно с программистами и ответственными за информацию лицами.
Защита шлюза
Большинство людей, размышляя о безопасности Internet, концентрируют внимание на брандмауэре. Брандмауэры, независимо от того, являются ли они специализированными устройствами или всего лишь маршрутизаторами отдельных пакетов информации, представляют собой первую линию обороны в системе безопасности Internet. Они размещаются на различных шлюзах сети, чтобы управлять сетевым трафиком. Как уже говорилось в предыдущем разделе, брандмауэры можно использовать для создания сегментов сети, которые будут обеспечивать работу систем открытого доступа и в то же время защищать внутреннюю закрытую сеть организации от пользователей Internet.
Существует тенденция привязывать правила построения брандмауэров к особенностям их функционирования (см. "Типы брандмауэров"). Например, организация, использующая возможности маршрутизатора фильтровать трафик Internet, старается внедрить правила, предписывающие установку фильтрующих брандмауэров. Возможно, это не самый лучший подход к разработке правил, поскольку в этом случае в организации будут вынуждены использовать только определенный вид аппаратных средств. Лучше не поддаваться соблазну создавать правила, привязываясь к определенным аппаратным средствам, а разрабатывать правила, которые будут поддерживать программу безопасности, предусматривающую предоставление определенных услуг (см. "Разрешенные вспомогательные процедуры"). Если проанализировать предоставляемые услуги, можно пересмотреть общий план системы безопасности таким образом, чтобы не быть привязанным к устаревшим аппаратным средствам.
Типы брандмауэров
Как правило, брандмауэры выполняют свою работу, следуя определенным правилам или, как говорят, следуя определенной политике; с помощью фильтрации трафика по признаку принадлежности информации определенному источнику или распознаванию адресов отправителя или портов получателя, извлеченных из содержимого пакетов, или же действуя как промежуточное звено, которое обеспечивает более качественное управление некоторыми вспомогательными системами.
Очень распространено использование возможностей маршрутизатора, соединяющего организацию с Internet, фильтровать информацию. Фильтрующие брандмауэры устанавливаются для разрешения или ограничения входящего и исходящего трафика сети.
Брандмауэры, являющиеся промежуточным звеном, — это системы, которые запускают программы, помогающие пользователю или серверу получить доступ к вспомогательным системам сети. Промежуточные системы обычно используются в том случае, когда брандмауэру необходимо просмотреть данные, передающиеся через Internet, чтобы определить, каким образом их фильтровать. Промежуточные звенья можно также использовать для кэширования часто используемых данных, а также для уменьшения потока данных, посылаемого в Internet.
Другой распространенный метод называется проверкой сохраняемых адресов пакетов (stateful packet inspection). Проверка сохраняемых адресов пакетов используется как часть алгоритма фильтрации пакетов за исключением того, что брандмауэр проверяет содержимое пакетов по определенным характеристикам, чтобы предотвратить нанесение ущерба сети искаженными пакетами.
Цель защиты
Некоторые организации понимают, что необходимо помнить о юридических проблемах, возникающих в результате работы программ сканирования информации на пользовательских системах. Многие же считают, что об этом не стоит беспокоиться, и в вашей организации могут никогда не узнать, насколько неправильно можно истолковывать правила, пока сами не столкнутся с данными проблемами (см. главу 11 "Правила надежной работы"). Это не означает, что проблем нельзя избежать. Но многие корпоративные юристы хотят ввести формулировку о необходимости защиты от вирусов и праве организации выбирать антивирусное программное обеспечение.
Предостережение от традиционного подхода к защите от вирусов
Традиционный подход к защите от вирусов заключается в том, чтобы заниматься только проблемами, возникающими в системах, построенных на платформах Windows различных версий, или в других приложениях, разработанных компанией Microsoft. Однако, проблемы с вирусами возникают и в других системах независимо от того, на какой операционной системе они базируются. Вирусы, которые появляются в определенных приложениях, могут инфицировать любую систему, в которой эти приложения запускаются. Одним из примеров является система Lotus Notes, которая может распространять вирусы на серверы UNIX, запускающие сервер Notes, но также и в том случае, когда запускается Windows NT. Существуют даже "неудаляемые" (proof-of-concept) вирусы для устройств, работающих в PalmOS.
Если организация работает с межплатформными приложениями, то правила должны требовать защиту всех платформ, а не только систем, работающих в Windows.
Один из способов обеспечения ответственности за безопасность информации заключается в том, чтобы включить в правила требование запускать антивирусную программу, причем в правилах должно быть подчеркнуто, что область действия правил ограничивается только этой программой. Несмотря на то, что существует определенная специфика, основанная на стратегии использования антивирусной программы (т.е. централизованные или распределенные программы), следует начать с установки программы. Ниже следует пример формулировки, предложенной юристом.
Организация должна использоватъ все возможности для предотвращения распространения компьютерных вирусов, "червей" и "троянских коней" в сетевых системах. Эти средства необходимо использоватъ исключительно для предотвращения распространения таких проблем по сети.
Пользователи должны принимать участие в этой программе и никакими действиями не препятствовать ее проведению.
На консультации у юриста...
В старой шутке говорится, что если вы пригласите двух юристов, то будете иметь три разных мнения, и ни одно из них не будет правильным, когда речь идет о юридических правах и информационной безопасности. Несмотря на то, что автор склоняется к тому, что юристам можно позволить накладывать запрет на отдельные технические решения при разработке правил информационной безопасности, не следует бояться задавать вопросы по поводу их правовых решений по отдельным пунктам.
Один юрист говорил, что наибольшие ошибки юристы совершают при подаче сомнительных исков. Например, если формулировка правил может быть воспринята как касающаяся кадровых вопросов, они полагают, что любые проблемы возможно разрешить на основе трудового законодательства.
Не в каждой организации хотят иметь в правилах формулировку, похожую на статью уголовного кодекса. Если предположить, что в организации будет установлено антивирусное программное обеспечение на всех системах вместо того, чтобы использовать сетевые фильтры, то желательно включить в правила формулировку подобную следующей.
На всех пользовательских системах еще до того, как они будут подключены к сети, следует установить программное обеспечение для защиты от вирусов. Пользователи должны содействовать обновлению этого программного обеспечения, а также не должны отключать эти средства. Если антивирусное программное обеспечение по каким-то причинам отключено, например, по причине установки нового программного обеспечения, то пользователю необходимо провести полное сканирование системы перед ее использованием.
Определение типа защиты от вирусов
Существует более дюжины компаний, предлагающих различные решения защиты сети от вирусов, "червей" и "троянских коней". Эти решения предполагают установку защиты на каждом канале поступления информации, в каждой системе или комбинацию этих решений. Существуют и другие решения, когда вложение и сегменты перемещаемых программ переносятся в другую систему, в которой данное вложение будет запущено на выполнение. Это дает гарантию, что если возникнут проблемы, то не на основной сети.
Перемещаемые программы
Новая запись, появившаяся в перечне вопросов к руководству, названному "Часто задаваемые вопросы" (Frequently Asked Questions), — "Что такое перемещаемая программа?". Концепция перемещаемых программ появилась, когда компания Sun разработала язык Java и операционную среду для него. Она заключается в написании одной единственной программы, которая будет работать, где угодно. Путем создания перемещаемых программ, которые загружаются с сетевого сервера, такого как Web-сервер, решена задача, когда одна программа может быть отправлена на любую систему и будет в ней работать.
В настоящее время самое распространенное использование перемещаемых программ в Internet для повышения технического уровня пользователя при работе с Web-узлом. Но принцип перемещаемых программ можно использовать для доставки любых типов приложений, в том числе вирусов и другой гадости.
Тонкость формулировки правила защиты от вирусов заключается в том, чтобы разработать правило, которое не обязывает организацию эксплуатировать какой-то определенный антивирусный пакет программ, поскольку может возникнуть желание сменить его. В большинстве организаций устанавливают антивирусный пакет программ на каждой отдельной системе и запускают его всякий раз, когда пользователь регистрируется в сети. В других организациях используют сетевое оборудование для сканирования трафика, проходящего через определенные контрольные точки. И, наконец, существуют системы, которые сканируют электронную почту и тестируют вложения в отдельной контрольной системе.
Независимо от используемой системы в правилах следует разъяснять, как обрабатывать зараженные вирусами программы. Например, если в организации используется система, которая сканирует вложения электронной почты отдельно от остальных входящих потоков, то это должно быть оговорено в правилах. Это необходимо сделать, поскольку при допросе в суде обязательно нужно будет открыть наличие в организации сканирования, чтобы избежать других обвинений.
В правилах встречаются три типа формулировок, которые определяют полную программу защиты от вирусов. В первой формулировке устанавливается тип необходимого антивирусного мониторинга и тестирования. Затем необходима формулировка проверки целостности системы, которая поможет организации подтвердить работоспособность программы. И, наконец, необходимо рассмотреть правила проверки на вирусы для распределенных или съемных носителей (например, гибких дисков, архивов на ленте и т.п.).
Правила эксплуатации стороннего программного обеспечения
Интересный побочный эффект предыдущей формулировки правил заключается в том, что она подразумевает сканирование дисков с инсталляционными программами. Несмотря на то, что это происходит редко, бывают случаи, когда поставщики теряют бдительность и распространяют зараженные вирусом программы. Большинство администраторов безопасности согласны с тем, что сканирование дистрибутивных дисков является хорошей мерой предосторожности.
Многие поставщики дают гарантию, что носители, которые они распространяют, не содержат вирусы. Они не хотят иметь лишних проблем и нести ответственность за инфицирование систем клиентов из-за их программного обеспечения. Некоторые поставщики афишируют, что их мастер-копия просканирована перед дублированием с помощью специального программного обеспечения для сканирования вирусов.
Программное обеспечение поставщиков является не единственным поводом для беспокойства. Организации могут получать данные из множества различных источников, которые могут содержать вирусы или создавать другие проблемы. Существуют демонстрационные версии программ и бесплатно распространяемые программные средства, которые люди загружают регулярно и необязательно с надежных серверов. Независимо от источника получения программного обеспечения в организации должно быть правило, которое предписывает определенные меры предосторожности при загрузке сторонних данных.
По причине того, что эти данные могут загружаться с внешних источников, включая Internet, некоторые считают, что последняя формулировка правил должна касаться обработки сторонней информации после ее загрузки. Альтернативой являются правила, которые предписывают загружать стороннюю информацию перед ее использованием в испытательную тестовую систему для проверки. Организации, которые используют этот тип правил, могут подкрепить правило загрузки внешних данных такой формулировкой.
Сторонние данные и программы должны загружаться в систему, на которой можно проводить опробование и тестирование на наличие вирусов, ошибок или других проблем перед загрузкой этих данных на другие системы в сети организации.
Привлечение пользователей к защите от вирусов
Беспокоят не только атаки с помощью вирусов, но если кто-нибудь из организации хранит вирусы, тогда проблемы будут гораздо серьезней. Организации не хотят, чтобы их считали распространителями вирусов. Многие предпочитают вводить очень жесткую формулировку правил, касающуюся вирусов. Некоторые даже хотят, чтобы в формулировку были включены возможные наказания за нарушение этих правил. Ниже следует жесткая формулировка, которая была использована для одной из таких организации.
Пользователи не должны преднамеренно создавать, запускать на выполнение, передавать или демонстрировать никаких компьютерных кодов, разработанных для самовоспроизведения, нанесения ущерба или для создания других проблем с любой памятью компьютеров, запоминающими устройствами, операционной системой и любым программным обеспечением. Пользователи, нарушающие данные правила, могут быть наказаны в дисциплинарном порядке или уволены, а дело будет передаваться в соответствующие юридические органы.
Автор слышал, что слабое место этих правил заключается в том, что пользователи могут трактовать эти правила двояко. Однако, юристы, с которыми работал автор, считают, что такая формулировка дает организации достаточную свободу для наказания пользователей, использующих системы организации и сети для распространения вирусов.
Проверка целостности системы
Проверка целостности системы может проходить во многих формах. Наиболее распространенные антивирусные пакеты могут хранить перечень файлов базовой системы и сканировать эти файлы каждый раз при загрузке системы для выявления возможных проблем. В других системах существуют средства, которые следят за общей конфигурацией системы, а также проверяют целостность файлов, файловых систем и двоичных кодов в общих областях памяти. Наличие регулярно выполняемых проверок такого типа является еще одной превентивной мерой защиты в программе безопасности. Если организация проводит такие меры, то можно составить следующую формулировку правил.
Все системы, подключенные к сети организации, должны подвергаться периодической общей проверке, чтобы выявлять зараженные вирусами операционные системы и вспомогательное программное обеспечение. Период между проверками не должен превышать одного месяца (30 дней).
Распределенные и съемные носители
Другой сложной областью при разработке правил можно считать защиту не часто используемых устройств или съемных носителей. Свойства и тех, и других меняются, поскольку кто-нибудь может снять диск, ленту или любой носитель, на котором хранятся данные, и установить их на другую систему. Пользователь также может переносить вирусы с одной системы на другую.
Трудность разработки правил заключается в том, что различные системы выдвигают различные требования к съемным носителям. Например, система на основе UNIX имеет не такие требования к сканированию, как система на базе Windows. Однако, мы не можем быть уверены в том, что компакт-диск, записанный в системе UNIX не инфицирует систему Windows.
Один из способов решения этих проблем заключается в введении правил, которые требуют сканировать носители в специальной системе. Формулировка политики может быть следующей.
Пользователи, загружающие какие-либо данные или программы с внешнего носителя, должны перед загрузкой сканировать этот носитель на предмет наличия на нем вирусов.
и компьютеры, не только обходятся
Вирусы, "черви" и "троянские кони", которые инфицируют сети и компьютеры, не только обходятся организациям "в копеечку", но и снижают объем производства, который может в дальнейшем и не быть компенсирован. Правила защиты от вирусов могут устанавливать требование для всех пользователей защищать ценные данные организации.
- подход к тестированию на вирусы;
- проверка целостности системы;
- проверка распределенных или автономных средств.
- 3. Правила эксплуатации стороннего программного обеспечения.
- Несмотря на то, что это происходит довольно редко, все же бывают случаи, когда поставщики теряют бдительность и распространяют зараженные вирусом свои программы. Можно разработать правила, предписывающие особый режим эксплуатации стороннего программного обеспечения.
- В правилах может быть предписано, чтобы стороннее программное обеспечение перед загрузкой их на другие системы устанавливалось на испытательную систему и проверялось.
- 4. Привлечение пользователей к защите от вирусов.
- Организация не хочет, чтобы ее пользователи имели какое-то отношение к вирусам. Это может плохо повлиять на выполнение задач организации. Данные правила должны жестко требовать, чтобы пользователь не имел никакого отношения к вирусам.
- Чтобы сделать формулировку правил более жесткой, в некоторых организациях добавляют в нее положение о дисциплинарных взысканиях, включающих увольнение и передачу дел правоохранительным органам.
Тестирование на вирусы
Предположим, что в организации приняли решение использовать распределенный подход для защиты от вирусов. (Размеры организации значения не имеют.) В качестве этапа выполнения программы закупается популярный антивирусный пакет, который будет установлен в каждой системе. Администраторы установят и сконфигурируют программное обеспечение, в котором будут программы, выполняющие непрерывное сканирование вирусов и обновляющие еженедельно с помощью предлагаемых поставщиком общедоступных услуг базу данных сигнатур вирусов. Формулировка правил может выглядеть следующим образом.
Антивирусное программное обеспечение должно устанавливаться и конфигурироваться во всех сетевых системах организации таким образом, чтобы гарантировать постоянное сканирование на предмет поиска вирусов, а также периодически обновляться по указанию администраторов.
Вирусы, "черви" и "троянские кони"
Не проходит и недели без слухов о новых вирусах, "червях" и "троянских конях", которые инфицировали сети или компьютеры. Решение этих проблем не только требует немалых денежных затрат, но и чревато снижением объема производства, который может в дальнейшем и не быть компенсирован. Несмотря на то, что эти проблемы в первую очередь влияют на определенный тип операционной системы и программное обеспечение определенного поставщика, не существует операционных систем, которые давали бы полную гарантию защищенности от вирусов. Следует помнить, что первый известный "червь" был запущен в 1988 году и предназначался для атаки систем Digital VAX и Sun System, работавших под управлением одной из версий UNIX.
При разработке правил безопасности в первую очередь необходимо определить цель такой защиты. Некоторые могут подумать, что это не обязательно, но только так можно определить требования, предъявляемые к разрабатываемым правилам, а также сделать их более эффективными. После этого в правилах, прежде чем обсуждать роль пользователей в реализации правил, необходимо определить, каким образом организация обеспечит защиту от вирусов (централизованно или локально), а также в правила следует включить руководства по эксплуатации заимствованного программного обеспечения.
Шифрование
Хранение ключей
Определенные аспекты хранения ключей контролировать невозможно. Аппаратные средства шифрования обладают ресурсами памяти, необходимыми для их надлежащей работы. Программное обеспечение должно иметь ресурсы онлайновой памяти, включая те, что имеются в оперативной памяти. В сферу правил, регламентирующих хранение ключей, входит создание резервных копий и другие возможности хранения ключей.
Правила хранения ключей могут предписывать, каким образом хранить ключи, как делать резервные копии или обеспечивать их пересылку. Но особенно важно рассмотреть случай хранения ключей на том же устройстве или носителе, где хранятся защищенные данные. В одной из дискуссий кто-то подметил, что хранить ключи на том же диске, где находятся защищенные данные, все равно, что оставлять ключ от дома под ковриком перед дверью. Формулировка правил очень простая.
Ключи не должны храниться на том же диске, где находятся защищенные данные.
Что касается правил, касающихся иных аспектов хранения ключей, таких как уничтожение ключей на носителе, то в большинстве организаций предпочитают не включать эти требования в правила, а включать их в процедуры.
Эксплуатация криптографических систем и обработка зашифрованных данных
Помимо всех соображений, которые необходимо учесть при использовании криптографии, существует тенденция разработки отдельных правил, касающихся работы с зашифрованными данными. Однако, существует один аргумент, о котором нельзя забывать: предполагается, что правила являются инструкциями, а все специфические вопросы должны быть включены в рабочие процедуры.
Правила, определяющие, когда шифровать данные, лучше включить в процедуры. Целью разработки правил, регламентирующих работу в области криптографии, является предоставление некоторых инструкций для разработки этих процедур. В одной из организаций, с которой сотрудничал автор книги, в ходе изучения данной проблемы было принято решение, что данные следует классифицировать на основе требований к их хранению или пересылке. После продолжительной дискуссии было принято решение, что вместо такой классификации в правилах будет лучше использовать классификацию данных по принципу: если они не используются, то лучше их удалить. Формулировка правил следующая.
Все данные должны классифииироваться согласно их применению. Критериями должны служить соображения конфиденциальности данных, место их размещения и способ пересылки.
Во время этих обсуждений кто-то принес секретные архивные данные. Автор книги услышал, что в этой организации архивные данные конвертировали с магнитных лент на оптические носители. Руководители стали интересоваться, не нужно ли зашифровать эти данные. Обсуждая настоящую концепцию, мы пришли к выводу, что может возникнуть проблема с управлением ключами и восстановлением ключей для каждой копии носителя. Проблема оказалась настолько непростой, что руководство приняло решение ужесточить правила хранения резервных копий носителя и включить в правила такую формулировку.
Архивные и резервные данные не должны шифроваться. Секретные данные должны храниться в соответствии с предписаниями правил.
И, наконец, нужно обсудить вопрос, как работать с зашифрованными данными. Прежде всего, если данные зашифрованы, необходимо обеспечить гарантии того, что их нельзя будет извлечь из системы. Во многих организациях начинают беспокоиться по поводу своих старых лент и оперативных данных, желая также их зашифровать. В ходе обсуждений появилась следующая формулировка правил.
После шифрования данных все исходные данные нужно удалитъ или необходимо уничтожить носители, на которых они записаны. Оперативная и внешняя память, используемые в процессе шифрования, также должны быть тщательно вытерты 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 облегчает решительному взломщику возможность считать эти данные. Единственный способ предотвратить вторжение такого типа заключается в использовании шифрования. Шифрование представляет собой особую технологию, и правительства предпочитают, чтобы рядовые граждане не пользовались ею, поскольку шифрование делает сложным прослушивание пересылаемых вами данных. Все это требует особых соображений во время разработки правил информационной безопасности организации.
Шифрование
Пересылка данных через 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.
Все соглашения о сторонних разработках должны включать постановление о размещении копий исходника и исполняемых программ на хранение у третьей стороны. Эти постановления должны разрешать доступ организации к копии, если сторонний разработчик не может больше сопровождать это программное обеспечение.
Правила, гарантирующие целостность программного обеспечения
Когда организация для разработки программного обеспечения прибегает к сторонней помощи, необходимо позаботиться о целостности такого программного обеспечения. Как организация может удостовериться, что это программное обеспечение не содержит незадокументированных функций, нелегальных входов или иных механизмов, способных подорвать безопасность? Правила в данной области подобны правилам разработки программного обеспечения. Разница в том, что эти правила касаются сторонних организаций и соглашений, определяющих взаимоотношения с ними. Формулировка правил, может быть следующей.
Все соглашения со сторонними разработчиками программного обеспечения должны включать требования обеспечения целостности. В эту формулировку необходимо включитъ такие требования, чтобы в разработанном программном обеспечении не было никаких незадокументированных функций, нелегальных входов, "лазеек" или других механизмов, нарушающих безопасность.
Формулировку о целостности можно дополнить, особенно, если разработанное программное обеспечение будет работать в системах организации и сети. В дополнение к обеспечению того, что программное обеспечение функционирует так, как было определено в техническом задании, необходимо, чтобы оно могло работать со средствами управления безопасностью операционной среды, в которой установлено. Если работа программного обеспечения не будет согласована с установленными инструкциями и алгоритмами, то она может свести на нет требования правил безопасности. Поэтому, для расширения правила обеспечения целостности можно добавить следующую формулировку.
Все программное обеспечение, разработанное сторонними организациями, должно соответствовать установленным стандартам информационной безопасности. Это программное обеспечение должно согласовываться со средствами управления операционной системы или средствами управления программным обеспечением.
Правила разработки программного обеспечения
Разработка программного обеспечения представляет собой искусство компилирования закодированных инструкций таким образом, чтобы преобразовать их в понятную программу для запуска на компьютере. Подобно иным видам искусства, базирующимся на научных теориях, ошибки и другие упущения могут привести к катастрофическим результатам. С развитием Internet недоработки в программном обеспечении, обеспечивающем функционирование Web-страниц, пересылку электронной почты или доступ к другим серверам, делают системы уязвимыми для атак извне.
В методиках разработки программ обеспечение безопасности редко рассматривается в качестве этапа разработки. Довольно часто обеспечением безопасности начинают заниматься уже после разработки, что приводит к необходимости применения экстраординарных мер. Включив в правила безопасности организации положения о разработке программного обеспечения, можно избежать последующей доработки программного обеспечения собственными силами, вызванной необходимостью обеспечить безопасность программного обеспечения и систем. В данной главе обсуждается процесс разработки программного обеспечения, а также его влияние на безопасность организации. Этот процесс включает в себя собственно разработку, тестирование и конфигурирование системы. Даже если организация не занимается разработкой собственного программного обеспечения, некоторые аспекты этих правил, такие как управление конфигурированием системы и разработка сторонними специалистами, могут оказаться довольно полезными.
Область действия правил разработки программного обеспечения
При написании этой книги, предназначенной для широкого круга пользователей, было довольно сложно описывать специфические проблемы, с которыми сталкиваются различные по величине организации. Вместо того, чтобы рассматривать все возможные варианты, в данной главе обсуждается разработка правил для организаций, в которых есть собственная группа разработчиков программного обеспечения. Численность этой группы не имеет особого значения, и автор предоставляет читателю возможность самому вносить соответствующие корректировки к предложенным здесь рекомендациям, чтобы они отвечали конкретным условиям.
Процедуры инсталляции
Независимо от того, насколько часто тестируется программное обеспечение, может возникнуть необходимость выгрузить из работающей системы установленное ранее программное обеспечение или патчи. По этой причине в правила управления конфигурацией необходимо включить требование как по инсталляции, так и по выгрузке программного обеспечения. Формулировка может быть следующей.
В процедуры управления конфигурацией необходимо включитъ процедуры инсталляции и "отката" к предыдущей версии в случае возникновения проблем.
Процедуры запросов на замену версий
Одним из ключевых моментов, отражающихся на безопасности, при замене версий и управлении конфигурацией, является возможность отслеживать изменения. В случае возникновения проблем администраторы, чтобы установить вызвавшую их причину, могут обследовать программное обеспечение системы и другие установленные программные модули. Первым шагом для обеспечения трассировки системы должна стать разработка правила, официально разрешающего изменение процедур управления для всех систем, находящихся в эксплуатации. В этом правиле предусматривается, что запросы на выполнение изменений в системе, а при необходимости и пересмотра правил безопасности, должны подаваться в письменном виде.
Для замены версий и управления конфигурацией должно быть официально разрешено изменение процедур управления для всех систем, находящихся в эксплуатации. Эти процедуры включают в себя подачу письменных запросов на внесение изменений, сопровождение исходных модулей разработанного и сданного в эксплуатацию программного обеспечения, а также проверку средств управления безопасностью.
В правилах не отражены ни конкретные методы выполнения этих работ, ни программное обеспечение, которое может быть использовано в работе. Еще раз напомним, что это относится к деталям реализации.
Рекомендации по разработке аутентификации
Большое количество программного обеспечения предназначено для поддержки производственных функций, доступ к которым должен быть предоставлен только определенным пользователям. Несмотря на то, что такие требования не всегда выдвигаются, большая часть разрабатываемого программного обеспечения должна удовлетворять требованиям идентификации пользователей и установки полномочий пользователей по отношению к этим функциям. Идентификация и авторизация (Identification and Authorization — I&A) являются основными средствами защиты прямого доступа к программе. Это очень важно, поэтому во многих организациях рассматривают возможность включить в правила безопасности дополнительные положения, подкрепляющие правила разработки программного обеспечения, чтобы гарантировать, что I&A будет обязательно включено в разработку.
Один руководитель проекта подметил, что, когда он пришел в организацию, во многих проектах, которые разрабатывались в организации, использовалось несколько различных алгоритмов для обеспечения функций I&A. Некоторые из них даже были несовместимы с операционной системой, базой данных или другими алгоритмами, которые использовались в программном обеспечении большинства систем. Исправить такое положение можно, если постараться использовать единый алгоритм, встроенный в систему или базу данных. Помимо того, что становится проще управлять разработкой, в этом алгоритме используются постоянно доступные и продуманные алгоритмы защиты, которые служат для защиты как собственных разработок, так и системы или базы данных. Этот руководитель предложил следующую формулировку правил.
При проектировании и развертывании программного обеспечения собственной разработки в нем должны применяться идентификация и авторизация, которые базируются на встроенных в операционную систему, базу данных или в системы сервисного программного обеспечения алгоритмах.
Другие правила, затрагивающие процесс разработки I&A, сфокусированы на обработке информации, которую содержат пароли. Несмотря на то, что некоторые из этих правил декларируют подходы к разработке I&A, основанные исключительно на здравом смысле, многие уже поняли, что правила могут быть забыты, хотя они являются частью процесса разработки. Поэтому, возможно, будет лучше включить требования к паролям в правила безопасности. В некоторые правила может быть включены следующие формулировки.
Пароли не должны пересылаться электронной почтой в незашифрованном виде.
Пароли, не должны пересылаться открытым текстом по сети в незашифрованном виде.
Пароли нельзя хранить в открытом виде на доступных запоминающих устройствах.
Пароли никогда не должны быть константой, хранящейся внутри программы (жестко закодированной).
Память, используемая для дешифрования и проверки паролей, должна очищаться nocлe завершения работы.
Разработка программного обеспечения представляет собой
Разработка программного обеспечения представляет собой искусство компилирования закодированных инструкций таким образом, чтобы преобразовать их в понятную программу для запуска ее на компьютере. Подобно другим видам искусства, основанным на научных теориях, ошибки и упущения могут привести к катастрофическим результатам. Довольно часто обеспечением безопасности начинают заниматься уже после разработки, что приводит к необходимости применения экстраординарных мер. Включив в правила безопасности организации положения о разработке программного обеспечения, можно избежать последующей доработки программного обеспечения собственными силами, вызванной необходимостью обеспечить безопасность программного обеспечения и систем. Даже если организация не занимается разработкой собственного программного обеспечения, некоторые положения этих правил могут оказаться довольно полезными.
"откату" к предыдущей версии.
Сторонняя разработка
Некоторые организации не обладают достаточным опытом, необходимым для разработки собственного программного обеспечения. В последнее время стало обычным делом заказывать другим компаниям разработку 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 входит программа инструктажа, то в документ AUP нужно добавить простую формулировку, подобную следующей.
Обязанности пользователей при регистрации в системе
Начав разработку AUP с приверженности их законам и перечисления компонентов, составляющих эти правила, имеет смысл теперь обсудить что-нибудь попроще, вроде обязанностей пользователей при регистрации в системе. Этот раздел представляет собой краткое изложение правил аутентификации (см. главу 5 "Аутентификация и безопасность сети"). Здесь представлены правила, которые должны знать пользователи, даже если они и не читали все документы, составляющие правила безопасности.
Простейший способ выбрать все важное заключается в составлении списка коротких формулировок для включения их в документ AUP.
блокировку.
Ответственность организации и предоставление информации
Пользователи являются не единственными лицами, которые имеют обязанности перед организацией, описанные в правилах информационной безопасности. Организация тоже обязана информировать пользователей о том, какие требования предъявляются к ним правилами и какие они должны выполнять функции, а также какие санкции возможны со стороны руководства организации. Помимо этих обязательств организации, она еще имеет правовые обязательства информировать о том, какие шаги она предпринимает, включая наблюдение и сбор данных, проходящих через сеть. При отсутствии таких требований судебные органы не будут принимать во внимание собранные данные о нарушениях пользователями правил безопасности.
Иногда эти правила довольно сложно внести в документ AUP. Были сообщения о том, что пользователи отрицательно относятся к предписаниям правил. Это приводит к конфликту между руководством и теми, кто непосредственно руководствуется в работе этими правилами, что ухудшает моральный климат в организации. Поэтому, необходимо составить формулировки правил, в которых полностью оговаривается, какие санкции может предпринимать организация, исходя из требований правил, и гарантировать, что ее действия не будут нарушать этику.
Правила надежной работы
Тем читателям, КТО СЛЕДУЕТ УКАЗАНИЯМ настоящей книги, необходимо еще провести большую работу, чтобы завершить разработку правил информационной безопасности. Закончив эту массу работы, следует обратить свое внимание на итоговую версию документа, называемую Правилами надежной работы (Acceptable Use Policy — AUP).
AUP является документом, в котором собраны все необходимые пользователям правила. В AUP собраны фрагменты правил организации, отражающие обязанности пользователей в области обеспечения безопасности. В основном, в этих фрагментах резюмируются отдельные мысли правил, и написаны они простым языком. Хороший документ AUP должен быть кратким и точным. В идеале, AUP должен занимать всего лишь несколько страниц.
Обычно, AUP представляет собой подписанный документ, который является обязательством подчиняться правилам безопасности, на базе которых он составлен. Его можно выдавать вновь принятым на работу сотрудникам, подрядчикам или поставщикам, которым предоставляется доступ к сети, чтобы обеспечить гарантии того, что они будут знать свои обязанности. Цель создания документа - привлечь внимание к документам, составляющим политику организации, не требуя от пользователей читать их все. В документе AUP должно говориться, что пользователь обязан подчиняться правилам, но AUP можно рассматривать как "документ ускоренного начала работы", чтобы разрешить пользователям прочитать полный комплект документов позже.
Образец AUP
Хоть в эту главу включены некоторые образцы формулировок, в Приложении В "Примеры правил" представлен также полный пример AUP.
Работа с системами и в сети
Теперь, когда пользователь может зарегистрироваться в системе или сети, он должен знать, что можно, а что нельзя делать в сети. В этом разделе мы повторяем многие правила безопасности, касающиеся ежедневной работы. Это обычные правила поведения, нашедшие отражение в правилах безопасности. Сюда можно включить следующие правила.
Разработка AUP
Несмотря на то, что AUP представляет собой весьма важный документ, он должен быть кратким и исчерпывающим. Одна из проблем, с которой можно столкнуться при разработке AUP, заключается в том, что в нем необходимо учесть различные аспекты деятельности различных организаций. Отдел кадров организации захочет получить гарантии, что в документе описаны правила найма на работу и положения трудового законодательства, которыми он тоже должен руководствоваться. Кроме того, тем, кому приходится сотрудничать с подрядчиками и поставщиками, необходимо будет включить документы AUP и правил в контракты с этими сторонними организациями.
Хоть AUP читается легко, многие находят, что разрабатывать этот документ очень сложно. В одной организации стол переговоров превратился чуть ли не в поле битвы, когда руководство, отдел кадров, управление работы с подрядчиками и юристы попытались утвердить AUP. Чтобы достигнуть консенсуса, им пришлось провести три заседания и обменяться массой сообщений по электронной почте.
Язык документа AUP
На протяжении этой книги автор использовал очень формализованный язык для примеров формулировок правил (см. "Язык документов политики безопасности" в главе 4 "Физическая безопасность"). При разработке AUP можно использовать тот же язык, который использовался при разработке документов правил безопасности организации. Поскольку AUP обычно является первым документом, с которым знакомятся, попав в организацию, автор постарался использовать в AUP понятный и достаточно информативный языковой стиль.
При выборе языкового стиля необходимо проявлять осторожность. В противном случае смысл документа может быть искажен. Если язык слишком неофициальный или не лаконичный, то AUP могут не воспринимать всерьез. Если же язык будет слишком официальным, то пользователи могут не воспринимать всерьез сами правила. Поэтому, необходимо найти золотую середину.
Документ AUP должен быть простым и четко оформленным. Когда автор помогал организациям разрабатывать документы AUP, то старался строить документ следующим образом.
Эти правила надежной работы разработаны на базе правил информационной безопасности организации. Копии документов правил информационной безопасности можно получить у заместителя начальника каждого отдела или в электронном виде во внутренней сети организации.
Эти правила могут меняться. Организация может принять решение об изменении правил без предварительного уведомления. После внесения изменений пользователи будут информированы об этом посредством электронной почты.
Пользователь согласен подчиняться предписаниям правил надежной работы и правил информационной безопасномти, начиная с даты подписания им этих правил и до тех пор, пока он будет работать в организации.
в котором описаны все правила,
Правила надежной работы (AUP) представляют собой документ, в котором описаны все правила, касающиеся пользователей. В AUP собраны фрагменты правил организации, отражающие обязанности пользователей в области обеспечения безопасности. В основном, в этих фрагментах резюмируются отдельные мысли правил, и написаны они простым языком. Документ AUP должен быть кратким, чтобы его можно было использовать в качестве обязательства подчиняться правилам информационной безопасности. Его можно выдавать вновь принятым на работу сотрудникам, подрядчикам или поставщикам, которым предоставляется доступ к сети, чтобы обеспечить гарантии того, что они будут знать свои обязанности.
Сбор конфиденциальных данных
Если организация контролирует данные, то желательно, чтобы некоторые из этих данных были собраны. Даже если организация не проводит активного наблюдения за сетью, существуют другие посторонние источники информации, с помощью которых организация также может собирать записи. Независимо от того, занимается ли организация в настоящее время сбором информации, она должны уведомить, какие данные она собирает, описать методы сбора и способы хранения.
Для некоторых организаций это представляет собой довольно сложный вопрос, поскольку его нужно внести в AUP в качестве дополнения к правилам управления персоналом. Возникает впечатление, что в документе AUP не уделяется внимание кадровым вопросам, что может вызвать негативную реакцию. Лучше всего посоветоваться с отделом кадров для определения того, что нужно внести в документ AUP, а что оставить на усмотрение отдела кадров. В любом случае есть несколько вопросов, которые необходимо рассмотреть в формулировках правил. Ниже следует далеко не полный перечень этих вопросов.
Согласование и внедрение
Аудит и сбор данных
За определенное время администраторы могут собрать много данных. Независимо от того, выбираются эти данные из системных журналов или являются копией системного или сетевого трафика, их можно использовать для проверки эффективности применения правил. В качестве одного из этапов периодического аудита, проводимого для оценки эффективности применения правил, эти данные могут оказаться полезными при изучении проблем, вызванных применением правил или выявленных в результате применения правил.
Автор обнаружил, что эти данные полезны для того, чтобы лучше понять, как работает организация, и полезны для совершенствования правил. Дополнительно к этому, они также могут предоставить информацию о загрузке сети, а это может помочь организации провести изменения для повышения эффективности работы сети. Поэтому, в правила аудита необходимо также включить требование по сохранению информации для последующего изучения. Формулировка правил может быть довольно проста.
Данные, необходимые для обработки информации о нарушениях информационной безопасности и об инцидентах, должны сохраняться, чтобы их можно было использовать во время анализа правил информационной безопасности на эффективность применения.
Меры наказания
К каждому правилу и закону прилагаются инструкции по назначению наказаний и взысканий. В правила информационной безопасности необходимо также включить формулировку, касающуюся мер наказания. Одна из причин сделать это заключается в том, чтобы в случае нарушения безопасности, не возникало вопросов, имеет ли организация право применять меры наказания. Поскольку нарушения могут совершаться и внутри организации, и сторонними взломщиками, в правилах должны быть учтены оба варианта.
Исходя из юридического опыта автора, разработка такого правила начинается с общей формулировки, в которой говорится, что пользователю запрещено наносить вред системам, сетям и т.п. Формулировка может быть составлена таким образом, чтобы охватить основные постановления по правоприменению всех имеющихся правил. Она может выглядеть следующим образом.
Категорически запрещено любое поведение, которое неблагоприятно отражается на работе других лиц в системах и сетях компании или которое может навредить другим лицам.
Далее, устанавливаются правила применения мер наказания по отношению к пользователям, которые нарушают правила. Автор предпочитает использовать две формулировки. Одна формулировка правил адресована ко всем пользователям. Ее предлагается использовать при применении мер наказания по отношению к внутренним пользователям, например, собственным служащим. Другая формулировка похожа на первую, но предназначена для внешних пользователей или подрядчиков, которые пользуются сетью на основе особого разрешения. В этой формулировке нужно показать причину, по которой они допущены к пользованию сетями и системами, например, ссылку на контракты или договоры, на основе которых им предоставлен доступ. Ниже представлен пример таких формулировок.
Руководство имеет право аннулировать любые привилегии доступа пользователей и в любой момент разорвать с ними трудовое соглашение за нарушения предписаний правил безопасности или за поведение, мешающее нормальной работе сети и компьютерных систем организации.
Руководство имеет право разорвать контракты и договоры с подрядчиками и другими внешними пользователями, если они нарушают предписания правил или демонстрируют поведение, которое мешает нормальной работе сети и компьютерных систем организации.
И, наконец, правила должны охватывать незаконную деятельность, осуществляемую внутренними пользователями и внешними взломщиками. Можно записать в правила отдельную формулировку, которая отражает реакцию организации на все виды незаконной деятельности. Для этой формулировки нет краткой формы. В ней должно быть сказано, что в соответствии с местными законами ожидает тех, кто нарушает законы.
Клиент, который хотел по собственному усмотрению привлекать правоохранительные органы и систему закона, вместо того, чтобы делать это в обязательном порядке, опирался на приведенную ниже формулировку правил. Руководство понимало, что в некоторых случаях увольнение служащего является достаточным наказанием. Поскольку об увольнении было сказано в предыдущей формулировке правил, мы разработали такую формулировку.
Руководство имеет право применить собственные меры наказания вместо соответствующих санкций по криминальному или гражданскому законодательству против любого, кто использует, злоупотребляет или атакует сеть организации и информационные системы таким образом, что это может быть отнесено к нарушениям закона и предписаний этих правил.
Мониторинг, средства управления и меры наказания
Наиболее дискуссионная тема правил информационной безопасности касается мониторинга, средств управления и меры наказания при нарушениях. Дебаты возникают из-за некоторых правил мониторинга и управления, которые могут быть использованы при правовой защите информационной безопасности организации. Признавая их законными, некоторые адвокаты видят в этих методах нарушение прав неприкосновенности частной жизни. Работая со многими организациями, автор советовал соблюдать осторожность и разработать правила, которые помогут в работе, а не вызовут недоверие или негативную реакцию.
Проблема заключается в том, что статистика показывает наибольшее количество нарушений безопасности именно внутри организации, в то время как основное внимание уделяется защите от внешних действий. Благодаря тому, что об этом много говорят, во многие правила включены постановления, касающиеся применения санкций к посторонним нарушителям. Необходимо изучить внешнюю угрозу и рассмотреть внутреннюю опасность. Даже если организация не хочет, чтобы правила выглядели как набор предписаний для создания полицейского государства, все равно необходимо обеспечить возможность контроля исполнения правил и возможность принудительного их применения.
Мониторинг
Первый шаг по созданию правил мониторинга заключается в определении прав организации на наблюдение. Несмотря на то, что эти правила могут быть направлены на утверждение прав руководства на мониторинг, в их предписаниях может быть сказано, что руководство имеет право назначить кого-либо для осуществления мониторинга. В конце концов можно посадить несколько исполнителей из отдела информационных технологий перед мониторами для наблюдения за сетевым трафиком. Правила могут выглядеть следующим образом.
Руководство имеет право наблюдать за всей деятельностью в системе и за сетевым трафиком для проведения в жизнь постановлений правил безопасности. Руководство имеет право возложить обязанности по мониторингу и другие обязанности на отдельных администраторов.
Обязанности администраторов
В предыдущем разделе этой главы были описаны, в основном, обязанности руководства по внедрению правил безопасности. Руководство может назначить администраторов для мониторинга и проверки соответствия, но об их обязанностях не было ничего сказано, так как это отнесли к деталям реализации. В правилах для администраторов необходимо указать те вопросы, за которые отвечает администратор.
Некоторые правила предназначены не только для системных администраторов или администраторов безопасности. В правилах администрирования могут быть также отражены административные обязанности, которые являются обязанностями лиц, ответственных за данные или за технологию, а также - обязанности пользователей. Эти правила охватывают вопросы административного согласования и внедрения, которые не входят в сферу административного управления.
В зависимости от полноты и широты охвата ваших правил количество вопросов, которые должны быть в них учтены, может показаться несметным. Прежде чем приступать к разработке правил, необходимо продумать, что именно должно входить в правила администрирования. Ниже представлен краткий список предлагаемых вопросов.
В правиле, которое имеет смысл обсудить особо, рассматривается, какие действия следует предпринять, когда служащий или подрядчик разрывает трудовое соглашение с организацией. Независимо от того, является это добровольным уходом или нет, администраторы должны разработать процедуры аннулирования права доступа к ресурсам организации. Поддерживая актуальность идентификационной базы пользователей, можно уберечь сеть от возможных атак.
Процедуры по работе с уволенными пользователями не должны входить в эти правила. Однако, предписаниями правил могут устанавливаться обязанности по решению вопросов в отношении уволенных пользователей. Некоторые из этих вопросов касаются назначения лиц, которые несут ответственность за своевременное аннулирование права доступа, освобождение ресурсов, выделенных этому пользователю, выявление в пользовательских ресурсах нарушений безопасности и других ошибок, а также за архивное хранение пользовательских файлов и других данных. Упрощенная формулировка, в которой говорится об аннулировании и архивном хранении, может выглядеть следующим образом.
Права доступа к ресурсам организации пользователей, которые разорвали трудовые отношения с организацией, должны быть немедленно аннулированы. Администраторы должны привести в порядок программы и другие данные, с которыми работали эти пользователи. Администраторы должны разработать процедуры аннулирования прав доступа этих пользователей.
Отчетность о нарушениях безопасности
Подчинение этим правилам должно стать обязанностью каждого, а не только администраторов. В вышеописанные правила включены указания пользователям содействовать внедрению этих правил, но ни в одном из правил не отражается в полной мере значение документирования случаев нарушения безопасности. Разработка правил составления отчетности о нарушениях безопасности очень похож на разработку всех других правил, описанных в этой главе, — они в высшей степени зависят от конфигурации окружения и правовых требований к внедрению этих правил.
Публикация документов правил и требования по уведомлению
Разработанные правила не улучшат работу организации, если их поставят пылиться на полке. Этот документ должен быть не только действующим, но и доступным для всех пользователей. Общепринятый способ сделать это заключается в публикации документов правил во внутренней сети организации. Таким способом можно сделать документы правил доступными для всех пользователей и сэкономить деньги организации на распечатке этих документов. Кроме того, все последующие обновления будут осуществляться в одном месте, и не нужно заботиться об их распространении.
В правилах, определяющих работу в данной области, нужно не только регламентировать публикацию документов, но необходимо записать требования по регистрации сроков публикации или обновления. В предписаниях этих правил необходимо также указать, кто будет отвечать за эту работу. Во многих организациях стараются возложить эти обязанности на отдел кадров. Однако, в некоторых мелких компаниях, которые пользуются услугами сторонних отделов кадров (кадровых агентств), могут назначить ответственной за публикацию документов правил иную службу. Одна из версий такого типа правил звучит следующим образом.
Отдел кадров должен нести ответственность за публикацию во внутренней сети организации документов правил информационной безопасности и всех последующих обновлений, и должен обеспечить каждому свободный доступ к документам правил.
После публикации документов правил или последующих их обновлений отдел кадров должен уведомить о публикации документов правил и способе доступа к ним каждого пользователя.
В одной компании, с которой сотрудничал автор книги, высказали беспокойство о том, что электронная копия может оказаться недоступной. Серверы могут отказать в работе, сетевое оборудование может выйти из строя, а внутренняя сеть может оказаться недоступной для некоторых удаленных пользователей. Они хотели, чтобы в предписаниях правил было требование публиковать печатную версию документов, доступную для всех отделов, а также для всех, кто не имеет доступа к внутренней сети. Посовещавшись, мы составили такую формулировку.
Отдел кадров должен нести ответственность за обеспечение всех отделов и тех, кто не имеет доступа к внутренней сети, печатными копиями документов правил одновременно с публикацией электронной версии.
Работа с отчетностью об инцидентах, затрагивающих информационную безопасность
Отчеты об инцидентах могут приходить из нескольких источников. Проблемы с защитой обнаруживают администраторы, и для того, чтобы пользователи могли фиксировать нарушения, они должны иметь правила, определяющие, как это делать. Отчеты об инцидентах могут приходить и извне организации, зафиксированные посторонними службами администрирования, так как проблемы могут быть связаны с сайтом организации, правовыми нарушениями или с контролирующими органами и т.п. И, наконец, может быть широковещательное оповещение о проблемах, которое может исходить от поставщика или группы реагирования на инциденты.
В первую очередь, в данных правилах устанавливаются требования по отчетности для администраторов и пользователей. При разработке этих правил желательно ввести в них формулировку с требованием, чтобы отчетность составлялась строго по определенным методикам. Это означает, что кто-то должен разработать эти методики. Формулировка может выглядеть следующим образом.
Администраторы и пользователи должны докладывать обо всех нарушениях правил безопасности и связанных с ними процедур, в которых используются утвержденные методики составления отчетности.
Затем, в правилах необходимо рассмотреть, что следует предпринимать, когда отчет об инциденте приходит из внешних источников. Большинство организаций, с которыми пришлось иметь дело, предпочитают относиться к этим сообщениям серьезно и хотят с ними разобраться. На этом основании можно написать следующую формулировку.
Администраторы должны серьезно относиться к сообщениям об инцидентах от всех внешних источников и проверять их достоверность. Результатами этих проверок необходимо оперировать, руководствуясь утвержденными правилами.
В этих правилах ничего не говорится о том, что делать, если сообщение об инциденте приходит от правоохранительных органов. В большинстве организаций довольно болезненно воспринимают ситуации, когда полиция стучится к ним в дверь по поводу каких-то проблем. В одной организации, с которой сотрудничал автор книги, хотели разработать правило, предписывающее прямую ответственность руководства за все, что относится к расследованиям, связанным с правоприменением.
Если утвердить такое правило, то не избежать проблемы, вызванной тем, что ответственное руководящее лицо недостаточно осведомлено в вопросах безопасности и не может руководить этими расследованиями. В организации решили включить в правила такую формулировку, рассчитывая разработать специальные процедуры позже. Формулировка выглядела следующим образом.
Меры реагирования на нарушения закона необходимо координировать с руководством. Руководство должно выступать в роли ведущего собственного следователя, а также нести ответственность за связи и взаимодействие с правоохранительными органами.
Заключительный аспект правил составления отчетности относится к работе с широковещательными сообщениями о проблемах, поступающими от поставщиков и групп реагирования на инциденты. Здесь возникает спорный вопрос, касающийся того, какие отчеты каких групп реагирования принимать в качестве достоверного источника сообщений о потенциальных проблемах. Некоторые советуют прислушиваться к мнению поставщиков, хотя их критикуют за слишком медленное реагирование. Другие для получения надежной информации предпочитают работать с такими организациями, как координационный центр CERT (CERT/CC). Однако CERT/CC критикуют за то, что он не реагирует на все инциденты. Кроме того, они не рассматривают доклады поставщиков антивирусного обеспечения о вирусах.
Все вышесказанное усложняет разработку правил широковещательного раскрытия информации. Разработчики правил имеют тенденцию включать в правила принципы работы со всеми группами реагирования на инциденты для обеспечения гарантий того, что ничего не будет упущено. Вместо того чтобы разрабатывать комплексные правила, лучше включить в правила формулировку, предписывающую разработку процедур, которые можно менять при изменении требований. Формулировка может выглядеть следующим образом.
Администраторы должны отслеживать широковещательные публикации организаций, сообщающих об инцидентах, ошибках и других проблемах, которые могут повлиять на безопасность сети и систем организации.В список этих организаций должны входить поставщики информационных систем, используемых в организации, по крайней мере, две ведущие организации, а также выбранный организацией поставщик антивирусного программного обеспечения.
Работа с правоохранительными органами
Если организация планирует работать с правоохранительными органами, то необходимо определить характер этой работы. Во-первых, далеко не каждое силовое ведомство способно заниматься расследованиями компьютерных преступлений. Большинство местных полицейских управлений не способно выполнять требования, необходимые для таких расследований. Так что если дело происходит в Соединенных Штатах, то все расследования такого типа ложатся на ФБР.
Для работы с любой правоохранительной организацией не существует никаких формул. Перед разработкой правил может возникнуть желание связаться с местным бюро расследований или периферийным отделением ФБР, чтобы выяснить их требования, касающиеся отчетности организации о преступлениях. При разработке правил воспользуйтесь этой информацией.
Для обеспечения гарантий защищенности систем
Для обеспечения гарантий защищенности систем и сети нужно определить правила согласования и внедрения, в которых разъясняются меры, принимаемые при нарушениях правил безопасности. Правила согласования и внедрения выходят за рамки технической сферы, в которой работает большинство профессионалов в области безопасности. Разработка этих правил требует знания различных корпоративных правил, а также соответствия различным законам, включая закон об интеллектуальной собственности, трудовое законодательство и, возможно, уголовное право.
Согласование и внедрение
После завершения разработки правил информационной безопасности наступает этап утверждения и внедрения этих правил. Хорошо, если можно было бы доверять пользователям и всем остальным, кто имеет доступ к системам и сети организации. Для обеспечения гарантий защищенности систем и сети нужно определить правила согласования и внедрения, в которых разъясняются меры, принимаемые при нарушениях правил безопасности.
Правила согласования и внедрения выходят за рамки технической сферы, в которой работает большинство профессионалов в области безопасности. По своей природе разработка этих правил требует знания различных корпоративных правил, а также соответствия различным законам, включая закон об интеллектуальной собственности, трудовое законодательство и, возможно, уголовное право. Поэтому весьма важно, чтобы в обсуждении этих правил участвовали представители всех сфер деятельности, на которые будут влиять правила.
Консультации у юриста
На протяжении всей книги приводятся примеры формулировок правил, которые можно использовать в качестве образца при разработке своих правил. Можно также эти примеры целиком вставлять в разрабатываемые правила. Но не следует забывать, что эти примеры базируются на личном опыте автора, поэтому следует их доработать согласно конкретным юридическим нормам.Поэтому мы настоятельно рекомендуем, для проверки законности этих формулировок проконсультироваться у юриста той страны, в которой компания занимается бизнесом.
Соображения, касающиеся действий после совершения компьютерных преступлений
В последние годы компьютерные преступления стали центром внимания служб безопасности. Поскольку организации стали относиться к вопросам безопасности своих информационных активов более серьезно, все громче слышны требования сурово наказывать тех, кто совершает компьютерные преступления. В этом ключе Конгресс США, многие государства и даже такие международные сообщества, как Европейский Союз, приняли законы, направленные на борьбу с компьютерными преступлениями.
Тем не менее, бороться с компьютерными преступлениями довольно нелегко. Несмотря на то, что некоторые правоохранительные органы пытаются обучиться работе на этом новом фронте, кажется, пока только ФБР имеет достаточно ресурсов, необходимых для расследования некоторых преступлений. Однако их ресурсы тоже ограничены, поэтому они установили нижний порог наносимого компьютерным преступлением материального ущерба, ниже которого преступление не подлежит расследованию.
Далеко не каждая организация захочет докладывать о компьютерных преступлениях. Ведь в случае раскрытия этой информации организация сталкивается с трудностями и возможными негативными последствиями на рынке, что может вызвать к ней недоверие. Из состава акционеров крупного банка вышел акционер, державший большой пакет акций, после того как обнаружилось, что взломщик похитил 10 миллионов долларов через Internet. Банк раскрыл эту информацию только по предписанию судебного ордера. В противном случае никто бы никогда об этом и не узнал.
Соображения по регистрации событий
Независимо от того, насколько тщательно в организации проводится контроль за безопасностью, большая часть нарушений всплывает только после того, как они были сделаны. В большинстве случаев администратор замечает признаки нарушений без чьей-либо помощи. Один из методов, применяемых администраторами при наблюдении за работой системы, заключается в проверке журналов, которые создаются в системе и в основных пакетах программного обеспечения. В журналах, создаваемых этими компонентами, фиксируются все операции, которые пользователи выполняют в системе или сети, а также фиксируются все ошибочные и успешные попытки доступа к системе.
Правила регистрации довольно сложны, поскольку невозможно составить общую формулировку, удовлетворяющую любой конфигурации системы. В тех случаях, когда считается непрактичным регистрировать каждую операцию, выполняемую в компьютерной системе, необходимо обеспечить поддержку сервисных систем, обслуживающих базы данных. В правилах может быть сказано, что в журналы должны заноситься все важные события, но кто может сказать, какие события являются "важными" для каждой сети и системы? Кроме того, для некоторых систем в отдельных организациях ведение журналов может быть необязательно. Например, в сервере, обслуживающем печать, функции регистрации могут быть отключены, поскольку вспомогательные системы печати могут хранить эту информацию в ином месте.
При рассмотрении правил регистрации событий необходимо разработать формулировку, которая предписывает регистрировать в журналах события, имеющие отношение к безопасности. Таким образом можно гарантировать, что для юридических разбирательств имеется информация, в которой зафиксированы факты нарушения безопасности. Ясно, что это может быть далеко не вся информация, используемая в таких случаях, но такая информация необходима. Дополнительные соображения по этому вопросу выглядят так.
В правилах регистрации событий нужно еще описать, как должна обрабатываться информация из журналов. Это очень важный процесс в технологии контроля безопасности, поэтому в правилах должны быть определены инструкции по обработке содержащейся в журналах информации. Этим будет гарантирована доступность содержимого журналов для администраторов. Некоторые полагают, что эти правила слишком обобщены, и что администраторы в них не нуждаются. Автор книги предполагает, что не все могут самостоятельно сделать необходимые выводы, поэтому рекомендует все-таки включить такие формулировки в правила. Обобщенный набор формулировок может выглядеть следующим образом.
Администраторы должны регулярно просматривать системные и другие журнагы регистрации.
Просматривать файлы журналов могут только пользователи, которым даны на это права.
Администраторы должны предпринять необходимые меры предосторожности, чтобы исключить отключение заполнения журналов, их исправление или удаление.
При обнаружении нарушений этих правил или безопасности сетей администраторы должны выполнить установленные процедуры.
В отношении последней формулировки правил нужно сказать, что несмотря на легкость создания процедур обработки журнальных записей, их очень сложно реализовывать. Проблема заключается не в сборе информации, что относительно просто, а в том, что это действительно искусство — методическая работа с регистрационными записями и определение с их помощью, что же произошло на самом деле. Это требует большого опыта и времени.
И. наконец, в правилах необходимо оговорить, что делать с системными журналами по прошествии времени. Администраторы понимают, что записи в журналах должны циклически обновляться и даже удаляться из системы, чтобы дать возможность системе фиксировать новые события. Для такого управления работой с журналами должны быть разработаны правила, определяющие порядок замены и обновления журналов. При разработке этих правил нужно учитывать наличие в системе свободного дискового пространства и других системных ресурсов, а также требования к продолжительности хранения журналов.
Правила обновления могут меняться в зависимости от рода деятельности организаций, а также от разновидности журналов. Например, финансовые организации могут хранить записи о финансовых сделках сроком до 10 лет. чтобы можно было в будущем провести аудит. Кроме того, может потребоваться разработка правил обслуживания носителей, на которых записаны эти регистрационные журналы. Эти правила могут походить на правила создания резервных копий, которые обсуждалась в главе 2 "Определение целей политики".
Соображения по сохранению улик
Правоохранительные органы все еще работают по принципам обеспечения физической безопасности территории, и эти принципы они распространяют на расследования любых преступлений. К сожалению, место совершения компьютерных преступлений невозможно оградить сплошной желтой лентой. Однако при расследовании компьютерных преступлений, очень важно сохранить улики, чтобы доказать факт совершения преступления — с учетом требований правоохранительных органов и государственных прокуроров, которые будут преследовать злоумышленников в судебном порядке.
При разработке правил, касающихся этой области, должны быть изучены все аспекты взаимодействия с правоохранительными органами, чтобы четко определить требования правил. Для крупных организаций, обладающих возможностями размещать свои офисы в различных штатах и странах, необходимо рассмотреть все вопросы, связанные как с юрисдикцией вообще, так и с особенностями применения законов, связанными с местом размещения офиса. Дело в том, что правовые нормы для различных местных, относящихся к юрисдикции штатов и принадлежащих федеральному правительству органов, могут быть совершенно разными. Иногда наилучшим выходом может оказаться разработка простых правил, в которых говорится, что организация будет работать с правоохранительными органами в соответствии с их нормативами. Детали можно оставить для раскрытия их в связанных с правилами процедурах после обсуждения всех деталей в местном отделении адвокатской конторы.
Тестирование и эффективность правил
Этот раздел иногда называют Правилами правил. Здесь рассматриваются различные вопросы, начиная с того, каким образом оценивать эффективность проводимой политики. Мы говорим не о тестировании алгоритмов, а о том, насколько внедрение правил делает бизнес более эффективным, благодаря проводимым процедурам согласования.
Проверка правил на соответствие является весьма субъективным процессом. Большинство организаций, с которыми работал автор, предпочитают хранить в тайне статистику выявленных нарушений и разрешенных нарушений правил. Поэтому не удается получить информацию, которую можно бы было использовать при доработке правил информационной безопасности. Вот поэтому правила, разрабатываемые в этом разделе, охватывают процессы сбора статистики и составления отчетов. Кроме того, для подкрепления этих процессов рекомендуется включить в правила формулировку о проведении инструктажа по безопасности.
Что же касается инструктажа по безопасности, то после разработки правил необходима совместная работа разработчиков правил, руководства и каждого сотрудника организации для изучения правил и их применения. Руководство должно не только выделить для этого время, но и всячески содействовать проведению обучения. Введение требований проведения инструктажа в качестве первой формулировки правил в этом разделе говорит о том, что инструктаж является очень важным компонентом в плане обеспечения безопасности. Это может быть отражено в следующей формулировке.
Все пользователи для получения права доступа к сети и системам организации должны пройти инструктаж по безопасности для ознакомления с правилами безопасности. Пользователи, которые уже работают в сети, должны пройти инструктаж в течение 30 дней после введения в действие этих правил.
После ознакомления пользователей с правилами информационной безопасности следующим шагом нужно продемонстрировать степень соответствия правил реальной работе. Это будет мерой эффективности работы по данным правилам. Следует помнить, что речь идет о правилах, так что не стоит углубляться в специфику. В правилах может быть записано, что заниматься сбором и обработкой статистических данных и другой информации о нарушениях безопасности, а также о разрешенных нарушениях правил должны администраторы. Таким образом, в правила вводится следующая формулировка.
Администраторы безопасности и системные администраторы должны делать записи обо всех нарушениях безопасности. Эти записи должны быть достаточно подробны, чтобы их можно было использовать для наложения дисциплинарных взысканий и при доработке правил безопасности. Администраторы безопасности должны вносить каждое разрешенное нарушение правил в журналы допустимых рисков. Руководители, которым необходимо нарушить отдельные предписания этих правил, должны расписаться в таком журнале и тем самым взять на себя ответственность за безопасность систем и сетей.
Требуемые действия
После сообщения об инциденте собираются улики и применяются правовые санкции, базирующиеся на этом сообщении. Недостаточно просто сообщить о том, что что-то произошло. Если в ходе расследования инцидента установлено, что требуется применить меры наказания, которые могут ограничиваться дисциплинарными мерами или применением мер, предусмотренных законодательством, то в правилах должны быть описаны требования по обработке этих улик.
Для правильного применения некоторых правил требуются познания в области работы с уликами, которые необходимы для применения юридических санкций. Все это можно отразить в нескольких общих формулировках правил. Разрабатывая эти формулировки, необходимо учитывать правила, касающиеся следующих вопросов.
Управление
Правила управления утверждают право организации на внедрение алгоритмов, позволяющих встроить в систему определенные средства управления. Хотя другие правила разрешают организации устанавливать средства управления доступом и требования аутентификации и использования паролей, эти правила определяет право реализовывать их постановления. Как бы странно это не звучало, некоторые юристы считают, что введение таких правил может оказаться необходимым для предотвращения потенциальных проблем, если организация будет выступать ответчиком в суде. Даже если судьи этого не требуют, вреда от введения этого постановления не будет. Правило может звучать достаточно просто.
Руководство должно установить средства управления согласно требованиям этих правил.
Наряду с определением управления, в правилах должно указываться, кто имеет право администрировать и тестировать эти средства управления. Организации не хотят, чтобы кто-то посторонний тестировал их средства безопасности. Помимо доступности бесплатных средств через Internet, риск такого тестирования увеличивается из-за пользователей, которые очень любопытны или умышленно нарушают правила безопасности.
Дело Рэндала Шварца
В громком деле знаменитый автор и эксперт фирмы Pearl Рэндап Шварц (Randal Schwartz) был осужден за компьютерное преступление в штате Орегон. Обвинявшийся, помимо всего прочего, в несанкционированном тестировании средств защиты сети и систем корпорации Intel, когда он работал на Intel в качестве подрядчика, Шварц заявил, что он это сделал с наилучшими намерениями. Независимо от мнения читателя об этом деле, представим, будто читатель несет ответственность за безопасность сети. Никто никогда не знает, с какими намерениями осуществляется зондирование системы — с благородными или не совсем, особенно, если это, якобы благородное, лицо делает это без разрешения. Как можно об этом знать наверняка? Что предпринял бы читатель в этой ситуации? Об этом стоит подумать при разработке ваших правил.
Формулировки этих правил очень сильно зависят от законов, касающихся вашей деятельности.
Чтобы эти правила были эффективными и, при необходимости, могли служить для обеспечения правовой защиты, законодательство или прецедентное право включает требование о том, чтобы организация руководствовалась в работе своими собственными правилами, во избежание юридического разбирательства. Люди, занимающиеся техническими вопросами, так не думают, но, тем не менее, необходимо изменить свой менталитет и всегда обращаться за помощью к адвокатам. Нижеследующую формулировку можно использовать в качестве руководства по разработке правил управления.
Руководство и назначенные администраторы должны нести ответственность за тестирование средств управления доступом и тестирование сети на наличие уязвимых мест. Пользователи не должны проводить тестирование на наличие уязвимых мест и тестирование средств управления доступом вручную или программными средствами.
Когда уязвимые места становятся известны, пользователи не должны использовать их возможности вручную или с помощью программных средств.
Руководство и назначенные администраторы должны иметь доступ к средствам, которые могут помочь в управлении и тестировании системы обеспечения информационной безопасности. Пользователи не должны иметь доступ к этим средствам через сеть организации и не должны загружать эти средства в любую область сети или "скачивать" их оттуда.
Процесс пересмотра правил
Что необходимо включить в правило пересмотра
В первых трех главах этой книги описаны основные принципы разработки таких правил. Рекомендуется также руководствоваться этими принципами в процессе пересмотра. Одна из причин таких рекомендаций заключается в том, чтобы по возможности повторно использовать информацию, собранную в процессе исследований. В течение некоторого времени разработанные для обеспечения работы по этим правилам руководства и процедуры будут способствовать этим исследованиям и давать дополнительную информацию, которая должна учитываться в процессе пересмотра.
Очень важно при пересмотре учесть информацию, полученную в результате оценки степени риска или аудита. Как уже говорилось в главе 1 "Что собой представляет политика информационной безопасности", оценка степени риска и аудит могут оказаться прекрасным инструментом при оценке степени влияния систем защиты и правил безопасности на работу сети организации. Кроме того, мы настоятельно рекомендуем, чтобы этот анализ проводил кто-то сторонний, чтобы исключить предвзятое отношение к результатам анализа. Это лучший способ обеспечить беспристрастную оценку эффективности программы защиты.
Кроме того, в процесс необходимо включить полезную информацию о технологиях, которую предоставляет руководство. Руководство определяет стратегию развития организации и может использовать эти знания, чтобы обеспечить полезное применение правил безопасности для развития организации. Например, если руководство знает о том, что ведутся переговоры о партнерстве, пример которого приводился выше, то оно может распорядиться о разработке правила работы с VPN, которое будет готово к сроку реализации условий соглашения.
Несмотря на то, что некоторая информация может показаться не заслуживающей внимания, нужно проанализировать в процессе пересмотра и ее, чтобы оценить степень ее важности. Наиболее важные данные могут предоставить сетевые и системные администраторы. Администраторы ежедневно имеют дело с пользователями, поэтому они больше всего знают о проблемах. Группа, занимающаяся пересмотром, может использовать эту информацию для определения степени влияния правил на работоспособность сети и на эффективность использования самих правил. Менеджеры, в свою очередь, предоставляют информацию о пользователях и советы, полученные от клиентов. Всю эту информацию необходимо собрать вместе и проанализировать с учетом рекомендаций по усовершенствованию правил, чтобы исключить проблемы в будущем.
Необходимо также учитывать функциональные особенности систем. Правила могут способствовать раскрытию новых возможностей системы, связанных с установлением новых конфигураций и подключений. Кроме того, они могут содействовать повышению степени доверия путем демонстрации защиты сетевых операций. Эту информацию также можно использовать для предотвращения проблем.
Комиссия по пересмотру правил
В идеале, комиссия по пересмотру правил должна состоять из представителей всех заинтересованных сторон, которые были привлечены для разработки правил. Помимо сотрудников, руководителей и различных администраторов, обслуживающих информационные технологии, в состав комиссии должен входить представитель отдела кадров и юрист. Если пересмотр отдельных правил требует юридических познаний (например, пересмотр правил шифрования), то необходимо либо присутствие юриста, сведущего в этих вопросах, либо консультация у него.
На деле для некоторых организаций является проблемой создание комиссии. Небольшие организации могут попросту не располагать достаточными человеческими ресурсами, даже если в них осознают необходимость создания комиссии. Если, отсутствует возможность физически собрать всех заинтересованных лиц, то будет достаточно самого минимального представительства.
Организации, которые не обладают ресурсами для создания комиссии, могут пойти по другому пути. Через год после разработки (с помощью автора книги) правил для небольшой организации (насчитывающей менее 50 пользователей) ее представители попросили автора помочь им скоординировать процесс пересмотра. Вместо того чтобы организовывать физическую встречу, автор проводил консультации посредством электронной почты. После того как результаты аудита были направлены всем заинтересованным сторонам, их попросили прислать по электронной почте предложения по изменению правил. Автор обработал все предложения и провел совещание, используя регулируемую группу электронной почты.
Когда представители комиссии достигли консенсуса, автор разработал измененные правила и отправил их по электронной почте в комиссию для одобрения. Автор получил копию результатов обсуждения и начал новый раунд согласования. После шести недель обсуждения и согласования комиссия внесла три изменения в свои правила, а затем была распущена, каждый участник которой остался доволен своей работой и способом ее проведения.
После разработки правил и наличия процесса пересмотра, работа по обеспечению безопасности сети организации только начинается. Администраторы безопасности должны теперь разработать или обновить процедуры и начать использовать эти средства для наблюдения и внедрения этих правил. Информационная безопасность должна стать превентивной работой, а не реакцией на неприятности.
Периодический пересмотр документов правил
Определенных рекомендаций по поводу того, как часто нужно пересматривать правила, не существует. В период сотрудничества автора с различными организациями он советовал, чтобы пересмотр производился с периодичностью от шести месяцев до одного года. Шести месяцев вполне достаточно, чтобы выявить факты, требующие корректировки правил. Однако кое-кто считает, что для этого требуется больший период времени. Если период пересмотра больше года, то могут возникнуть проблемы застоя - постепенное пренебрежение соблюдением правил и, в конце концов, полное их игнорирование.
Определение модели безопасности
Когда администраторы внедряют и контролируют правила, они могут обнаружить, что при одних и тех же обстоятельствах поступают заявки на выполнение операций в обход правил, или во время проверок регистрационных журналов выявляются факты многократных попыток нарушить правила безопасности. Существует много способов выявить и систематизировать факты и составить модель пересмотра правил по разрешенным отказам от правил, по регистрационным журналам и отчетам о нарушениях. В некоторые коммерческие пакеты, такие как системы обнаружения вторжений, включены дополнительные модули статистического анализа, которые могут помочь при решении этих задач. Другие системы типа универсальных вычислительных машин предоставляют эти средства анализа в виде утилит операционных систем.
Однако автоматизированных средств может оказаться недостаточно. Администраторам будет необходимо проводить обследование и руководствоваться интуицией для определения модели пересмотра правил, которые зависят от знания модели функционирования вашей сети. Например, в среде UNIX нередко бывают попытки зарегистрироваться в качестве основного пользователя или "суперпользователя". Несмотря на то, что эти попытки могут осуществляться различными пользователями, оказалось, что они делались с одного терминала или с одной и той же удаленной системы в этой сети. Рассмотрев такую модель можно сделать вывод, что была попытка взлома системы, проведенная с другой, уже взломанной системы. Однако, если удаленная система используется, в основном, разработчиками организации, то они могли бы попытаться провести ее диагностику и устранить проблему.
В результате такого анализа может быть разработано правило, разрешающее присваивать разработчикам право суперпользователя или предоставлять им право суперпользователя при необходимости. Однако, единственный путь прийти к такому решению - сопоставить факты нарушений с принципами работы систем или сети.
В организациях, в которых только начинают разрабатывать свою политику, беспокоятся о том, смогут ли эти правила стать фундаментом для серьезной программы защиты информации. Таким организациям рекомендуется пересматривать правила каждые шесть месяцев в течение нескольких первых лет. Побочный эффект этого процесса заключается в том, что не нужно будет включать эти сроки в правило пересмотра. Изменения в правила могут не вноситься после очередного пересмотра, а будут внесены при следующем пересмотре, если те, кто проводил пересмотр, решат, что правила достаточно стабильны и могут не корректироваться более длительный период. Чтобы утвердить процесс пересмотра, достаточно включить в правила такую упрощенную формулировку.
Правила информационной безопасности должны пересматриваться каждые шестъ месяцев.
Как нам всем хорошо известно, сети и компьютеры в руках человека могут вести себя непредсказуемо. Даже самые лучшие разработчики правил могут что-то упустить, потому что невозможно предвидеть все проблемы, которые могут возникнуть в системах. Положения о применении санкций и о разрешенном нарушении правил должны обеспечить защиту сети и в то же время разрешить определенную свободу действий, так как неизбежно, что что-то может случиться, и случается, что не учтено принятыми правилами. Возьмем пример: небольшая организация, которая занимается продажей новейшей популярной продукции, установила партнерские отношения с другой организацией. Согласно договору обе организации будут делиться информацией друт с другом для распространения продукции. В пунктах соглашения указано, что обе организации должны совместно пользоваться информацией посредством виртуальной частной сети (VPN). Однако одна из организаций не предусмотрела возможность использования такой схемы работы и не располагает правилами работы с VPX.
В случае частых изменений производственного процесса некоторые организации оказываются перед необходимостью вводить правило разрешенных нарушений или отклонений (см. главу 3 "Обязанности в области информационной безопасности"). "Разрешенное нарушение" представляет собой соглашение, подписанное ответственным за данные или технологию лицом, в котором говорится, что безопасная работа будет базироваться на отдельных отклонениях от существующих правил, описанных в новом документе. В вышеописанном примере в этом "разрешенном нарушении" может быть указано, что подключение к VPN будет произведено так же, как и подключение к Internet с некоторыми дополнительными ограничениями. Другой способ заключается в разработке правила, в котором будет положение о возможности проведения внерегламентного пересмотра правил, когда необходимо добавить или откорректировать некоторые правила в случае аварийных ситуаций. Формулировка может выглядеть следующим образом.
Руководство должно сформировать временную комиссию для разработки, обновления или пересмотра правил на тот случай, если необходимо внести значительные изменения, не дожидаясь планового пересмотра правил.
Процесс пересмотра правил
Итак, в организации разработали и внедрили правила безопасности. Пользователи прошли обучение, время от времени случаются инциденты, и все осведомлены о требованиях информационной безопасности. Но мы знаем, что правила безопасности являются всего лишь средством для внедрения в работу собственных положений. Рано или поздно вы обнаружите, что некоторые правила устарели и только мешают нормальной работе.
Правила безопасности не должны быть "мертвыми" документами. Они должны изменяться и развиваться по мере развития организации и появления новых технологий. Для этого необходимо периодически пересматривать правила. Для того чтобы этот процесс был перманентным, необходимо разработать последнее правило в нашем наборе - правило, устанавливающее процесс пересмотра. Этот процесс базируется как на собранной информации, так и на результатах анализа работы по внедренным правилам.
Документы правил безопасности не должны
Документы правил безопасности не должны быть "мертвыми" документами, изменяясь и развиваясь по мере развития организации и появления новых технологий. Для этого необходимо периодически пересматривать правила, чтобы поддерживать их актуальность. Заключительное правило должно утвердить процесс пересмотра правил, во время которого анализируется информация, собранная в результате реализации правил.
А. Глоссарий
Эти определения дадут четкое понимание терминов, которые использовались в данной книге. Чем больше технических терминов в книге, тем больше требуется информации, чтобы лучше понять содержание. Подробные определения этих и других терминов лучше всего получить по адресу http://www.whatis.com.
Авторское право (copyright). Эксклюзивное законное право на копирование, публикацию и продажу интеллектуальной собственности. Авторские права необязательно регистрировать, но регистрация поможет защитить их в суде.
Альянс производителей коммерческого программного обеспечения (Business Software Alliance — BSA). Международная промышленная организация, которая занимается борьбой с пиратским копированием программного обеспечения.
Антивирус (anti-virus). Класс программного обеспечения, которое предназначено для предотвращения инфицирования системы вирусами.
Апплет (applet). Небольшая программа, которая загружается с сервера и запускается на компьютере клиента.
Асимметричное шифрование (asymmetric encryption). См. "Шифрование открытым ключом".
Аутентификация (authentification). Процесс выяснения, является ли кто-то или что-то тем, за кого он себя выдает.
Биометрия (biometric). Технологии измерения и анализа характеристик человеческого тела в целях его аутентификации.
Брандмауэр (firewall). Устройство или программа для защиты сети. Брандмауэры размещают на шлюзах сети для предотвращения входа в сеть организации нежелательного или злоумышленного трафика и блокирования выхода несанкционированного трафика из внутренней сети.
Бюро экспортных отношений (Bureau of Export Affairs — BXA). Бюро федеральной торговой комиссии США, которое проводит государственную политику по экспорту криптографических средств.
Вассенаарское соглашение (Wassenaar Arrangement - WA). Международное соглашение по вопросам вооружения, в котором также имеются постановления по импортированию и экспортированию криптографической продукции.
Виртуальная частная сеть (Virtual Private Network — VPN). Частная сеть, в которой используется общедоступная инфраструктура телекоммуникаций, а защита обеспечивается путем использования шифрования и протокола туннелирования.
Вирус (virus). Самовоспроизводящийся злоумышленный код, который интегрируется в исполняемые хосты, такие как загрузочные секторы, исполняемые программы и макросы. Вирусы копируются при выполнении.
Внутренняя сеть (intranet). Частная сеть предприятия. Intranet может состоять из одной сети или нескольких связанных сетей, доступных только для предприятия.
Воздушный зазор (air gap). Термин, используемый при описании полного разделения двух и более сетей.
Временное подключение (transient connection). Подключение, которое не является долговременным. Подключения к сети с помощью модема и беспроводные подключения считаются временными подключениями.
Всемирная паутина (World Wide Web— WWW). "Всемирная паутина — это целая вселенная доступной через сеть информации, вместилище человеческих знаний" (определение изобретателя Web, Тима Бернерс-Ли (Tim Berners-Lee)).
Граничная проверка, проверка на нарушение границ (bounds checking). Метод разработки программного обеспечения, с помощью которого проверяют границы операций с внутренней памятью для предотвращения таких проблем, как переполнение буфера.
Демилитаризованная зона (demilitarized zone— DMZ). Сегмент сети, который размещен между сетью организации и общедоступной сетью, обычно Internet. Такие службы общедоступных сетей как DNS (Domain Name System— служба именования доменов) и Web-серверы обычно устанавливаются в DMZ.
Дешифрование (decryption). Процесс преобразования зашифрованных данных обратно в исходную форму.
Дистанционная передача данных (telecommuting). Работа вне привычного офиса, используя сетевые средства для подключения пользователя к системе организации.
Живучесть (survivability). Способность сетевой компьютерной системы поддерживать важнейшие функции во время атак и сбоев, а также восстанавливать все функции в короткий срок.
Запрос на комментарии и предложения (Request for Comments — RFC). Документ IETF, определяющий или обновляющий стандарты. Некоторые документы RFC являются только информативными.
Интеллектуальная собственность (intellectual property). В концепции информационной безопасности данные, созданные в организации и защищенные определенными правилами.
Информационные активы (information assets). Данные организации, составляющие ее достояние. Во многих организациях в информационных активах определены цели и задачи организации.
Информационный Центр сети Internet (Internet Network Information Center — InterNIC). Созданная совместно правительством США и корпорацией Network Solutions, Inc. организация. Эта организация отвечала за регистрацию и сопровождение имен доменов высшего уровня. В настоящее время сформирована всемирная организация назначения имен и адресов (Internet Corporation for Assigned Names and Numbers- ICANN), занимающаяся контролем и регистрацией процессов аккредитации.
Инфраструктура открытого ключа (public key infrastructure— PKI). Позволяет пользователям незащищенных открытых сетей защитить обмен данными. В PKI используются в паре открытый и секретный ключи, генерируемые в процессе шифрования открытым ключом, которые получают согласно подтвержденным полномочиям.
Использование изъянов (exploit). Атака компьютерной системы, основанная на использовании отдельных слабых мест.
Коммерческие программные продукты (Commercial Off-The-Shelf — COTS). Описывает продукцию, которую можно сразу закупить у коммерческих организаций.
Концентратор (hub). Устройство, в котором сходится сетевой трафик перед распределением на подключенные системы и другие сети.
Криптографический хэш (cryptographic hash). Функция, использующая криптографические функции для преобразования данных в уникальную величину фиксированной длины, которую невозможно снова преобразовать в исходные данные.
Маршрутизатор (router). Программное средство или устройство, которое проверяет адрес в пакете и определяет путь доставки пакета по назначению. В маршрутизаторах используются таблицы, где описываются сетевые подключения, для определения пути доставки пакетов.
Межсетевой обмен пакетами (Internetwork Packet Exchange — IPX). Сетевой протокол от компании Novell, который связывает сети, использующие программное обеспечение NetWare компании Novell.
Незваный гость (intruder). Другое название хакера, которое использует пресса.
Национальный институт стандартов и технологий (National Institute of Standards and Technology— NIST). Бюро департамента торговли США. Центр защиты компьютерных ресурсов (Computer Security Resource Center) разрабатывает стандарты защиты информации для федерального правительства.
Нелегальный вход (backdoor). В проектировании программного обеспечения алгоритм, запрограммированный для предоставления программисту специального доступа к программному обеспечению.
Новости Usenet (Usenet News). Набор сообщений, организованных в конференции, пересылаемый через Internet. При этом используется система хранения и распространения, которая рассылает корреспонденцию на другие серверы. Центрального сервера Usenet не существует.
Обнаружение вторжений (intrusion detection). Система, которая наблюдает за системным или сетевым трафиком в целях обнаружения нарушений в защите.
Общий шлюзовой интерфейс (Common Gateway Interface — CGI). Стандарт, используемый при передаче данных от клиента (например, от броузера) на Web-сервер для обработки его специальной программой на сервере.
Ответственность за информацию (Information Ownership). Концепция назначения кого-то ответственным за управление данными и обеспечение их целостности.
Отказ в обслуживании (Denial of Service — DoS). Атака системы или сети, в результате которой пользователи не могут получить доступ к ресурсам.
Открытый исходник (open source). Ссылается на любую программу, исходный текст которой сделан доступным для общего пользования или модификации. Большинство открытых исходников программного обеспечения разработано в результате совместной работы.
Отправка электронной почты (sendmail). Популярная открытая исходная программа, используемая для управления пересылкой электронной почты через Internet.
Оценка степени риска (risk assessment). Процесс оценки защиты и определения уязвимых мест в сети.
Пакет (packet). Минимальный набор данных, пересылаемых по сети.
Пароль (password). Уникальная последовательность символов, которая вводится пользователем в систему, чтобы идентифицировать себя. Один из этапов аутентификации.
Переполнение буфера (buffer overflow). Распространенная проблема программного обеспечения, когда внутренняя команда управления памятью записывает данные в область, находящуюся вне этих границ. Может быть предотвращено с помощью граничной проверки.
План послеаварийного восстановления (Disaster Recovery Plan — DRP). Процедуры, разработанные в процессе планирования чрезвычайных обстоятельств для обеспечения того, чтобы информация в сетях, системах и базах данных не была потеряна в случае аварийных отключений или бедствий. В некоторые DRP включены процедуры поддержания эксплуатации в случае аварийных отключений.
Планирование чрезвычайных обстоятельств (contingency planning). Разработка процедур для обеспечения того, чтобы информация в сетях, системах и базах данных не была потеряна в случае аварийных отключений или бедствий. Результатом планирования чрезвычайных обстоятельств является план послеаварийного восстановления.
Подсеть (subnetwork). Часть сети организации. Обычно, подсети создаются для изолирования сетевого трафика от остальной части сети.
Правила информационной безопасности (information security policies). Правила, определяющие программу защиты информации.
Правило конфиденциальности (privacy policy). Формулировка, определяющая, как в организации должны работать с собираемой конфиденциальной информацией.
Правило надежной работы (Acceptable Use Policy — AUP). Правило, которое пользователи соглашаются соблюдать, прежде чем получают доступ к сети.
Право на информацию (data ownership). Концепция назначения ответственных за данные в целях распределения обязанностей в области защиты информации.
Преобразование сетевых адресов (Network Address Translation — NAT). Преобразование IP адреса, используемого в одной сети, в другой IP адрес, принятый в другой сети.
Привлечение внешних ресурсов (outsourcing). Соглашение, согласно которому одна компания предоставляет услуги для внутреннего использования в другой организации.
Принудительный пароль (duress password). Специальный пароль, предназначенный для административных функций, введение которого означает, что пользователь вошел в систему под принуждением. Цель пароля — показать контакт с системой или показать источник проблемы.
Проверка пакета сохраняемых адресов (stateful packet inspection). Тип фильтрации брандмауэра, которая поддерживает состояние входящих пакетов для предотвращения атак, основанных на фрагментации пакетов. Проверка пакета сохраняемых адресов может также приводить в соответствие ответы внешним запросам для обеспечения дополнительного контроля.
Промышленный шпионаж (industrial espionage). Похищение одной компанией или иностранным государством технических секретов или коммерческих тайн другой компании.
Протокол динамической конфигурации хоста (Dynamic Host Configuration Protocol — DHCP). Протокол, который позволяет сетевым администраторам централизованно управлять и автоматизировать распределение адресов IP (Internet Protocol) в сети организации.
Протокол передачи от точки к точке, протокол двухточечного соединения (point-to-point protocol— PPP). Протокол, используемый для обмена между двумя компьютерами, использующими серийный интерфейс, обычно с помощью телефонных линий.
Протокол пользовательских дейтаграмм (User Datagram Protocol — UDP). Коммуникационный протокол без установления соединений, который пересылает между системами отдельные наборы данных, называемые дейтаграммами. UDP не гарантирует ни того, что дейтаграммы будут получены после отправления, ни того, что удаленный сервер вообще получит эти дейтаграммы.
Протокол управления передачей (Transmission Control Protocol — TCP). Коммуникационный, ориентированный на подключения протокол, который пересылает сообщения между системами. TCP поддерживает режим передачи пакетов, пока не убедится, что все данные доставлены в удаленную систему, а удаленная система собрала эти пакеты надлежащим образом.
Протокол управляющих сообщений в сети Internet (Internet Control Message Protocol- ICMP). Протокол, фиксирующий сбои и контролирующий сообщения между хостами Internet. В ICMP используются прозрачные для пользователя дейтаграммы IP и пользовательские приложения.
Протокол начальной загрузки (bootstrap protocol - ВООТР). Протокол, который позволяет компьютеру в сети автоматически получать сетевой адрес при загрузке или инициализации операционной системы. ВООТР является основой протокола динамической конфигурации хоста (Dynamic Host Configuration Protocol — DHCP).
Рабочая группа проектирования Internet (Internet Engineering Task Force — IETF). Добровольная организация, которая поддерживает стандарты, используемые в Internet.
Распределенный отказ в обслуживании (Distributed Denial of Service — DDoS). Атака ресурсов одного сервера с нескольких систем одновременно в целях вызвать отказ в обслуживании.
Реагирование на инциденты (incident response). Правила и процедуры, разработанные для реагирования на проблемы или нарушения в защите.
Ретрансляция кадров (Frame Relay). Служба телекоммуникаций, созданная для соединения локальных сетей (LAN). Их называют конечными точками в сети ретрансляции кадров. Служба ретрансляции кадров упаковывает данные в кадры переменной длины (фреймы) и пересылает их на связанную конечную точку. Все исправления ошибок делаются в конечной точке, что увеличивает скорость передачи данных.
Сетевая файловая система (Network File System— NFS). Протокол, который позволяет компьютеру использовать диск удаленного компьютера таким образом, будто этот диск стоит на собственном компьютере пользователя.
Сервлет (servlet). Небольшая программа, которая запускается на сервере.
Симметричное шифрование (symmetric encryption). Тип шифрования, в котором для шифрования и дешифрования используется один и тот же ключ.
Служба именования доменов (Domain Name Service — DNS). Сервер, который преобразует читабельное имя домена в IP-адрес.
Служба межсетевых адресов в среде Windows (Windows Internet Naming Service — WINS). Сетевая служба Microsoft Windows, которая поддерживает преобразование системных имен из сетевых адресов Windows в IP-адреса.
Список управления доступом (access control list — ACL). Таблица, используемая системами и системным программным обеспечением для определения прав доступа.
Спуфинг (spoofing). Этап атаки сети, на котором взломщик меняет IP-адрес пакета на тот адрес, который атакуемая система признает достоверным или на который система готова отправить ответ.
Сценарий атаки (attack scenario). Этап анализа сети на живучесть. Сценарии атаки определяют, каким образом может быть атакована система.
Тестирование на преодоление защиты (penetration testing). Процесс проверки защиты внешних границ сети.
Троянский конь (Trojan Horse). Программа, в которой код злоумышленника содержится внутри программы или данных, на первый взгляд, безобидный, но способный перехватить управление и повредить компьютер.
Туннелирование (tunneling). Протокол, который определяет специфический виртуальный путь, который проходят сообщения через IP-сети.
Упрощенный протокол электронной почты, протокол SMTP (Simple Mail Transfer Protocol). Протокол 5 уровня, используемый для пересылки электронной почты с одной системы на другую.
Уязвимость (vulnerability). Слабое место в системе, которым могут воспользоваться взломщики. Эти слабые места обычно являются результатом недоработок проекта, ошибок в программах или ошибок конфигурации в системном и вспомогательном программном обеспечении.
Федеральные стандарты обработки информации (Federal Information Processing Standards — FIPS). Стандарты, используемые федеральными службами США для определения среды обработки информации. Публикации FIPS представляют собой задокументированные стандарты, поддерживаемые национальным институтом стандартов и технологий (NIST).
Функциональная совместимость (interoperability). Способность программного обеспечения или систем работать друг с другом без специальной поддержки.
Хакер (hacker). Термин, используемый программистами по отношению к хорошему программисту. В прессе этим термином называют тех лиц, которые взламывают системы и сети без соответствующих санкций, или тех, кто занимается электронным мошенничеством.
Центр Защиты Национальной Инфраструктуры (National Infrastructure Protection Center- NIPC). Подразделение ФБР, занимающееся расследованиями, под юрисдикцию которого подпадают важные государственные инфраструктуры, включая Internet.
Цифровая подпись (digital signature). Криптографические хэши, создаваемые с помощью секретного ключа в цифровом виде. Цифровые подписи могут сверяться с помощью открытого ключа подписавшейся стороны, который может быть защищен сертифицированными полномочиями.
Цифровой сертификат (digital certificate). Небольшой фрагмент данных, создаваемых при сертифицировании полномочий, который содержит информацию о том, кто получил этот сертификат, а также об официальном органе, который выдал сертификат. Цифровой сертификат содержит открытый ключ, который используется при шифровании открытым ключом.
Человек в центре атаки (Man In The Middle Attack). Атака, в которой перехватывается и копируется, или модифицируется сообщение перед передачей его назначенному получателю. Цель заключается в перехвате информации по аутентификации или фальсификации пересылаемой информации, такой как финансовые документы.
Червь (worm). Самовоспроизводящийся код злоумышленника. "Черви" проявляют себя в том, что становится заметна чрезмерная нагрузка или когда процесс самовоспроизведения становится неуправляемым.
Широковещательная рассылка сообщений (spam). Незатребованная, практически бесполезная электроннная почта, обычно реклама, принудительно рассылаемая большому числу абонентов электронной почты.
Шифрование (encryption). Преобразование данных в форму, которую трудно понять неуполномоченным лицам.
Шифрование открытым ключом (public key cryptography). Основано на математической функции, в которой используется один ключ для шифрования сообщения и другой ключ для его дешифрования. Один ключ общедоступен, а другой ключ хранится в секрете.
Шлюз (gateway). Точка в сети, являющаяся входом в другую сеть.
Экстрасеть (extranet). Частная сеть, в которой используется Internet-протокол и открытая сеть Internet для безопасного расширения внутренней сети (intranet) организации, чтобы сделать ее доступной для партнеров, клиентов, поставщиков и т.д.
Электронный обмен данными (Electronic Data Interchange — EDI). Стандартный формат, используемый торговыми партнерами при обмене деловой информацией. Сообщение EDI содержит строки с элементами данных, каждая из которых представляет отдельный фрагмент. Вся строка называется сегментом данных. Один и более сегментов данных можно группировать вместе для формирования набора транзакций. Эти наборы транзакций обычно содержат элементы, которые являются стандартными документами или формами, используемыми в бизнесе.
ActiveX. Объектно-ориентированный язык, разработанный корпорацией Microsoft и используемый для создания перемещаемых программ (mobile code).
AUP. См. "Правило надежной работы".
BSA. См. "Альянс производителей коммерческого программного обеспечения".
ВХА. См. "Бюро экспортных отношений".
CGI. См. "Общий шлюзовой интерфейс".
COTS. См. "Коммерческие программные продукты".
DDoS. См. "Распределенный отказ в обслуживании".
DHCP. См. "Протокол динамической конфигурации хоста".
DMZ. См. "Демилитаризованная зона".
DoS. См. "Отказ в обслуживании".
DRP. См. "План послеаварийного восстановления".
FIPS Pub 140-2. Требования защиты для криптографических модулей, стандарт, используемый федеральными службами США для шифрования.
ICMP. См. "Протокол управляющих сообщений в сети Internet".
IETF. См. "Рабочая группа проектирования Internet".
ISO 9001. Стандарт, описывающий стандарты управления качеством всех процессов и процедур бизнеса.
Java. Объектно-ориентированный язык, разработанный компанией Sun Microsystems и используемый для разработки перемещаемых программ.
Kerberos. Разработан как часть проекта Athena Project в Массачусетсом технологическом институте (MIT — Massachussets Institute of Technlogies). Метод защиты санкционированных запросов в компьютерной сети. Kerberos позволяет пользователю запрашивать "билет" в процессе проверки полномочий, который используется для запроса к серверу на обслуживание. Службы Kerberos-aware проверяют запрашиваемый билет в целях определения прав доступа.
Mobile code (перемещаемая программа). Название программного обеспечения, которое можно загрузить с сервера и запустить в любой системе. Для создания mobile code обычно используются ActiveX и Java.
NAT. См. "Преобразование сетевых адресов".
NetWare. Сетевая операционная система, разработанная корпорацией Novell, Inc., которая поддерживает сетевые протоколы IPX и IP.
NFS. См. "Сетевая файловая система".
NIPC. См. "Центр Защиты Национальной Инфраструктуры".
NIST. См. "Национальный Институт Стандартов и Технологий".
PKI. См. "Инфраструктура открытого ключа".
РРР. См. "Протокол передачи от точки к точке, протокол двухточечного соединения".
Proxy server (промежуточный сервер). Вспомогательная система, которая действует в качестве промежуточного звена между пользователем или системой, расположенных на внутренней сети, и Internet для обеспечения надежной защиты.
Shareware. Программное обеспечение, которое распространяется бесплатно с условием, если пользователь продолжит пользоваться им после истечения определенного периода времени, обычно 30 дней, то он должен оплатить лицензию.
TCP. См. "Протокол управления передачей".
UDP. См. "Протокол пользовательских дейтаграмм".
VPN. См. "Виртуальная частная сеть".
Ресурсы
Дополнительная информация о реагировании на инциденты
Информацию об инцидентах предоставляют также службы, выявляющие ошибки в программном обеспечении. По причине того, что многие проблемы с защитой возникают именно в результате использования этих ошибок, имеет смысл просматривать эти узлы и внести их в свой список рассылки.
Группы реагирования на инциденты
Перечисленные в этом разделе группы распространяют информацию о проблемах с защитой, о которых им стало известно. Помимо отчетов об инцидентах эти группы работают с множеством поставщиков и пользовательских организаций, предупреждая их о потенциальных проблемах. Этим занимается каждая группа. Кроме того, они предоставляют собственный перечень услуг, включая архивирование защитного программного обеспечения (источник информации) и отправление сообщений об инцидентах.
Информация поставщиков о средствах защиты
Ниже представлены адреса Web-узлов основных поставщиков операционных и сетевых систем, а также пользовательских групп, занимающихся вопросами защиты этих систем. На этих узлах можно найти информацию от поставщиков о решении различных проблем безопасности. По адресам Web-узлов, помеченных "звездочкой" (*), можно связаться непосредственно со штаб-квартирами корпораций-поставщиков или выйти на поддерживаемую ими страницу, так как эти поставщики не предоставляют отдельно услуг по защите или предоставляют их только на условиях подписки.
Информационные ресурсы по вопросам безопасности
Ниже следует список групп, которые предоставляют важную информацию по вопросам безопасности. Предоставляемые ими информационные ресурсы состоят из коммерческих, образовательных и правительственных программ. Эта информация бесплатна и, в большинстве случаев, регулярно обновляется.
Криптографические правила и нормативы
Шифрование - это единственная область компьютерных технологий, которая регулируется законами, правилами и соглашениями. Исторически сложилось так, что все криптографические средства контролировались теми же правилами, что и вооружение. Согласно этим правилам нет никакой разницы между противоракетными системами и криптографией, предназначенной для защиты электронных операций. В США введены некоторые правила касательно импортирования продукции шифрования, и пользователи в Соединенных Штатах могут использовать криптографию, насколько, на их взгляд, она отвечает этим правилам. Проблема возникает, когда организациям требуется применить криптографию для защиты обмена информацией с заокеанскими офисами. Несмотря на некоторое смягчение законодательства в этой области, экспортирование криптографических средств все еще представляет серьезную проблему.
Ниже представлены другие источники информации.
Промышленные консорциумы и объединения
Было сделано много попыток объединить людей и организации для распространения идей и средств информационной безопасности. Ниже представлен список некоторых таких организаций, которые на время издания этой книги вели активную деятельность в этой области.
Публикации по вопросам защиты
Ниже представлены печатные издания, содержащие информацию по вопросам профессиональной защиты информации. Для подписки на эти издания необходимо посетить следующие узлы.
Ресурсы
Данные ресурсы представляют собой список адресов Web-узлов, документы, а также другую информацию, которая может оказаться полезной при разработке правил информационной безопасности и внедрении программы защиты информации в вашей организации. Информацию по вопросам безопасности можно получать из самых разных источников. Ниже представлено множество различных источников, включая коммерческие, некоммерческие, правительственные и "подпольные" ресурсы.
Ссылки на правила безопасности
Ниже следуют ссылки на различные онлайновые ресурсы, которые можно использовать для разработки правил информационной безопасности.
- RFC 2196 — Руководство по защите узла; Б. Фрэйзер (В. Fraser), Editor, SEI/CMU; сентябрь 1997 года: ftp://ftp.isi.edu/in-notes/rfc2196.txt
- RFC 2504 — Руководство по защите пользователей; Е. Гуттман (Е. Guttman), Sun Microsystems; Л. Леонг (L. Leong), COLT Internet; Г. Малкин (G. Malkin), Bay Networks; февраль 1999 года: ftp://ftp.isi.edu/in-notes/rfc2504.txt
- RFC 2828 — Словарь по безопасности Internet. P. Шайри (R. Shirey), GTE/BBN Technologies; май 2000 года: ftp://ftp.isi.edu/in-notes/rfc2828.txt
- RFC 3013 — Рекомендованные провайдерами услуг Internet система безопасности и процедуры; Т. Киллалия (Т. Killalea), neart.org; ноябрь 2000 года: ftp://ftp.isi.edu/in-notes/rfc3013.txt
- SANS Institute Reading Room выпустили несколько отдельных статей по вопросам разработки правил информационной безопасности. Эти статьи охватывают многие вопросы, начиная с помощи читателю в определении правила и заканчивая работами по его внедрению и юридическому обоснованию. Их можно найти по адресу http://www.sans.org/infosecFAQ/policy/policy_iist.htm
- Разработка правил безопасности узла AusCERT, Роб МакМиллан (Rob McMillan): ftp://ftp.auscert.org.au/pub/auscert/papers/Site.Security.Policy.Development.txt
- Прекрасные образцы правил, разработанных для университета, можно найти в Калифорнийском университете по адресу http://security.ucdavis.edu/policies
- Национальный институт стандартов и технологий (NITS) поддерживает стандарты безопасности, используемые гражданскими учреждениями. Руководство по разработке программы обеспечения безопасности для систем информационных технологий, отдельная публикация 800-18 (SP 800-18) предоставляет рекомендации правительственным учреждениям для разработки программы обеспечения безопасности. SP 800-18 помогает учреждениям работать в соответствии с постановлениями, выпущенными административным и бюджетным управлением (Office of Management and Budget— OMB). (Циркуляр А-130 (Управление федеральными информационными ресурсами), Приложение III (Защита федеральных автоматизированных информационных ресурсов)). Тем, кто сотрудничает с правительством США по вопросам информационной безопасности, необходимо прочитать эти документы, чтобы выяснить установленные к учреждениям требования. Копии этих документов можно найти по следующим адресам:
- NIST SP 800-18 — http://csrc.nist.gov/publications/nistpubs/800-18/Planguide.PDF
- Циркуляр OMB F-130 Приложение III — http://www.whitehouse.gov/omb/circulars/al30/al30appendix_iii.html
- Несмотря на то, что национальное космическое агентство США NASA (National Aeronautics and Space Administration) не является гражданским учреждением, оно предоставляет прекрасную программу обеспечения безопасности, разработанную для одного из своих проектов. Этот проект программы обеспечения безопасности объединенных сетевых систем (Integrated Services Network - NISN) NASA можно найти по адресу: http://www.nisn.nasa.gov/Doc_Repos/secplan.html
- Правила безопасности и основные стандарты бесполезны без их широкого внедрения. Насколько вам это удастся, и насколько вы справитесь с их согласованием и утверждением, определит успех вашей работы. На узле компании Security Risk Associates (в Великобритании) имеется множество статей по этим вопросам. Их можно найти по адресу http://www.security.kirion.net/securitypolicy.
Закон о страховании здоровья и медицинской ответственности
Закон о страховании здоровья и медицинской ответственности (Health Insurance Portability and Accountability Act — HIPAA) был принят в 1996 году министерством здравоохранения (Health and Human Services — HHS) для разработки стандартов безопасности и конфиденциальности, чтобы обеспечить защиту электронной информации здравоохранительных учреждений. Были разработаны стандарты защиты и конфиденциальности по обработке, хранению и пересылке этих данных, чтобы предотвратить непреднамеренное или несанкционированное использование информации, а также ее разглашение. Стандарты безопасности защиты пересылаемых данных были разработаны в августе 2000 года, а стандарты конфиденциальности — в апреле 2001 года. Система здравоохранения имела два года для приведения своих информационных систем в соответствие с постановлениями HIPAA. Ниже представлены источники информации о HIPAA.
- Закон о страховании здоровья и медицинской ответственности 1996 года (HIPAA), разработанный департаментом здравоохранения США и финансовым управлением службы обеспечения здоровья людей — http://www.hcfa.gov/hipaa/hipaahm.htm
- Phoenix Health Systems, консалтинговая фирма, специализирующаяся на информационных системах здравоохранения, финансирует этот Web-узел с информационными ресурсами HIPAA с одобрения HIPAA — http://www.hipaadvisory.com
- Разработка правил безопасности HIPAA: Совместное решение, Майлс М. Сато (Miles M. Sato) из SANS Institute Reading Room. ЗО апреля 2001 года — http://www.sans.org/infosecFAQ/policy/HIPAA_policy.htm
Защита от вирусов
Ниже представлены адреса Web-узлов основных поставщиков антивирусного программного обеспечения. Пользователям антивирусных программ от этих поставщиков настоятельно рекомендуется посетить их страничку и воспользоваться бесплатными услугами по обновлению. Это позволит получать информацию о самых последних атаках и защитить свою сеть. Ни в коем случае нельзя пренебрегать защитой от вирусов! Анализ самой последней информации и проведение активной программы антивирусной защиты является единственным способом защиты систем. Кроме того, необходимо, чтобы каждый сотрудник организации осознавал необходимость зашиты от вирусов и проведения профилактических мер.
Живучесть
"Живучесть - это способность сетевой компьютерной системы выполнять основные функции во время атак, повреждений и аварийных ситуаций и быстро восстанавливать все функции" (Р.Дж.Эллисон, Д.А. Фишер, Р.С. Лингер, Х.Ф. Липсон, Т.Лонгстафф, Н.Р. Мид "Живучесть сетевых систем: Новая дисциплина." Технический отчет CMU/SEI-97-TR-o13, ESC-TR-97-013. Ноябрь 1997 год. Адрес в Internet: http://cert.org/research/97tr013.pdf). Исследование систем на живучесть представляет собой немалый интерес, поскольку оно представляет собой попытку выйти за общепринятые рамки возведения стен и создания проходов через эти барьеры, а вместо этого сосредоточить внимание на обеспечении выполнения системой технологических задач. Ниже следуют адреса узлов, на которых можно получить более подробную информацию.
Администрирование электронной почты
Компания несет ответственность за создание и управление инфраструктурой, которая поддерживает условия безопасности и успешной доставки электронной почты внутри Компании, клиентам, партнерам и другим лицам через Internet.
В качестве части архитектуры системы Компания должна обеспечить средства сканирования содержимого сообщений для предотвращения распространения вирусов, "червей", "троянских коней" и других вредных элементов, которые могут нести угрозу безопасности систем и сети.
Архивирование электронной почты
Вся электронная почта сохраняется и архивируется. Архив находится на сервере, контролируемом и управляемом системным администратором и администратором безопасности, а доступ к нему должен быть разрешен только руководителям службы безопасности, руководству отдела кадров и исполнительным руководителям Компании. Этот архив может анализироваться в любое время для проверки выполнения пользователями правил Компании. Исполнительное руководство и руководство службы безопасности должны разработать план пересмотра и выработать систему наказания нарушителей.
Архив электронной почты будет оставаться в онлайновом режиме в течение шести месяцев, а затем будет помещен на автономное запоминающее устройство. Автономное запоминающее устройство должно обслуживаться в течение двух лет или более, в зависимости от условий договора или предписаний судебных органов. По истечении двух лет автономный носитель будет вытерт или уничтожен согласно с принятой технологией его применения.
Дисциплинарные меры
ЦЕЛЬ. Установить нормы поведения для работающих в сети и с системами Компании.
ПРАВИЛО. Категорически запрещено любое поведение, которое неблагоприятно отражается на работе других лиц в системах и сетях Компании, или которое может навредить другим лицам.
ЦЕЛЬ. Утвердить право руководства отменятъ право доступа к системам и сети для тех, кто нарушает эти правила.
ПРАВИЛО. Руководство имеет право аннулировать любые привилегии доступа пользователей и в любой момент разорвать с ними трудовое соглашение за нарушения предписаний правил безопасности или за поведение, мешающее нормальной работе сети и компьютерных систем Компании.
ЦЕЛЬ. Утвердить право руководства разрывать соглашения и контракты с теми, кому предоставлено право доступа к системам и сети на основании этих соглашений, если они нарушили эти правила.
ПРАВИЛО. Руководство имеет право разорвать контракты и договоры с подрядчиками и другими внешними пользователями, если они нарушают предписания правил или демонстрируют поведение, которое мешает нормальной работе сети и компьютерных систем Компании.
ЦЕЛЬ. Утвердить право руководства докладывать о нарушениях закона в соответствующие правоохранительные организации.
ПРАВИЛО. Руководство имеет право применить собственные меры наказания вместо соответствующих санкций по криминальному или гражданскому законодательству против любого, кто использует, злоупотребляет или атакует сеть организации и информационные системы таким образом, что это может быть отнесено к нарушениям закона и предписаний этих правил.
Дисциплинарные взыскания
Руководство имеет полномочия аннулировать право доступа любого пользователя при нарушении им этого правила, или если его действия нарушают нормальное функционирование информационных систем компании. Не допустимы любые действия, которые неблагоприятно влияют на использование систем и сетей компании другими лицами или которые могут оскорбить или нанести вред другим. Лица, нарушающие это правило, могут быть уволены.
Полномочия могут быть установлены без позволения, в этом случае руководство не несет ответственности за потерю или повреждение данных.
Информационные системы предназначены для обслуживания бизнеса
Информационные системы Компании изначально предназначены для выполнения задач, связанных с бизнесом Компании.
Персонал Компании может пользоваться информационными системами только в разрешенных пределах. Это использование не должно занимать много времени, а также не должно мешать выполнению основных задач. Личные сообщения не должны посылаться группам людей или другим служащим, за исключением случаев участия в соответствующих форумах (таких как конференции пользователей Usenet). Разрешение на широковещательное распространение личных сообщений нужно получить у вашего руководителя.
Инструктаж пользователей
ЦЕЛЬ. Обеспечить знание и понимание всеми пользователями правил.
ПРАВИЛО. Все пользователи сетей и систем Компании должны пройти инструктаж для ознакомления с правилами безопасности, прежде чем им будет предоставлен доступ. Пользователи, которые уже работают в сети, должны пройти инструктаж в течение 30 дней после введения в действие этих правил.
Интеллектуальная собственность и лицензирование
Легкость копирования электронных сообщений по пути следования их через различные коммуникационные системы представляет серьезный риск, связанный с нарушением прав интеллектуальной собственности. Каждый пользователь должен знать и соблюдать права других лиц на интеллектуальную собственность.
Программное обеспечение, которое может быть помечено как "бесплатное", "общедоступное" и "для открытого использования", может быть бесплатным для личного пользования, но не для корпоративного использования. При загрузке программного обеспечения из Internet и использовании этих программ может быть нарушено авторское право или не выполнены требования по приобретению лицензии. Поэтому, прежде чем использовать любое общедоступное программное обеспечение, вам необходимо в обязательном порядке получить разрешение вашего руководителя или юридического отдела
Не копируйте программное обеспечение, которое является интеллектуальной собственностью Компании, если в лицензии на это программное обеспечение не подтверждено ваше право делать это.
Пользователи не могут устанавливать программное обеспечение, взятое с их собственных домашних компьютеров или с каких-либо других компьютеров, пока не будет представлена лицензия на такое использование.
Без соответствующего разрешения копировать программное обеспечение, являющееся собственностью компании, запрещено.
Удаление документов об интеллектуальной собственности других лиц запрещено.
Контроль и конфиденциальность
Электронные сообщения, проходящие через информационные системы Компании, являются собственностью Компании и предназначены для выполнения задач бизнеса. Компания рассматривает все сообщения: отправленные, принятые или хранящиеся в архиве, как производственную информацию, включая и информацию, полученную для личных целей. Поэтому, конфиденциальность всех сообщений пользователей будет соблюдаться только на условиях Компании. Даже если Компания не занимается этим целенаправленно, она оставляет за собой право на контроль, предоставление доступа, пересмотр, копирование, хранение или удаление любых электронных сообщений, включая личные сообщения, получаемые с ее систем для любых целей, а также на передачу этой информации в другие руки, если Компания сочтет это необходимым.
Обязанности администраторов
ЦЕЛЬ. Обязать администраторов сохранять важные записи, фиксирующие нарушения безопасности.
ПРАВИЛО. Администраторы безопасности и системные администраторы должны делать записи обо всех нарушениях безопасности. Эти записи должны быть достаточно подробны, чтобы их можно было использовать для наложения дисциплинарных взысканий и при доработке правил безопасности.
ЦЕЛЬ. Обязать использовать журналы допустимых рисков в качестве утвержденной правилами безопасности процедуры разрешенного нарушения этих правил.
ПРАВИЛО. Администраторы безопасности должны вносить каждое разрешенное нарушение правил в журналы допустимых рисков. Руководители, которым необходимо нарушить отдельные предписания этих правил, должны расписаться в таком журнале и, тем самым, взять на себя ответственность за безопасность систем и сетей.
ЦЕЛЬ. Установить, что только системные и сетевые администраторы могут создавать и поддерживать идентификационные реквизиты пользователей и информацию, обеспечивающую управление доступом.
ПРАВИЛО. Системные и сетевые администраторы должны быть назначены ответственными за работу с информацией о пользователях и средствах управления доступом. В эти обязанности необходимо включить создание и модификацию учетных записей пользователей, а также, при необходимости, внесение изменений в средства управления доступом.
ЦЕЛЬ. Установить проведение полугодового аудита идентификационных реквизитов пользователей и средств управления доступом.
ПРАВИЛО. Системные администраторы и администраторы безопасности должны один раз в полгода проводить аудит учетных записей пользователей и соответствующих средств управления доступом для обеспечения их пригодности к использованию.
ЦЕЛЬ. Обязать администраторов разработать процедуры регистрации определенных функций систем и сетей.
ПРАВИЛО. Системные, сетевые администраторы, а также администраторы безопасности должны определить, какую информацию необходимо сохранять в системных и сетевых журналах. Кроме того, необходимо регистрировать все важные действия в области обеспечения безопасности.
ЦЕЛЬ. Обязать регулярно анализировать содержимое различных журналов регистрации и назначить администраторов, которым будет предоставлено исключительное право просматривать журналы.
ПРАВИЛО. Только уполномоченные администраторы должны регулярно просматривать системные и прочие журналы регистрации.
ЦЕЛЬ. Обеспечить защиту различных журналов регистрации.
ПРАВИЛО. Администраторы должны предпринять необходимые меры предосторожности, чтобы исключить отключение заполнения журналов, их исправление или удаление.
ЦЕЛЬ. Обеспечить гарантии своевременной отчетности администраторов о нарушениях защиты.
ПРАВИЛО. При обнаружении нарушений этих правил или безопасности сетей администраторы должны выполнить установленные процедуры.
ЦЕЛЬ. Обеспечить создание резервных копий и архивирование системных журналов.
ПРАВИЛО. Администраторы должны дублировать активные регистрационные журналы на онлайновые запоминающие устройства. Онлайновая копия должна быть заархивирована и перенесена на автономное запоминающее устройство в последний день каждого месяца. Автономное запоминающее устройство, на котором хранятся журналы, должно обслуживаться в течение двух лет, если в договоре или предписаниями судебных органов не установлен более длительный срок хранения.
Обязанности пользователей
Сообщения электронной почты являются эквивалентом почтовых открыток. Во время ее доставки каждый может прочитать содержимое сообщений. Секретная, конфиденциальная или запатентованная информация может отправляться только пользователям, которые имеют доступ к локальной сети. Патентованная информация может отправляться клиентам и партнерам, имеющим подключение к локальной сети. Нельзя отправлять через Internet никакую секретную, конфиденциальную или патентованную информацию.
Все пользователи электронной почты Компании должны выполнять Десять заповедей электронной почты. (Эти заповеди были разработаны Патрицией Макинтош (Patricia McIntosh) (fyrewede@concentric.net) и разосланы по многим адресам (дата неизвестна)).
Обязанности руководства
ЦЕЛЬ. Предоставить право на проведение мониторинга.
ПРАВИЛО. Руководство имеет право контролировать всю деятельность в системах и сетевой трафик для обеспечения гарантий выполнения этих правил. Для этого руководство назначает соответствующих администраторов и возлагает на них обязанности по проведению мониторинга, а также другие обязанности, связанные с поддержкой безопасности.
ЦЕЛЬ. Предоставить право устанавливать средства управления доступом.
ПРАВИЛО. Руководство имеет право устанавливать средства управления доступом в соответствии с требованиями этих правил.
ЦЕЛЬ. Предоставить право тестирования средств управления доступом.
ПРАВИЛО. Руководство и назначенные администраторы несут ответственность за тестирование средств управления доступом и сети на наличие уязвимых мест. Пользователи не должны проводить тестирование на наличие уязвимых мест в сети и средств управления доступом вручную или с помощью программных средств.
ЦЕЛЬ. Исключитъ возможность использования уязвимых мест.
ПРАВИЛО. Когда уязвимые места становятся известны, пользователи не должны использовать их возможности вручную или с помощью программных средств.
ЦЕЛЬ. Ограничить пользование средствами обеспечения безопасности и тестирования только представителями руководства и администраторами.
ПРАВИЛО. Руководство и назначенные администраторы должны иметь доступ к средствам, которые могут помочь в управлении и тестировании системы обеспечения информационной безопасности. Пользователи не должны иметь доступ к этим средствам через сеть Компании. Пользователи не должны загружать эти средства в любую область сети или "скачивать" их оттуда.
Обязательство
Я подтверждаю, что прочитал этот документ и буду соблюдать правила информационной безопасности Компании.
Правило хранения данных
Компания будет сохранять все сообщения электронной почты и любые копии этих сообщений в течение шести месяцев. Резервные копии информации от других компьютерных систем будут храниться в течение одного года или дольше, если это предусмотрено условиями договора.
Правило увольнений
ЦЕЛЬ. Установить процедуры добровольного или принудительного увольнения пользователей.
ПРАВИЛО. Права доступа к ресурсам организации пользователей, которые разорвали трудовые отношения с организацией, должны быть немедленно аннулированы. Администраторы должны привести в порядок программы и другие данные, с которыми работали эти пользователи. Администраторы должны разработать процедуры аннулирования прав доступа этих пользователей.
Правовые санкции и отчетность об инцидентах
ЦЕЛЬ. Установить, что каждый отвечает за реализацию этих правил.
ПРАВИЛО. Все пользователи должны нести ответственность за внедрение и реализацию положений этих правил, а также связанных с ними процедур. О нарушениях этих правил и процедур необходимо составлять отчеты, пользуясь утвержденными для выполнения этой работы процедурами.
ЦЕЛЬ. Ввести программу мониторинга различных сообщений об инцидентах, связанных с информационной безопасностъю, и об ошибках в программном обеспечении.
ПРАВИЛО. Администраторы должны отслеживать широковещательные публикации организаций, сообщающие об инцидентах, ошибках и других проблемах, которые могут повлиять на безопасность сети и систем организации. В список этих организаций должны входить, но крайней мере, две ведущие организации из перечня поставщиков информационных систем, используемых в организации, а также выбранный организацией поставщик антивирусного программного обеспечения.
ЦЕЛЬ. Установить процедуры взаимодействия с правоохранительными органами.
ПРАВИЛО. Меры реагирования на нарушения закона необходимо координировать с руководством. Руководство должно выступать в роли ведущего собственного следователя, а также нести ответственность за связи и взаимодействие с правоохранительными органами.
ЦЕЛЬ. Ужесточить требования к работе с доказательствами нарушений безопасности.
ПРАВИЛО. Данные, необходимые для обработки информации о нарушениях информационной безопасности и об инцидентах, должны сохраняться, чтобы их можно было использовать во время анализа правил информационной безопасности на эффективность применения.
Пример правил администрирования
ЦЕЛЬ. Ввести правила администрирования и внедрить правила информационной безопасности.
Пример правил безопасности электронной почты
В этом разделе вводятся правила использования в Компании электронной почты для обмена электронными сообщениями.
Пример правила надежной работы
В этом документе представлены правила ____________ (название Компании) работы, предоставления доступа, контроля и раскрытия различных электронных сообщений, включая полученные и отправленные служащими Компании. Правила эксплуатации информационных систем обязательны для всех пользователей компьютерных и сетевых систем организации, включая служащих, субподрядчиков и консультантов.
Целью данного документа является регламентация работы с "электронными сообщениями", в которые, помимо всего прочего, входит отправляемая, получаемая информация и обрабатываемая в электронной информационной сети информация, информация Internet, речевой почты, факсимильная, телеконференцсвязь, а также вся прочая информация, обрабатываемая вспомогательными системами, работающими в онлайновом режиме.
Примеры правил
На протяжении всей этой книги предлагались примеры формулировок правил. По отдельности они представляют собой довольно полезные образцы, но, как известно, люди хотят иметь полное представление о полном наборе правил. В этом приложении представлены три различных экземпляра правил, которые были взяты из документов, разработанных автором для различных организаций.
Как вы помните, примеры формулировок правил в этой книге были составлены в стиле, подобном стилю формулировок, которые описывают условия работы по правительственным контрактам США. Некоторым организациям такой стиль документов не нравится. Два экземпляра из представленных примеров правил были разработаны в ином стиле. Эти образцы были выбраны для того, чтобы продемонстрировать, как можно разработать правила, используя любой языковой стиль.
Первый пример, "Пример правила надежной работы", представляет собой правила надежной работы (AUP) для организации, насчитывающей более 250 пользователей. В то время, когда автор книги сотрудничал с этой организацией, они открыли четвертый офис в Соединенных Штатах и обсуждали возможность открытия офиса в Европе. Они запустили универсальные вычислительные машины, серверы UNIX, а также настольные ПК. Все их офисы были связаны посредством выделенных каналов связи. Эта организация хотела иметь что-то наподобие резюме их правил информационной безопасности, чтобы у пользователей не было никаких вопросов по поводу сути проводимой ими политики.
Второй пример, "Пример правил безопасности электронной почты", имеет отношение именно к правилам эксплуатации электронной почты. В этой организации были обеспокоены распространением вирусов по электронной почте и приобрели систему сканирования электронной почты на вирусы. Поскольку в организации, в основном, работали молодые люди, руководство решило, что им необходимо ознакомить пользователей с правилами этикета, которые следует соблюдать при пользовании электронной почтой. Они приняли решение воспользоваться для этого Десятью заповедями использования электронной почты. Эти заповеди были вставлены в итоговый документ правил эксплуатации электронной почты.
И, наконец, "Пример правил администрирования" представляет собой раздел правил, в котором описана работа по согласованию и внедрению правил (см. главу 12 "Согласование и внедрение"). Эти правила использовала одна развивающаяся организация, в которой шла подготовка к первичному публичному предложению (акций) (Initial Public Offering- IPO). Здесь весьма интересен стиль, которым изложены правила. Буквально перед окончанием разработки всех правил один из исполнителей добавил краткие пояснения каждой формулировки в относительно простом изложении и включил их в документ. Они были названы "Цель формулировки". После долгих обсуждений, большей частью конструктивных, эти формулировки были оставлены в документах. Однако в предисловии к документам правил было сказано об этом нововведении. Несмотря на то, что такие пояснения использовались только один раз, напрашивается вывод, что при определенных обстоятельствах можно рассмотреть их применение снова.
Публикация и уведомление
ЦЕЛЬ. Опубликовать npaвила, чтобы они стали доступными для всех пользователей, и сообщить им о публикации.
ПРАВИЛО. Отдел кадров несет ответственность за публикацию во внутренней сети Компании правил информационной безопасности и всех их обновлений. Отдел кадров должен уведомить каждого пользователя о публикации документа правил, а также о том, как получить к ним доступ.
ЦЕЛЬ. Предоставить печатные копии тем, кто не имеет доступа к электронной версии документа.
ПРАВИЛО. Отдел кадров должен предоставить каждому отделу и пользователям, не имеющим права доступа во внутреннюю сеть, по одной печатной копии документа правил одновременно с публикацией электронной версии.
Запрещенная деятельность и судебные процессы
Запрещается использовать электронные коммуникационные средства для распространения любой информации или неэтичных действий, направленных на угрозы, дискриминацию (включая языковую дискриминацию, которая может рассматриваться как третирование других на расовой основе, из-за вероисповедания, цвета, возраста, физических данных, преимуществ, сексуатьной ориентации и т.п.), клеветнические измышления, оскорбления или угрозы. В электронных сообщениях нельзя без соответствующих санкций разглашать информацию о сотрудниках. Категорически запрещается портить или вносить изменения в электронные сообщения в целях нанесения ущерба Компании или служащим Компании.
Средства электронных коммуникаций запрещено использовать для незаконных действий или нарушений прав интеллектуальной собственности других лиц. Служащим запрещено "влезать" в чужие компьютеры или перехватывать сообщения других лиц.
При составлении электронных сообщений служащие должны следовать тем же строгим правилам, что и при составлении служебных докладов. Содержание электронных сообщений может быть очень важным и сильно повлиять на финансовое состояние отдельных лиц Компании, к тому же оно может быть выдернуто из своего контекста. В виду того что отправлять такие документы очень легко, необходимо принять дополнительные меры по обеспечению гарантий того, что они не будут отправляться необдуманно и в спешке. Следует помнить, что все сообщения могут быть прочитаны кем-то еще кроме адресата. Соответственно, сообщения должны быть вежливыми, профессиональными и написаны деловым языком.
Защита электронной почты от вирусов
Электронная почта, которая заражена вирусами, "червями", "троянскими конями" или другими программными элементами, представляющими угрозу безопасности, не должна доставляться пользователю. Инфицированная электронная почта должна быть удалена из системы пересылки и проанализирована системными администраторами и администраторами безопасности. Администраторы безопасности и системные администраторы несут ответственность за разработку и сопровождение процедур обработки инфицированных сообщений электронной почты в соответствии с этими правилами.
Защита от вирусов
Пользователям запрещено намеренно создавать, запускать на выполнение, распространять или устанавливать никаких компьютерных исполняемых программ, которые могут самовоспроизводиться, вызывать повреждения или затруднять работу оперативной памяти, запоминающих устройств, операционных систем или другого программного обеспечения.
Программное обеспечение и другие файлы нельзя загружать на компьютеры Компании, пока они не будут проверены на вирусы с помощью программ сканирования. Отключение любых антивирусных средств в любой системе или сети является нарушением правил безопасности.
Базы данных: Разработка - Управление - Excel
- Базы данных
- Разработка баз данных
- СУБД и базы данных
- Управление базами данных
- Классика баз данных
- Софт для создания базы данных
- SQL
- Access
- FoxProо
- Расширенная оптимизация подзапросов в Oracle
- Informix
- Линтер
- Postgres
- СУБД DB2
- InterBase
- Excel
- Таблицы Excel
- Справка Excel
- Программирование в Excel
- Деньги в Excel
- Задачи Excel