Административные обязанности
После того, как разработаны правила подсоединения к 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. Их можно применить также в качестве образца при разработке правил для других форм электронной торговли.
Сведения о проблемах регулярно документируются в серийно выпускаемых изданиях. Истории о похищении кредитных карточек, переводе денег на офшорные счета или даже похищение товаров и услуг являются всего лишь частью проблем. Руководство организации может прочитать эти истории и ужаснуться: а сможет ли оно справиться с этими проблемами!
В последнее время, когда пришлось помочь одной организации в разработке правил электронной торговли, мы приняли решение, что наилучшим подходом будет создание отдельного документа правил и руководств. У этой организации были те же проблемы, что и у других: они усиленно инициировали введение электронной торговли и игнорировали необходимые меры защиты. Фактически, в то время, пока мы разрабатывали эти правила, группа разработчиков системы электронной торговли руководствовалась правилами, в которых предлагалось разработать план модернизации их служб, чтобы привести их в соответствие с требованиями безопасности, записанными в старых правилах.
Независимо от выбранного подхода к правилам электронной торговли существует несколько принципов, которые необходимо рассмотреть.
Хранение данных. Это касается не только того, где хранить информацию о кредитной карточке, но и где держать каталог, ценники и другую важную информацию. Можно ли размещать ее позади брандмауэра? Можно ли разместить ее в защищенной системе? Можно ли получать доступ к этой информации через защищенные (зашифрованные) каналы? До разработки правил необходимо ответить на все указанные вопросы.
Идентификация и аутентификация. Для каждого приложения электронной торговли существует отдельный метод идентификации пользователя и его полномочий по использованию приложения. Предпочтительней рассматривать, какие методы более всего соответствуют технологической модели вашей организации, а не лучшим известным образцам технологии.
Защита пересылки данных. Обычно защита сделок в электронной торговле подразумевает установку мощного Web-узла или коммуникаций, базирующихся на протоколе безопасных соединений (SSL— Secure Sockets Layer). Если вы придерживаетесь такой идеи, то стоит ли использовать системы строгого шифрования или все же позволить узлу подключаться к броузерам, которые понимают шифрование, называемое "экспорт силы" ("export strength"), которое не такое уж строгое? Собирается ли организация приобретать собственный цифровой сертификат? Будет ли организация позволять пользователям подключаться к узлу и использовать временные сертификаты, которые подходят для универсальных приложений, или же она будет требовать, чтобы клиент подключался со своим собственным сертификатом?
Обработка заказа. Где будет происходить обработка заказа? Может быть, на Web-сервере? После брандмауэра? Или на отдельном сервере? А как насчет обработки платежей по кредитной карточке? Будут ли они выполняться через 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
Когда автор помогал организациям разрабатывать правила безопасности, он старался удержать их от попыток включить в правила формулировки, которые являются частью программы инструктажа. Одним из таких понятий, которые не должны попасть в правила, является разъяснение того, что значит для организации соблюдение правил безопасности. В организации хотели, чтобы это понятие было записано в правилах, потому что этот документ утверждается высшим руководством. Такую логику, конечно, трудно оспорить.
В процессе тщательного анализа выявляются два пункта, которые должны присутствовать в данном разделе. Во-первых, формулировка должна разъяснять, что, получив доступ к ресурсам 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, разбив известные технологии на логические группы и создавая правило для каждой области применения.
1. Подход к Internet.
Прежде чем разрабатывать правила для Internet, необходимо определить количество вопросов, которые должны быть отражены в этих правилах. На первом этапе необходимо разобраться в основах архитектуры, а также понять значение брандмауэра и преобразования сетевых адресов.
Следующий шаг заключается в определении вспомогательных процедур, которые могут пропускаться через шлюз. Чтобы понять, что именно рассматривать, может оказаться полезным классифицировать вспомогательные процедуры по типу протоколов, а также по их принадлежности к входящим или исходящим процедурам.
Затем необходимо определить различия между приложениями-промежуточными звеньями, фильтрацией пакетов и проверкой сохраняемых адресов на брандмауэре.
2. Административные обязанности.
Правила, регламентирующие административные обязанности, должны предписывать обеспечение определенного уровня поддержки работы систем; должны являться частью правил группы обеспечения правовых санкций.
3. Обязанности пользователей.
Пользователи, конечно, могут думать, что им вовсе не нужен инструктаж для доступа к Internet, но в правилах должны быть требования по проведению инструктажа для разъяснения служащим их обязанностей, описанных в правилах.
Правила, рсгламентирующие обязанности пользователей, должны разъяснять, в каком виде организация желает быть представленной при посещении пользователями различных узлов Internet.
Большинство организаций заботятся о представлении своей секретной или патентованной информации. Для разъяснения того, каким образом работать с данной информацией, необходимо разработать правила.
Насколько это увлекательно, настолько и полезно загружать извне условно бесплатное программное обеспечение. Но такое удовольствие может обернуться бедой, особенно в отношении защиты информации. В данных правилах необходимо либо запретить загрузку условно бесплатных программ, либо разъяснить администраторам, какие следует разработать процедуры для работы с таким типом программного обеспечения.
4. Правила работы в WWW.
Если организация располагает собственной службой Web или пользуется внешними источниками, из которых возможен доступ к сетевой инфраструктуре организации, для защиты этого интерфейса также необходимо иметь соответствующие правила.
Правила защиты и сопровождения сервисных программ и сценариев должны предписывать ревизию этих программ на предмет безопасности и наличия ошибок. Кроме того, необходимо рассмотреть сопровождение и обеспечение защиты средств, поставляемых извне, используемых для поддержки Web-услуг.
В некоторых организациях желают иметь правила управления информацией, находящейся на Web-узле. В ином случае ответственным за данные и процессы лицам предоставляется право определять, какой информацией они должны управлять.
Самый спорный аспект услуг Web заключается в том, что могут делать ответственные за информацию с собранной информацией. С этим проблем быть не должно: необходимо ввести правила, которые сделают общедоступным правило конфиденциальности, которым следует руководствоваться при получении Web-услуг.
При разработке правил работы в Web нельзя забывать о пользователе. В правилах должна быть короткая формулировка, в которой определена ответственность пользователей при использовании ими Internet.
5. Ответственность за приложения.
Ответственные за приложения и процессы лица должны нести ответственность за пересылаемую информацию, а также за ее надежность и обеспечение гарантий того, что информация распространяется только среди пользователей, которым даны соответствующие полномочия.
Правила разработки приложений могут зависеть от правил разработки программного обеспечения или всего лишь предписывать руководствоваться в этом деле передовым опытом.
Для получения доступа к данным следует запросить приложения, которые идентифицируют внешних участников обмена через Internet, а также обеспечат расширенную аутентификацию пользователей, обращающихся к Internet. Так должны работать все приложения, получающие доступ к данным организации.
6. Виртуальные частные сети, экстрасети и другие туннели.
Эти технологии нужны не всем организациям. Для тех организаций, которым это необходимо, правила могут выглядеть в виде простой формулировки, в которой определены ключевые положения, которыми должна руководствоваться организация.
7. Модемы и прочие лазейки.
Еще один способ расширить доступ к сети организации заключается в использовании модемов. Помимо атак на отказы в обслуживании, проблема, которая может вынудить администраторов не спать по ночам, заключается в установке модема на неправильно сконфигурированной сети. Для руководства тем, где и как устанавливать модемы, также можно разработать правила.
Те, кто организовал модемный доступ к сети, должны позаботиться о разработке правил, которые разрешат администраторам централизованный мониторинг и управление этими модемами.
Поскольку получить доступ к модемам может кто угодно, было бы неплохо разработать правила, которые предписывают строгую аутентификацию тех, кто получает доступ к сети.
8. Применение PKI и других средств контроля.
Наиболее широко PKI используется в электронной торговле, которая доступна через Web и броузеры. Поскольку не рассматривается "реальный" PKI. то этот вопрос можно рассматривать в правилах электронной торговли.
Стандарты РКI и технологии постоянно меняются, поэтому довольно сложно разработать единое правило, которое будет удовлетворять при работе с PKI.
9. Электронная торговля.
В правилах электронной торговли должна быть рассмотрена вся инфраструктура, которая задействована в этом процессе. Вопросы, затрагиваемые правилами, могут быть следующими.
Хранение данных
Идентификация и аутентификация
Защита пересылки данных
Методы обработки заказов
Даже если организация при ведении электронной торговли пользуется внешними источниками, разработанные вами правила безопасности могут быть основой для составления контрактов вашей организации с провайдерами услуг.
Сетевые конференции 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). Проверка сохраняемых адресов пакетов используется как часть алгоритма фильтрации пакетов за исключением того, что брандмауэр проверяет содержимое пакетов по определенным характеристикам, чтобы предотвратить нанесение ущерба сети искаженными пакетами.
Администрирование электронной почты
То, как организация оперирует электронной почтой, также важно, как и использование системы. Правила безопасности и инструкции при подходящем случае становятся темой судебных процессов, основанием для жалоб и прочих хлопот, которые мешают работе организации или пользователей.
Другие аспекты работы с электронной почтой, будь то содержание посланий или их обработка, обычно не воспринимаются серьезно. А они являются реальными вопросами, так как находят порой отражение в скандальных делах и проблемах, связанных с электронной почтой и отражающихся на безопасности организации. Правила безопасности электронной почты должны устанавливать определенные обязанности и для пользователя, и для администратора.
Следует заметить, в этом разделе речь идет о том, что организация сама управляет собственными службами электронной почты. Если организация пользуется внешними услугами для обеспечения работы электронной почты, то следует проверить контракт, чтобы убедиться, что провайдер услуг управляет системами электронной почты в соответствии с принятыми в организации правилами. Однако, если организация пользуется онлайновыми услугами провайдера, такого как AOL (America Online), то правила будут регламентировать, в основном, пользование этими услугами и почти не затрагивать администрирование.
Архивирование электронной почты
Не стоит легкомысленно относиться к хранению и обновлению заархивированной электронной почты, поскольку если бы компания Microsoft руководствовалась собственными правилами, то сообщений, используемых правительством, могло бы уже и не существовать. Это не означает, что автор книги поддерживает использование электронной почты для якобы незаконной деятельности. Но если организация собирается разработать правила, то следует позаботиться, чтобы они были реалистичными, и руководствоваться ими в работе.
Правила архивирования и хранения содержат два компонента. Во-первых, нужно декларировать, что электронная почта будет архивироваться. Во-вторых, необходимо установить временные параметры хранения электронной почты. Также, как это делалось при разработке других правил, лучше было бы перенести вопросы, касающиеся используемых типов памяти и объемов хранимой информации, в документы по внедрению. Однако, необходимо включить в правила некоторые указания.
Организация должна сохранять и архивировать все сообщения электронной почты, которые проходят через ее сервер. Архив должен храниться на включенном в сеть запоминающем устройстве. Администраторы должны переносить архивированные сообщения на автономное запоминающее устройство каждые шесть месяцев, удаляя эти сообщения из оперативных запоминающих устройств.
Организация должна сохранять сообщения на этом автономном запоминающем устройстве, по крайней мере, два года, но может, по решению руководства, хранить его и дольше. Сообщения на автономном запоминающем устройстве должны быть стерты, или носитель должен быть уничтожен в соответствии с принятой для этого носителя технологией.
Некоторые более крупные организации, в особенности правительственные подрядчики, могут столкнуться с проблемами при создании единого правила для архивирования и хранения. От них, на основании контракта, могут потребовать руководствоваться правилами, отличными от тех, которые разработаны в организации. В таком случае организация может включить следующую формулировку в правила.
Организация должна дополнить правила, чтобы удовлетворить требования контракта, но без пересмотра правил. Данные изменения должны касаться только тех полъзователей, которые выполняют работу по настоящему договору, и организация должна уведомить этих пользователей о внесенных изменениях до их внедрения.
Цифровая подпись электронной почты
Еще одна особенность в использовании электронной почты заключается в том, что сообщение может быть сформировано, не показывая реального отправителя. Это называется спуфингом или имитацией соединения. Несмотря на то, что он используется теми, кто отправляет по собственной инициативе большое количество незатребованных сообщений (широковещательная рассылка сообщений), этот метод можно также использовать в качестве средства промышленного шпионажа. По такому сценарию сообщения отправляются пользователям организации так, будто они приходят из знакомого источника, пытаясь спровоцировать пользователей на отправку в ответ патентованной информации.
Пользователи могут установить контакт с подозрительным адресатом, запрашивающим информацию, чтобы убедиться в том, что запрос отправлен именно этим пользователем. Но культура электронной почты настолько доверительна, что такую операцию выполняют очень редко. Единственный способ гарантировать, что сообщение является корректным запросом, — сопроводить сообщение цифровой подписью. Цифровые подписи являются составной частью системы шифрования, которая использует криптографические алгоритмы для создания числовой величины, уникальной для вашего сообщения. Как и шифрование, правила управления цифровыми подписями лучше ввести в документы правил шифрования. Опять-таки, можно вставить дежурную формулировку в правила безопасности.
Любой запрос на патентованную информацию должен сопровождаться цифровой подписью, и зта подпись должна сверяться.
Пользователи, пересылающие патентованную или секретную информацию, должны "подписывать" сообщения цифровой подписью, чтобы продемонстрировать получателю, что сообщение, легитимно и зарегистрировано.
Использование цифровой подписи должно осуществляться в соответствии с принятыми в организации правилами шифрования.
Использование электронной почты для конфиденциального обмена информацией
Не любого легко убедить, что сообщения электронной почты являются электронным эквивалентом почтовых открыток. Информация, которая передается через Internet, проходит в виде читабельных байтов, доступных каждому, кто может их считать. Поскольку трафик проходит от одной сети к другой, вероятность того, что кто-нибудь прочитает сообщение, увеличивается. Кроме того, если сообщение по ошибке попадает не в тот почтовый ящик, то можно непреднамеренно раскрыть информацию, которую раскрывать нельзя.
После того, как сообщение покидает систему, отправитель не может контролировать, кто может прочитать сообщение, и даже не знает, попало ли оно по назначению. По этой причине некоторые организации создают правила, которые не разрешают отправлять по электронной почте конфиденциальную или патентованную информацию. В других организациях принимают правила, разрешающие пользователям пересылать конфиденциальную информацию только внутри организации, но запрещающие отправлять такую информацию сторонним пользователям.
Обработка электронной почты
Клиент стал беспокоиться о разработке правил эксплуатации электронной почты после того, как бывший служащий затеял судебный процесс против организации. Это была небольшая компания, насчитывающая менее 70 пользователей, и вопрос касался добавления в правила информации об архитектуре. После изучения этого запроса автор книги получил копию приказа о смещении с должности системного администратора. Юрист истца запрашивал, каким образом организация управляет маршрутизацией электронной почты, и записано ли это в правилах безопасности.
Автор книги просмотрел приказ об увольнении и другую вспомогательную документацию и пришел к выводу, что в системе, построенной на самой передовой архитектуре, можно найти детали, которые могут стать уликами против организации. Автору пришлось написать формулировку правил, которая позволяла бы организации разработать архитектуру системы, но такую, чтобы ее технические решения не могли стать зацепкой в суде. Она выглядела следующим образом.
Системные администраторы и администраторы безопасности должны совместно разработать архитектуру системы электронной почты таким образом, чтобы обеспечить надлежащую доставку сообщений как внутри организации, так и в Internet. Помимо всего прочего эта система должна допускать использование посреднических программ, переадресации, шлюзов и ручного вмешательства в управление этой службой.
Несмотря на то, что данная формулировка очень обобщенная, она удовлетворяет любое архитектурное решение и удовлетворит юристов организации.
Ограничение размеров сообщений электронной почты
Пользователи электронной почты сильно способствуют пользователям сети в создании изощренных сообщений и, тем самым, пересылке большого объема данных тем, что отправляют почту, присоединяя к сообщению файлы, хранящиеся в системе или сети. С каждым новым форматом файлов объем информации, заполняющей полосу пропускания сети, увеличивается. В одном хорошо известном университете установили, что больше половины сообщений электронной почты, проходящих через его серверы, содержали вложения, записанные в новейшем и популярном аудиоформате.
Это проблема не только университетов. В некоторых организациях было замечено, что пользователи посылали документы коллегам по электронной почте, не используя сетевые файловые серверы в качестве общего запоминающего устройства. Для управления ресурсами, используемыми электронной почтой, в некоторых организациях обновляют правила безопасности электронной почты, включая в них ограничения на размер пересылаемого файла.
Правило ограничения размеров сообщений электронной почты может просто сводиться к тому, чтобы запретить отправлять сообщение, превышающее определенный размер. Однако, бывают случаи, когда необходимо сделать исключение. В одной из организаций, с которой сотрудничал автор книги, библиотекарю нужно было отправлять и получать объемные сообщения от клиентов. Организации необходимо было иметь более гибкие правила, а не просто установить для всех одинаковое ограничение размера сообщения. Поэтому они приняли решение разработать правило, включающее формулировку, в которой говорилось, что руководство может делать исключения. Формулировка выглядела следующим образом.
Размер сообщений электронной почты, отправляемых и получаемых пользователями, в целом, не должен превышать 40 Кбайт. Исключения делаются для пользователей, условия работы которых требуют больших размеров сообщений. Администратор должен расматриватъ и разрешать исключения индивидуально.
Правила безопасности электронной почты
Мы быстро внедряем новые технологии, если они служат улучшению коммуникаций. Бурное развитие электронной почты только подтверждает это. Но электронная почта не является панацеей для всех. Помимо того, что электронная почта облегчает обмен информацией между людьми, ее используют для пересылки конфиденциальной информации, она является источником беспокойства для других пользователей, вовлечения их в нелегальную деятельность, а также ее информация может служить уликами против компании в судебных процессах.
За последние годы действительно было несколько судебных процессов, которые основывались на доказательствах, извлеченных из архивов электронной почты. Недавно в антимонопольном судебном процессе Соединенные Штаты против компании Microsoft государственные юристы использовали заархивированную электронную почту администрации Microsoft в качестве улики против компании Microsoft. Это заставило многих сфокусировать внимание на правилах использования и обработки отправленной и принятой электронной корреспонденции.
Электронное послание является эквивалентом почтовой карточки. По этой причине требуются особые подходы к электронной почте. При разработке правил безопасности электронной почты организация должна рассмотреть массу вопросов, начиная с архивного хранения и заканчивая инструкциями по оформлению содержимого посланий.
Правила использования электронной почты
Электронная почта появилась одновременно с Internet. Сообщения отправляются практически в реачьном времени и совершенно ненавязчиво. Получатель не должен немедленно читать сообщение, потому что это не телефонный звонок. Такой подход даст отправителю возможность тщательно сформулировать сообщение.
Но эта "освященная веками" пересылка информации накладывает определенную ответственность, о чем не должны забывать разработчики правил безопасности. При создании правил безопасности электронной почты рекомендуется, чтобы основные правила работы и инструкции, которыми должны руководствоваться пользователи, были изложены в правилах безопасности электронной почты в первую очередь. Один клиент решил, что для привлечения внимания пользователей ему стоит включить "Десять заповедей использования электронной почты". Использование формулировок правил безопасности такого типа представляет собой творческий путь создания впечетляющих правил, предписания которых будут выполняться. Хотя пришлось их подредактировать, чтобы соблюсти конфиденциальность клиента, ниже представлены эти заповеди.
1. Вы должны оказывать то же уважение, что и при устном общении.
2. Вы должны проверять правописание, грамматику и трижды перечитывать свое сообщение перед отправлением.
3. Вы не должны участвовать в рассылке посланий, пересылаемых по цепочке (чаще всего это письма религиозно-мистического содержания).
4. Вы не должны по собственной инициативе пересылать по произвольным адресам незатребованную информацию.
5. Вы не должны рассылатъ сообщения, которые являются зловредными, раздражающими или содержащими угрозы.
6. Вы не должны отправлять никаких сообщений противозаконного или неэтичного содержания.
7. Вы должны помнить, что электронное послание является эквивалентом почтовой открытки и не должно использоваться для пересылки секретной информации.
8. Вы не должны использовать широковещательные возможности электронной почты за исключением выпуска уместных объявлений.
9. Вы должны свести к минимуму количество электронных посланий личного характера.
10. Вы должны неукоснительно соблюдать правила и инструкции и помогать администраторам бороться с нарушителями правил.
Сообщения электронной почты являются эквивалентом
Сообщения электронной почты являются эквивалентом почтовых открыток. По этой причине требуются особые подходы при разработке правил безопасности электронной почты. При разработке правил безопасности электронной почты организация должна рассмотреть массу вопросов, начиная с архивного хранения и заканчивая инструкциями по оформлению содержимого посланий.
1. Правила использования электронной почты.
Правила должны быть разработаны так, чтобы они способствовали ответственному подходу при пользовании электронной почтой, которая способствует достижению целей организации и отвечает требованиям бизнеса.
Некоторые положения, которые необходимо включить в правила, касаются культуры пользования, содержания сообщений, общего отношения к электронной почте и подчинения правилам безопасности.
2. Администрирование электронной почты.
Правила, описывающие администрирование электронной почты, определяют действия организации при управлении системой электронной почты.
Правила администрирования должны устанавливать право сканирования сообщений, проходящих через систему электронной почты. Это сканирование может проводиться для поиска вирусов или проверки содержимого сообщений. Независимо от типа сканирования необходимо сформулировать правило, в котором говорится, что организация проводит сканирование.
Правила эксплуатации электронной почты могут включать в себя механизмы по ограничению размеров сообщений, чтобы не допустить перегрузки серверов и полосы пропускания сети.
Чтобы смягчить другие проблемы, организация может захотеть включить в правила положения, позволяющие использовать программы-посредники, шлюзы и другие средства поддержки пересылки сообщений. В этих правилах не должно быть указания на то, что сообщения фильтруются или сохраняются.
Если сообщения электронной почты архивируются, необходимо это отметить в правиле, в котором будут отражены основные детали того, как будет проводиться архивирование. В данном правиле также должны быть обозначены сроки хранения и потенциальные исключения из правил.
3. Использование электронной почты для конфиденциального обмена информацией.
Правило обмена конфиденциальной информацией включает в себя предписание шифровать сообщения перед их пересылкой и "подписывать" их цифровыми подписями.
Правила шифрования фактически не относятся к правилам безопасности электронной почты. Поэтому в правила безопасности электронной почты должна быть включена формулировка, адресующая пользователя к предписаниям принятых в организации правил шифрования.
Шифрование электронной почты
Третьим вариантом является разработка правила, требующего шифровать перед отправлением конфиденциальную и патентованную информацию. Зашифрованное сообщение может быть прочитано только тем получателем, кому оно предназначено. Однако, использовать шифрование и оперировать им нужно обдуманно. Существует много вопросов, таких как распределение ключей, возврат ключей и ограничение пересылки ключей, которые выходят за рамки правил работы с электронной почтой. Несмотря на то, что правила шифрования будут рассмотрены позже (см. главу 9 "Шифрование"), в правила безопасности электронной почты можно включить формулировку, подобную следующей.
Патентованная информация, отправляемая сторонним пользователям, должна шифроваться перед отправлением. Использовать шифрование нужно, руководствуясь действующими в организации правилами шифрования информации.
Сканирование электронной почты
Последние несколько лет электронная почта использовалась для распространения вирусов в Internet. Для борьбы с такими проблемами многие администраторы устанавливают в своих сетях средства сканирования вирусов. Это может оказаться хорошим решением, но существует ли правило для установки таких средств? В нашем противоречивом мире могут и не разрешить что-то делать с информацией, извлеченной без разрешения, записанного в официальном документе.
Правила сканирования содержимого позволяют организации просматривать содержимое сообщений. По разным причинам некоторым организациям необходим контроль содержимого электронной почты, чтобы предотвращать проблемы или утечку конфиденциальной информации. Проблема заключается в том, что правила сканирования содержимого задевают этические проблемы. Ощущение такое, словно организация заглядывает через плечо пользователям, поскольку она им не доверяет. В некоторых организациях, которые создавали в коллективе "семейную" атмосферу, было заметно, что коллектив не одобряет эту практику. В других организациях это воспринималось как необходимое зло.
Решение заключается в составлении формулировки правил, которая позволит организации сканировать всю электронную почту с учетом целей, которые поставлены успешным проведением бизнеса. Если организация проводит сканирование в поисках вирусов или других проблем, то это должно быть оговорено в правилах. Независимо от правил, если организация приняла решение сканировать электронную почту, то должно быть что-то вроде открытого доступного документа, в котором разъясняется, с какой целью проводится сканирование.
Для проведения сканирования в поисках вирусов формулировка правил может быть следующей.
Организация должна сканировать каждое сообщение электронной почты, которое проходит через сервер, чтобы проверить его на наличие компьютерных вирусов, "червей" или других исполняемых файлов, которые представляют угрозу безопасности сети. Инфицированная электронная почта не должна доставляться пользователю.
Администраторы должны разработать процедуры обработки инфицированных сообщений электронной почты.
Для сканирования содержимого формулировка может быть такой.
Организация имеет право сканировать содержимое каждого сообщения электронной почты, которое проходит через ее серверы, на основе заранее установленных критериев. Если сообщение не соответствует критериям, то оно не должно доставляться полъзователю.
Администраторы должны разработать процедуры для обработки забракованных сообщений. Руководство должно располагать средствами для внедрения таких правил, включая, помимо всего прочего, дисциплинарные меры для пользователей или правовые санкции для лиц, не являющихся пользователями.
И, наконец, к любому разделу можно добавить следующее.
Организация должна сделать доступным перечень того, что будет сканироваться на сервере.
Введение права на контроль электронной почты
Самое распространенное приложение Internet может оказаться и самым опасным. Электронная почта может использоваться для пересылки секретных данных, оскорблений и создавать проблемы для службы безопасности. Все проблемы можно решить, если организация контролирует трафик электронной почты и содержимое посланий, а также архивирует сообщения, чтобы в будущем можно было разобраться в возникшей проблеме. Если в чем-то вы сомневаетесь, то необходимо проконсультироваться с юристом, чтобы выяснить, что законно, а что противопоказано в этой работе. Если этого не делать, то право на мониторинг, так же как весь режим работы электронной почты и архивирование сообщений пользователей, должно быть установлено правилами безопасности, а периодический просмотр электронной почты может быть основой контроля за их соблюдением.
Цель защиты
Некоторые организации понимают, что необходимо помнить о юридических проблемах, возникающих в результате работы программ сканирования информации на пользовательских системах. Многие же считают, что об этом не стоит беспокоиться, и в вашей организации могут никогда не узнать, насколько неправильно можно истолковывать правила, пока сами не столкнутся с данными проблемами (см. главу 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.
Один из способов решения этих проблем заключается в введении правил, которые требуют сканировать носители в специальной системе. Формулировка политики может быть следующей.
Пользователи, загружающие какие-либо данные или программы с внешнего носителя, должны перед загрузкой сканировать этот носитель на предмет наличия на нем вирусов.
и компьютеры, не только обходятся
Вирусы, "черви" и "троянские кони", которые инфицируют сети и компьютеры, не только обходятся организациям "в копеечку", но и снижают объем производства, который может в дальнейшем и не быть компенсирован. Правила защиты от вирусов могут устанавливать требование для всех пользователей защищать ценные данные организации.
1. Цель защиты.
Иногда из соображений, выдвинутых юридической практикой, в правила безопасности достаточно включить формулировку, устанавливающую только требование защиты от вирусов, причем средства защиты должны использоваться исключительно по своему назначению.
Другая формулировка должна включать указание пользователю использовать для антивирусной защиты только утвержденные средства и никакими действиями не препятствовать их применению.
2. Определение типа защиты от вирусов.
В правилах защиты от вирусов должен быть отражен подход к антивирусной защите, но необязательно сам программный продукт.
В правилах необходимо связать принцип сканирования с используемой для этого программой. Это делается для обеспечения полной открытости информации в случае судебных дел.
Для определения программы защиты от вирусов необходимо составить формулировку правил, охватывающую следующие вопросы:
подход к тестированию на вирусы;
проверка целостности системы;
проверка распределенных или автономных средств.
3. Правила эксплуатации стороннего программного обеспечения.
Несмотря на то, что это происходит довольно редко, все же бывают случаи, когда поставщики теряют бдительность и распространяют зараженные вирусом свои программы. Можно разработать правила, предписывающие особый режим эксплуатации стороннего программного обеспечения.
В правилах может быть предписано, чтобы стороннее программное обеспечение перед загрузкой их на другие системы устанавливалось на испытательную систему и проверялось.
4. Привлечение пользователей к защите от вирусов.
Организация не хочет, чтобы ее пользователи имели какое-то отношение к вирусам. Это может плохо повлиять на выполнение задач организации. Данные правила должны жестко требовать, чтобы пользователь не имел никакого отношения к вирусам.
Чтобы сделать формулировку правил более жесткой, в некоторых организациях добавляют в нее положение о дисциплинарных взысканиях, включающих увольнение и передачу дел правоохранительным органам.
Тестирование на вирусы
Предположим, что в организации приняли решение использовать распределенный подход для защиты от вирусов. (Размеры организации значения не имеют.) В качестве этапа выполнения программы закупается популярный антивирусный пакет, который будет установлен в каждой системе. Администраторы установят и сконфигурируют программное обеспечение, в котором будут программы, выполняющие непрерывное сканирование вирусов и обновляющие еженедельно с помощью предлагаемых поставщиком общедоступных услуг базу данных сигнатур вирусов. Формулировка правил может выглядеть следующим образом.
Антивирусное программное обеспечение должно устанавливаться и конфигурироваться во всех сетевых системах организации таким образом, чтобы гарантировать постоянное сканирование на предмет поиска вирусов, а также периодически обновляться по указанию администраторов.
Вирусы, "черви" и "троянские кони"
Не проходит и недели без слухов о новых вирусах, "червях" и "троянских конях", которые инфицировали сети или компьютеры. Решение этих проблем не только требует немалых денежных затрат, но и чревато снижением объема производства, который может в дальнейшем и не быть компенсирован. Несмотря на то, что эти проблемы в первую очередь влияют на определенный тип операционной системы и программное обеспечение определенного поставщика, не существует операционных систем, которые давали бы полную гарантию защищенности от вирусов. Следует помнить, что первый известный "червь" был запущен в 1988 году и предназначался для атаки систем Digital VAX и Sun System, работавших под управлением одной из версий UNIX.
При разработке правил безопасности в первую очередь необходимо определить цель такой защиты. Некоторые могут подумать, что это не обязательно, но только так можно определить требования, предъявляемые к разрабатываемым правилам, а также сделать их более эффективными. После этого в правилах, прежде чем обсуждать роль пользователей в реализации правил, необходимо определить, каким образом организация обеспечит защиту от вирусов (централизованно или локально), а также в правила следует включить руководства по эксплуатации заимствованного программного обеспечения.