AirSnort и компания - реальная угроза

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

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

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

Интересна точка зрения авторов данной утилиты - Блэйка Хегирли и Джереми Брюстля: "Да, AirSnort может быть использована в качестве инструмента взлома, но это и веский аргумент против заявленной безопасности WEP-шифрования". Авторы убеждены, что AirSnort докажет практически каждому, насколько незащищены беспроводные сети: "Мы чувствовали, единственный правильный путь - выпустить утилиту в свободное пользование. Обычному пользователю или сетевому администратору среднего уровня неочевидно, насколько уязвимо WEP-шифрование, но AirSnort призвана открыть людям глаза".

Это не голословное утверждение - AirSnort доступна в исходных текстах на веб-странице проекта, и любой, кто знаком с языком C, может убедиться, как просто проникнуть в беспроводную сеть.
С этой точки зрения Хегирли и Брюстль выглядят уже не злобными хакерами, а буквально создателями катализатора, призванного усилить безопасность 802.11b/g. Несмотря на *nix-корни AirSnort, в сети обнаружилась и откомпилированная для платформы Win32 версия, скриншот которой мы и приводим.

Инструмент для пассивной атаки - AirSnort

С 2001 года популярность беспроводных сетей значительно возросла, также возросло и количество различных утилит для проведения пассивных атак - к AirSnort добавилась WEPCrack, написанная на языке Perl, утилиты Aircrack, Kismet и WepLab. Их число не ограничивается вышеперечисленными, это лишь наиболее популярные инструменты для атаки Wi-Fi-сетей.

Более того, идет активная работа над портированием "взломщиков" на платформу Windows, что не может не настораживать.

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

Кстати, для успешного взлома Aircrack и WepLab требуется на порядок меньшее, чем AirSnort, количества пакетов - это уже не миллионы, а сотни тысяч. Убедительный довод, чтобы задуматься о методах противодействия.

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

Популярные методы активной атаки - повторное использование вектора инициализации и манипуляция битами.

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

Чем усилить безопасность беспроводной сети?

Как уже понятно, скрытие идентификатора SSID, ведение списка валидных MAC-адресов и использование WEP-шифрования обеспечивают не безопасность, а ее видимость - примерно как решетки на окнах, сделанные из пластилина. Путь один: найти методы, способные реально усложнить жизнь злоумышленникам, ведь, как известно, невзламываемых ключей не бывает, дело лишь во времени, требуемом для их вычисления.

На сегодняшний день разумными считаются три средства, дополняющие уже имеющиеся, - стандарты IEEE 802.1x, 802.11i и протокол WPA.

IEEE 802.1x применяется для авторизации, аутентификации и аккаунтинга пользователей, чтобы проверить возможность предоставления доступа к сети. В случае 802.1x используются уже динамические ключи шифрования, что является несомненным плюсом. 802.1х предназначен для работы со сторонними средствами, такими как сервер RADIUS (Remote Access Dial-In User Server) и протокол EAP (Extensive Authentication Protocol).

Сервер RADIUS - своего рода "проходная", вахтер на которой самостоятельно решает, пустить пользователя в сеть или нет. К чести некоторых производителей беспроводного доступа (например, D-Link и U.S. Robotics), возможность авторизации и аутентификации пользователя на сервере RADIUS с помощью 802.1х предусмотрена даже в достаточно старых устройствах стандарта 802.11b.

Средства 802.1x в точке доступа стандарта 802.11b

В настоящее время есть несколько популярных реализаций RADIUS-серверов: FreeRadius, GNU Radius, Cistron Radius, Radiator Radius, Microsoft IAS, Advanced Radius. Некоторые из них - коммерческие продукты, некоторые - доступны для бесплатного использования с соблюдением соответствующих лицензионных требований.

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

Наконец, аккаунтинг - журналирование использования сетевых ресурсов и сервисов.

В общем случае алгоритм привязки RADIUS-сервера к беспроводной сети может быть таков:

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

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

Кстати, до сих пор удачных попыток взлома 802.1х не зафиксировано, поэтому развитие идет, безусловно, в верном направлении.

В качестве дополнения к неубедительному протоколу WEP имеется WPA - Wi-Fi Protected Access. WPA реализует принцип временных ключей шифрования и тесно взаимодействует с TKIP - Temporal Key Integrity Protocol (протокол целостности временных ключей). WPA работает в связке с 802.1х и EAP и совместим с последним из компонент всего комплекса безопасности - протоколом 802.11i.

802.11i предусмотрен в качестве глобальной замены WEP (его иногда называют также WPA2). 802.11i является как бы "надмножеством" WPA - сочетает все его возможности со своими оригинальными. 802.11i использует гораздо более мощный, нежели RC4 у WEP, алгоритм шифрования - это AES (Advanced Encryption Standart).



В действительности построить хорошо защищенную сеть можно и при помощи уже имеющихся средств - даже несмотря на WEP, SSID broadcasting и MAC-доступ. Хорошо зарекомендовавшее себя решение - Virtual Private Network, виртуальная частная сеть, в которую можно "завернуть" всю беспроводную сеть вместе с ее огрехами в области безопасности. Средства VPN работают на глобальном сетевом уровне, поэтому, видимо, в настоящее время это один из немногих способов обеспечения достойной безопасности - благо технология IPSec портирована с IPv6 на IPv4.

Об этом, кстати, упоминают и известные нам разработчики AirSnort Хегирли и Брюстль: "Мы можем посоветовать сетевым пользователям обратить внимание на методы шифрования "точка-точка", виртуальные частные сети, для шифрования трафика от вашего ноутбука до сервера".

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

MAC-аутентификация

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

Кстати, аутентификация беспроводного клиента по MAC-адресу - исключительно инициатива конкретного производителя, спецификации беспроводных стандартов 802.11b/g такой меры безопасности не предусматривают. То есть подобный метод аутентификации может либо присутствовать, либо нет, - в зависимости от желания и маркетинговой политики производителя.

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

Миф о WEP-шифровании

Одной из наиболее действенных мер по защите беспроводной сети от несанкционированного вторжения принято считать WEP-шифрование трафика. WEP (Wired Equivalence Privacy) представляет собой статический ключ длиной 64 или 128 бит, при помощи которого шифруется вся информация между точкой доступа и беспроводными клиентами в случае Infrastructure-организации сети или между клиентами при Ad-Hoc-организации.

Шифрование базируется на алгоритме RC4. Правда, профессионалы от IT-безопасности не питают к нему особого доверия, поскольку он легко поддается взлому. Да и с WEP-шифрованием все далеко неоднозначно - и при 64-, и при 128-битном ключе имеет место некоторая условность. Дело в том, что эффективная длина ключа в первом случае составляет 40 бит, а во втором - 104 бит. Недостающие до заявленных служебные 24 бит используются для дешифрования информации на принимающей стороне. Таким образом, числа "64" и "128" хороши лишь для пресс-релизов, а не для реальной безопасности. Кроме того, не будем забывать, что ключи являются статическими - а значит, их нужно периодически менять. Если для беспроводной сети, состоящей из точки доступа и трех клиентов, это не представляет особой проблемы, то для корпоративных сетей с сотнями беспроводных пользователей данное решение явно не подходит. Более того, для обеспечения достаточного уровня безопасности при использовании WEP-шифрования требуется смена 64-битного ключа раз в полчаса, а 128-битного - раз в час (в реальности часто ключи прописывают раз и навсегда, не мудрствуя лукаво). Налицо практическое применение сизифова труда.

Однако это трудности, лежащие на поверхности. Какие же методы сегодня предпочитаются при взломе WEP? Прежде всего, анализ "подслушанного" трафика утилитами AirSnort и WEPCrack (поиск в Интернете при помощи www.google.com выдает домашние страницы обоих проектов в первой же строчке). Для того чтобы читатель реально представлял себе степень защиты (или беззащитности) беспроводной сети, приведем следующие цифры: при анализе беспроводного трафика на расшифровку 128-битного ключа (на самом деле он 104-битный) при помощи AirSnort уходит всего 2-4 часа.

Проблемы безопасности в беспроводных сетях

Евгений Патий,

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

Существует мнение, что пренебрежение проблемами несанкционированного доступа вызвано некоторой инерционностью внедрения беспроводных технологий. Если еще год-два назад термин "Wi-Fi" можно было встретить достаточно редко, в основном в пресс-релизах и специализированных обзорах, то сейчас семейство стандартов 802.11b/g активно используется на "бытовом" уровне - публичные беспроводные сети функционируют во множестве мест, начиная от ресторанов и заканчивая залами ожидания аэропортов и гостиницами. Кроме того, пользователя плавно подвели к мысли, что без Wi-Fi жизнь нельзя считать полноценной, поэтому так широк выбор различных устройств, поддерживающих 802.11b/g - ничего другого, фактически, не остается.

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

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

Широковещательная передача SSID

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

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

В действительности же запрещение трансляции SSID нисколько не способствует увеличению "атакоустойчивости". Такой шаг способен привести лишь к появлению потенциальных проблем у подключаемых клиентов, поскольку конфигурирование сети становится гораздо менее гибким. Отключение широковещательной передачи SSID создает иллюзию надежности: ведь значение этого идентификатора все равно можно подслушать - оно находится во фреймах Probe Response. В любом случае беспроводная точка доступа - потенциальный источник угрозы, так как опытный пользователь, имеющий в арсенале ноутбук с беспроводным адаптером и необходимый минимум знаний, достаточно короткий срок может стать полноценным участником корпоративной сети со всеми вытекающими последствиями. Естественно, речь идет о преодолении стандартных препятствий, предусмотренных спецификациями стандартов 802.11b/g и инициативой производителя.

Веб-конфигурирование точки доступа

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

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

Зачем взламывать беспроводную сеть

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

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

Каковы же наиболее популярные средства защиты беспроводных сетей из тех, что предоставляют производители оборудования уровня SOHO? Их три:

Разграничение доступа, основанное на MAC-аутентификации. Запрет широковещательной передачи идентификатора SSID. 64- и 128-битное WEP-шифрование трафика.

Методические основы защиты информационных активов компании

Сергей ПЕТРЕНКО

В последнее время в разных странах появилось новое поколение стандартов в области защиты информации, посвященных практическим вопросам управления информационной безопасности компании. Это прежде всего международные и национальные стандарты управления информационной безопасностью ISO 15408, ISO 17799 (BS7799), BSI; стандарты аудита информационных систем и информационной безопасности COBIT, SAC, COSO, SAS 78/94 и некоторые другие, аналогичные им. Насколько рекомендации перечисленных стандартов безопасности могут быть полезны для защиты информационных активов отечественных компаний? Давайте посмотрим вместе.

История вопроса

В соответствие с международными и национальными стандартами ISO 15408, ISO 17799 (BS7799), BSI; COBIT, SAC, COSO, SAS 78/94 обеспечение информационной безопасности в любой компании предполагает следующее. Во-первых, определение целей обеспечения информационной безопасности компьютерных систем. Во-вторых, создание эффективной системы управления информационной безопасностью. В третьих, расчет совокупности детализированных не только качественных, но и количественных показателей для оценки соответствия информационной безопасности заявленным целям. В четвертых, применение инструментария обеспечения информационной безопасности и оценки ее текущего состояния. В пятых, использование методик кправления безопасностью с обоснованной системой метрик и мер обеспечения информационной безопасности, позволяющих объективно оценить защищенность информационных активов и управлять информационной безопасностью компании.

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

Международный стандарт ISO 15408

Следуя по пути интеграции, в 1990 г. Международная организация по стандартизации (ISO) и Международная электротехническая комиссия (ТЕС) составили специализированную систему мировой стандартизации, a ISO начала создавать международные стандарты по критериям оценки безопасности информационных технологий для общего использования, названные Common Criteria for Information Technology Security Evaluation или просто Common Criteria.
В их разработке участвовали: Национальный институт стандартов и технологии и Агентство национальной безопасности (США), Учреждение безопасности коммуникаций (Канада), Агентство информационной безопасности (Германия), Агентство национальной безопасности коммуникаций (Нидерланды), Органы исполнения программы безопасности и сертификации ИТ (Англия), Центр обеспечения безопасности систем (Франция).

В дальнейшем "Общие критерии" неоднократно редактировались. В результате 8 июня 1999 года был утвержден Международный стандарт ISO/IEC 15408 под названием "Общие критерии оценки безопасности информационных технологий" (ОК).



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



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

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

Вместе с тем в ОК главное внимание уделено защите от несанкционированного доступа (НСД). Модификации или потери доступа к информации в результате случайных или преднамеренных действий и ряд других аспектов информационной безопасности остался не рассмотренным.


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

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

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

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

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

Избежать жесткой классификации ИТ по уровню безопасности.

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

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

Задание по безопасности – это полная комбинация требований, являющихся необходимыми для создания и оценки ИБ конкретной системы или продукта ИТ.





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



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

Предлагаемые адаптированные ОК содержат две категории требований: функциональные и требования гарантированности.

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

4. Охватить весь жизненный цикл ИТ, начиная от формирования целей и требований обеспечения безопасности и кончая поставкой и наладкой ИТ на конкретном объекте.

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

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

6. Обеспечить комплексность подхода к обеспечению безопасности ИТ.

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


Здесь предусматриваются следующие уровни рассмотрения безопасности ИТ:

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

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

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

спецификации безопасности (проектное представление механизмов безопасности, реализация которых гарантирует выполнение требований безопасности);

разработка (реализация механизмов безопасности со спецификациями).

7. Обеспечение комплексности оценки безопасности ИТ.

Адаптация ОК позволяет оценивать безопасность ИТ в процессе их разработки на наиболее важных этапах. Предусмотрены следующие стадии оценки:

профиля защиты;

задания по безопасности;

реализованных механизмов безопасности.

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

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

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



8. Предусмотреть расширяемость требований к безопасности ИТ.

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

Интересно отметить, что в настоящее время Европейской ассоциацией производителей компьютерной техники ЕСМА уже проводятся проекты по разработке стандарта "Расширенный коммерческий функциональный класс оценки безопасности (E-COFC)". В этом документе принятый в 1993 г. стандарт ЕСМА-205 "Коммерческий функциональный класс оценки безопасности (COFC)" перерабатывается в соответствии с требованиями и терминологией ОК.

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



Стандарты ISO/IEC 17799:2002 (BS 7799:2000)



В настоящее время Международный стандарт ISO/IEC 17799:2000 (BS 7799-1:2000) “Управление информационной безопасностью – Информационные технологии. - Information technology- Information security management” является наиболее известным стандартом в области защиты информации. Данный стандарт был разработан на основе первой части Британского стандарта BS 7799-1:1995 "Практические рекомендации по управлению информационной безопасностью - Information security management – Part 1: Code of practice for information security management” и относится к новому поколению стандартов информационной безопасности компьютерных информационных систем. Текущая версия стандарта ISO/IEC 17799:2000 (BS 7799-1:2000) рассматривает следующие актуальные вопросы обеспечения информационной безопасности организаций и предприятий:

Необходимость обеспечения информационной безопасности

Основные понятия и определения информационной безопасности

Политика информационной безопасности компании

Организация информационной безопасности на предприятии



Классификация и управление корпоративными нформационными ресурсами

Кадровый менеджмент и информационная безопасность

Физическая безопасность

Администрирование безопасности корпоративных информационных систем

Управление доступом

Требования по безопасности к корпоративным информационным системам в ходе их разработки, эксплуатации и сопровождения

Управление бизнес-процессами компании с точки зрения информационной безопасности

Внутренний аудит информационной безопасности компании

Вторая часть стандарта BS 7799-2:2000 "Спецификации систем управления информационной безопасностью - Information security management – Part 2: Specification for information security management systems”, определяет возможные функциональные спецификации корпоративных систем управления информационной безопасностью с точки зрения их проверки на соответствие требованиям первой части данного стандарта. В соответствии с положениями этого стандарта также регламентируется процедура аудита информационных корпоративных систем.

Дополнительные рекомендации для управления информационной безопасностью содержат руководства Британского института стандартов - British Standards Institution(BSI) , изданные в период 1995-2003 в виде следующей серии:

Введение в проблему управления информационной безопасности -Information security managment: an introduction

Возможности сертификации на требования стандарта BS 7799 -Preparing for BS 7799 sertification

Руководство BS 7799 по оценке и управлению рисками -Guide to BS 7799 risk assessment and risk management

Готовы ли вы к аудиту на требования стандарта BS 7799-Are you ready for a BS 7799 audit?

Руководство для проведения аудита на требования стандарта -BS 7799Guide to BS 7799 auditing

Практические рекомендации по управлению безопасностью информационных технологий -Code of practice for IT management

Сегодня общими вопросами управления информационной безопасности компаний и организаций, а также развитием аудита безопасности на требования стандарта BS 7799 занимаются международный комитет Joint Technical Committee ISO/IEC JTC 1 совместно с Британским Институтом Стандартов- British Standards Institution(BSI) - (www.bsi-global.com), и в частности служба UKAS (United Kingdom Accredited Service).


Названная служба производит аккредитацию организаций на право аудита информационной безопасностью в соответствии со стандартом ВS ISO/IEC 7799:2000 (BS 7799-1:2000). Сертификаты, выданные этими органами, признаются во многих странах.

Отметим, что в случае сертификации компании по стандартам ISO 9001 или ISO 9002 стандарт ВS ISO/IEC 7799:2000 (BS 7799-1:2000) разрешает совместить сертификацию системы информационной безопасности с сертификацией на соответствие стандартам ISO 9001 или 9002 как на первоначальном этапе, так и при контрольных проверках. Для этого необходимо выполнить условие участия в совмещенной сертификации зарегистрированного аудитора по стандарту ВS ISO/IEC 7799:2000 (BS 7799-1:2000). При этом в планах совместного тестирования должно быть четко указаны процедуры проверки системы информационной безопасности, а сертифицирующие органы должны гарантировать тщательность проверки информационной безопасности.

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

Ниже в табл. 1 приведено сравнение содержания стандартов ISO 17799 (BS 7799) разных версий и ISO 9001, в котором рассматривается близкий круг вопросов управления информационной безопасностью.

Таблица 1.



Германский стандарт BSI



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


Это руководство представляет собой гипертекстовый электронный учебник объемом примерно 4 МБ (в формате HTML). Общая структура германского стандарта BSI приведена на рис 1.

Рис 1

В германском стандарте BSI представлены:

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

Описания компонентов современных информационных технологий:

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

Характеристики объектов информатизации (здания, помещения, кабельные сети, контролируемые зоны).

Характеристики основных информационных активов компании (в том числе аппаратное и программное обеспечение, например рабочие станции и сервера под управлением операционных систем семейства DOS, Windows и UNIX).

Характеристики компьютерных сетей на основе различных сетевых технологий, например сети Novell NetWare, сети UNIX  и Windows).

Характеристика активного и пассивного телекоммуникационного оборудования ведущих вендоров, например Cisco Systems.

Подробные каталоги угроз безопасности и мер контроля (более 600 наименований в каждом каталоге).

Существенно, что вопросы защиты приведенных информационных активов компании рассматриваются по определенному сценарию: общее описание информационного актива компании - возможные угрозы и уязвимости безопасности -возможные меры и средства контроля и защиты. С версиями этого стандарта на немецком и английском языках можно познакомиться подробнее на Web-сервере BSI (www.bci.de).



Стандарт COBIT 3rd Edition



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


таблицу 2) .

Таблица 2.

Ассоциация ISACA, в отличие от других, занимается открытым аудитом информационных систем. Она основана в 1969 году и в настоящее время объединяет более 23000 членов из более чем 100 стран, в том числе и России. Ассоциация ISACA координирует деятельность более чем 26000 аудиторов информационных систем (CICA — Certified Information System Auditor), имеет свою систему стандартов в этой области, ведет исследовательские работы, занимается подготовкой кадров, проводит конференции.

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

По заявлениям руководящих органов ISACA основная цель ассоциации – исследование, разработка, публикация и продвижение стандартизованного набора документов по управлению информационной технологией для ежедневного использования администраторами и аудиторами информационных систем. В интересах профессиональных аудиторов, руководителей информационных систем, администраторов и всех заинтересованных лиц ассоциация развивает свою концепцию управления информационными технологиями в соответствии с требованиями информационной безопасности. На основе этой концепции описываются элементы информационной технологии, даются рекомендации по компании управления и обеспечению режима информационной безопасности. Концепция изложена в документе под названием COBIT 3rd Edition (Control Objectives for Information and related Technology), который состоит из четырех частей.

Часть № 1: Краткое описание концепции (Executive Summary).

Часть № 2: Определения и основные понятия (Framework). Помимо требований и основных понятий в этой части сформулированы требования к ним.

Часть № 3: Спецификации управляющих процессов и возможный инструментарий (Control Objectives).

Часть № 4: Рекомендации по выполнению аудита компьютерных информационных систем (Audit Guidelines).



Третья часть этого документа в некотором смысле аналогична международному стандарту ВS ISO/IEC 7799:2000 (BS 7799-1:2000). Примерно также подробно приведены практические рекомендации по управлению информационной безопасностью, но модели систем управления в сравниваемых стандартах сильно различаются. Стандарт COBIT (Control Objectives for Information and related Technology - контрольные объекты информационной технологии) – пакет открытых документов, первое издание которого было опубликовано в 1996 году.

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

Рис.2.



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

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





Рис. 3.





Российская специфика



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

В противоположность германскому стандарту BSI, предоставляющему возможность использовать конкретные “частные” сценарии защиты информационных активов компании, стандарты ISO 15408, ISO 17799 и COBIT позволяют рассмотреть только наиболее общие принципы управления информационной безопасностью, характерные для процессов защиты информации в целом. Однако названные подходы обладают определенными ограничениями. Ограничением германского стандарта BSI является невозможность распространить рекомендации этого стандарта на защиту информационных активов российских компаний, которые отличаются по своей структуре и специфике бизнес деятельности от ранее рассмотренных примеров организации режима информационной безопасности. Ограничением стандартов ISO 17799 и COBIT является трудность перехода от общих принципов и вопросов защиты информации к частным практическим процессам обеспечения информационной безопасности в российских компаниях. Основная причина этого заключается в том, что защита информационных активов любой российской компании дополнительно характеризуется определенными индивидуальными специфическими условиями бизнес деятельности в условиях ограничений и регулирования российской нормативной базы в области защиты информации. Другими словами, только совместно используя сильные стороны рассмотренных международных стандартов, а также адаптировав полученные рекомендации в соответствии с требованиями российской нормативной базы в области защиты информации можно эффективно обеспечить защиту информационных активов конкретной российской компании.

Системный процесс проверки на соответствие

 





COBIT



SAC



COSO



SAS 78/94





Целевая аудитория



TOP-менеджеры, пользователи, аудиторы информационных систем



Внутренние аудиторы компании



TOP-менеджеры



Внешние аудиторы





Под аудитом понимается



Системный процесс проверки на соответствие декларируемым целям политики безопасности,

Организацию обработки данных, норм эксплуатации



Системный процесс проверки на соответствие декларируемым целям бизнес-процессов, политики безопасности и кадровой политики



Системный процесс проверки на соответствие декларируемым целям бизнесс-процессов, а также политики безопасности компании.



Системный процесс проверки на соответствие декларируемым целям бизнесс-процессов, а также политики безопасности компании.





Цели аудита



Развитие бизнеса, повышение его эффективности и рентабельности, следование нормативно-правой базы



Развитие бизнеса, финансовый контроль, следование нормативно-правой базы



Развитие бизнеса, финансовый контроль, следование нормативно-правой базы



Развитие бизнеса, финансовый контроль, следование нормативно-правой базы





Область применения



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



Управление производством, эксплуатация автоматизированных и автоматических систем управления



Управление производством, риск-менеджмент, управление информационными системами, мониторинг корпоративных информационных систем



Управление производством, управление рисками, мониторинг и управление корпоративными информационными системами





Акцент



Информационный менеджмент



Информационный менеджмент



Менеджмент



Финансовый менеджмент





Срок действия сертификата аудита



интервал времени



Время проверки



интервал времени



Интервал времени





Заинтересованные лица



TOP-менеджеры компании



TOP-менеджеры компании



TOP-менеджеры компании



TOP-менеджеры компании





Объем документов, регламентирующих проведение аудита



4 документа общим объемом 187 страниц



12 частей общим объемом 1193 страниц



4 тома общим объемом 353 страниц


>

А как же СБ?!

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

Читинг - это способ "удовлетворить" СБ, не модифицируя его код. Для того чтобы СБ начислял вам деньги, вы должны просматривать веб-страницы. На техническом уровне это значит, что на первом плане у вас должен находиться Internet Explorer или Netscape Navigator (Opera почему-то не поддерживается), вы должны периодически переходить с сайта на сайт и время от времени шевелить мышкой. Переходы с сайта на сайт регистрируются путем DDE-нотификаций: можно посылать их СБ в обход настоящего браузера. Нажатия мышки регистрируются установкой глобального хука на функцию в DLL (что самой Майкрософт вообще-то не рекомендуется).

Существует 1000+1 программа "накрутки" СБ именно через читинг, но все они ловятся и выкупаются так или иначе - сразу или со временем. В частности, не вредно будет знать, что СБ может загружать "антихакерские" модули, число которых постоянно растет.

Патч - это метод взлома оригинального бинарного кода. Хочется сказать, что СБ.exe только этого и ждет, то есть весь код просто-таки нашпигован разнообразными проверками. В частности, проверяются контрольные суммы (по частям файла, а не целиком, так что "исправить" CRC не удастся) самой exe, dll, вычисляются и проверяются дайджесты и хеш-значения ресурсных строк (например, команд протокола и заголовки браузеров). К тому же, существует, по крайней мере, несколько runtime-проверок на работу под управлением (под отладкой) и дополнительно - та же возможность загружать модули для выполнения. Все это можно отключить, но я бы никогда не рискнул утверждать, что не осталось еще одной проверки.

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

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

Для кодирования в СБ используется два метода: первый - "сжимающий" алгоритм - кодирует текстовые строки в другие текстовые строки. Этот метод кодирования условно можно назвать x2. Поскольку x2 строит упорядоченные бинарные деревья, то найти его можно, поискав вызовы функции qsort.

Кроме того, в уже декодированной строке есть два комплиментарных дайджеста (aid и bid) - 11-байтных хеша, основанных на идентификаторе пользователя и текущем системном времени. (aid,bid)=function (id,time ()). Поскольку все кодировки в СБ основаны на случайных числах, которые инициализируются srand (time ()), то вызов srand () в начале функции безошибочно покажет вам, где идет кодирование или создание дайджестов. Справедливости ради отметим, что, кроме x2 кодировки и создания aid-bid дайджестов, в программе есть еще пару кодировок - в частности, для шифрования файла настроек.

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

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

Архитектура

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

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

С другой стороны, несколько однопроходных модулей, вызываемых последовательно и соединенных через программные каналы, предоставят ту же производительность при значительно более простом коде. Так мы и сделаем - будем иметь дело с несколькими однопроходными операциями, каждая из которых достаточно проста, чтобы уместиться на одном экране текстового редактора. Поскольку наши "подпрограммы" нужно вызывать в определенном порядке, будем нумеровать файлы подобно тому, как раньше нумеровали строки в qbasic (например, 5,10,20,30 и т.д.),- в случае чего можно вставить в последовательность пару новых элементов, и при этом будет ясно, что за чем идет.

Командный файл для запуска будет примерно таким:

perl -n 1.pl СБ.asm | perl -n 2.pl | perl -n 3.pl 1>СБ.out

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

print;

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

Такое поведение, вообще говоря, позволяет делать более сложные вещи, но мы хотим поддерживать код настолько простым, насколько это возможно. В идеале порядок проходов совершенно не должен иметь значения, но неявно мы все время будем использовать зависимости - поскольку от перестановки проходов производительность будет меняться в диапазоне от "отлично" до "неприемлемо". Например, после замены всех "white spaces" на единичные пробелы мы можем везде вместо "\s+" использовать " ", что значительно проще для regexp-движка, и так далее.

Бесполезный Perl и общая теория улучшения мира

Арсений Чеботарев,

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

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

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

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

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

Третий мотив - уже совсем реальный - это собственно "evaluation purposes". Постоянное созерцание кода, ковыряние во всяком бинарном хламе - от ассемблера до псевдокода Java - сделает из вас законченного Code Warriora'а и, помимо прочего, поможет писать быстрые, надежные и безопасные программы.

Цели чрезвычайного Плана Отдела Информационных технологий

Целями чрезвычайного Плана Отдела Информационных технологий являются:

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

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

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

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

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

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

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

Допущения Плана Отдела Информационных технологий

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

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

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

Функциональная безопасность программных средств

В.В Липаев (профессор, доктор технических наук)

Информационный бюллетень "Jet Info 08(135)/2004"

СОДЕРЖАНИЕ

Об авторе: окончил физический факультет МГУ, доктор технических наук, профессор, главный научный сотрудник Института системного программирования РАН. Длительное время работал в Московском НИИ приборной автоматики, в последние годы - Главным конструктором и председателем Координационного совета Министерства радиопромышленности СССР по автоматизации проектирования программного обеспечения, руководителем комплексного проекта ПРОМЕТЕЙ по разработке автоматизированных технологий создания крупномасштабных программных средств для систем реального времени. Автор более тридцати монографий и методических руководств, а также 250 оригинальных статей и изобретений.

Граничные условия, вход/выход, etc.

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

Итак, есть исполняемый файл для Windows, написанный на C++/MFC (предположительно - в формате PE). Если он был сжат/закодирован, будем считать, что эта часть проблемы уже решена: сжатие/кодировка - это отдельная тема, для которой имеется свой инструментарий, а в Сети существуют даже специализированные ресурсы по этому вопросу.

Для того чтобы разговор был предметным, возьмем очень известную в Сети программу (условно назовем ее СБ). Эта программа известна всем, кто пытался получить деньги за серфинг. Причин для такого выбора несколько: во-первых, она представляет собой хороший пример "кристально чистого" кода MFC без каких-либо методов шифрования самого кода. С другой стороны - это весьма интересный freeware-код для взлома, (по вполне понятным причинам коммерческие программы мы с вами ломать не станем).

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

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

Итак, есть наша программа - СБ.exe. Пропускаем ее через IDA и получаем огромный листинг СБ.asm. То, что перед нами C++/MFC, вне сомнений; но пока мы видим просто текст на ассемблере, причем размер его составляет около 30Мб.
Работать с ним неудобно, а некоторые текстовые редакторы вообще виснут (тот же F4 в Far, например). Кроме того, нам видно много лишних деталей: технические комментарии, код пролога и эпилога функций, передача параметров по push и т.д. Короче говоря, полученный текст приблизительно в 10-20 раз длиннее, чем нам нужно для понимания и реставрации алгоритмов программы.

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

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

Информационная безопасность - статьи, обзоры, книги

Информационный бюллетень JET INFO

Обзор подготовлен по материалам учебного курса "Основы информационной безопасности" доктора физ.-мат. наук, заведующего сектором в отделе информационной безопасности НИИ системных исследований РАН В.А. Галатенко

Анна Иванова,

Антон Разумов

Юрий Зырянов

Андрей Кадацкий

Анна Штейн, IDS Scheer Россия и страны СНГ

Борис Тоботрас, Дмитрий Михеев,

Андрей Коптелов, IDS Scheer Россия и страны СНГ

Иван Мелехин,

Алексей Доля

А. Щеглов, А. Оголюк

Алексей Доля

А.А. Грушо, Е.Е. Тимонина, Информационный бюллетень JET INFO

В.А. Галатенко, Информационный бюллетень JET INFO

Алексей Лукацкий, Cisco Systems

В.А.Галатенко, Информационный бюллетень JET INFO

,

Евгений Патий,

,

,

Денис Шергин,

Тестовая лаборатория Ferra

Евгений Патий,

Лекция из курса "Основы информационной безопасности"

В.А.Галатенко, INTUIT.ru

Михаил Савельев, компания

Николас Петрели, Информационный бюллетень Jet Info

Сергей Монин, REDCENTER

, Игорь Васильевич Шестак, Украинский Государственный Университет информационно-коммуникационных технологий

Михаил Савельев,

Михаил Савельев,

Евгений Патий,

Евгений Патий,

Алексей Лукацкий,

Александр Безмалый,

. Глава из книги "IT-безопасность. Стоит ли рисковать корпорацией?"

Линда Маккарти

Лев Фисенко

, #06/2005

Евгений Патий, #6/2005

Александр Веселов,

Лидия Сирота,

, www.security.ukrnet.net

В.В Липаев, Jet Info Online #08(135)/2004

В.В Липаев, Jet Info Online #03(130)/2004

Марк Кобзарь, Алексей Сидак, №6 2004

Елена Полонская,

Алексей Кошкин, Наталья Кошкина, Королевство Delphi

Лилия Козленко, 3'2002

Лукацкий А.В., , опубликовано в журнале BYTE #10/2003

Константин Виноградов, Лилия Виноградова,

Константин Виноградов,

Сергей Петренко, Сергей Симонов, журнал "IT Manager" #15(3)/2004

Елена Полонская,

Елена Полонская,

Елена Полонская,

Арсений Чеботарев,

Олег Сыч,

,

Б.Д. Альтерман, В.И.
Дрожжинов, Г.Е. Моисеенко, №5 2003



Б.Д. Альтерман, В.И. Дрожжинов, Г.Е. Моисеенко, №8 2003


, IT Manager #12/2003


В. А. Васенин. Доклад на конференции "Математика и безопасность информационных технологий" (МаБИТ-03, МГУ, 23-24 октября 2003 г.)
Доклад был опубликован на сайте Cryptography.Ru


Юрий Мельников, Алексей Теренин
Статья была опубликована в журнале "Банковские технологии" и на сайте Cryptography.Ru


#2/2004


Сергей Петренко, Сергей Симонов, Роман Кислов, №10 2003


, опубликовано в Журнале сетевых решений LAN


, Научно-инженерное предприятие "Информзащита"
Опубликовано в журнале "Технологии и средства связи"



Александр Мурадян, руководитель направления "Эффективность IT", "Коминфо Консалтинг"

&laquoIT News&raquo, #1(2)/2004



, &laquoЭкспресс-Электроника&raquo, #1/2004



Опубликовано в журнале


, Научно-инженерное предприятие "Информзащита"
Опубликовано в журнале "Мир связи. Connect"


, Научно-инженерное предприятие "Информзащита"
Опубликовано в журнале "PCWeek/RE"


, Научно-инженерное предприятие "Информзащита"
Опубликовано в "PCWeek/RE"


, Научно-инженерное предприятие "Информзащита"
Опубликовано в журнале "Мобильные системы"


, опубликовано в журнале "Мобильные Системы"



, , ,
опубликовано на сайте



Казарин О.В.,



В.Б. Бетелин (член-корреспондент РАН), В.А. Галатенко, М.Т. Кобзарь, А.А. Сидак, И.А. Трифаленков,

бюллетень JET INFO



Беляев А.В., ЧФ СПбГТУ



, Труды 2002 г.



, Труды 2003 г.



,"Журнал Сетевых Решений LAN"



, журнал CODE





Крис Касперски, книга



Крис Касперски, книга




,


Сергей Петренко, Сергей Симонов, "IT Manager", #3/2003


Пол Инглэнд, Батлер Лэмпсон, Джон Манферделли, Маркус Пейнадо, Брайан Уиллман,


Криспин Кован,


Ольга Поликарпова,


Алексей Галатенко,


Сергей Петренко


Сергей Петренко


С.В. Вихорев, , В. М. Трушин, ООО "Дельный совет"


Сергей Петренко,


Илья Медведовский,


А. Березин,


Сергей Вихорев, Роман Кобцев, No.7-8/2002


С. В. Вихорев,



О. В. Генне, ООО "Конфидент" , No.3, 2000

Владимир Казеннов

ISO 17799 в России

В России стандарт ISO 17799 пока не является общепринятым документом, в отличии от стандартов ГТК и ФАПСИ. Однако стандарты ГТК на практике применяются обычно только к программным продуктам, стандарты ФАПСИ регламентируют, в основном, применение криптографических средств. Применение этих стандартов к системе управления информационной безопасности компании практически не возможно, так как сами стандарты предназначались, скорее, для программного обеспечения и сертифицировать всю ИТ систему компании на соответствие стандартам ГТК представляется достаточно сложным и не совсем неэффективным занятием.

Совершенно иным образом обстоят дела со стандартом ISO 17799. При всей своей обобщенности и отсутствии в некоторых частях стандарта конкретных деталей, сам стандарт разработан именно для применения его в сложных и разветвленных корпоративных системах и что не мало важно - ISO 17799 не противоречит существующим российским стандартам ГТК и ФАПСИ.

Критерии оценки защищенности информационных

Какой вопрос наиболее часто задают руководители высшего звена компании ИТ менеджерам и специалистам по информационной безопасности? Думаю, что это очевидно: "Насколько защищена наша информационная система?". Этот вопрос действительно является краеугольным камнем информационной безопасности и тем самым "тонким" местом, которое обычно стараются избегать секьюрити специалисты. И действительно оценить защищенность информационной системы достаточно сложно + но, как известно, можно. Для этого существуют, в основном, качественные методы оценки уровня защищенности, которые на выходе позволяют получить не количественную оценку ("система защищена на 4.2 балла или на 58%"), а качественную - система соответствует определенному классу или уровню защищенности. Количественные методы оценки на практике не нашли своего применения. Применение качественных методов оценки является на сегодняшний день единственным способом получить представление о реальном уровне защищенности информационных ресурсов компании.

Критерии проведения аудита безопасности информационных систем

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

Листинги и комментарии

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

Проход 05_stringer.pl - сборка строк:

01 if (m|db\s+..h\s+;\s+([0-9A-Za-z\@:\.\?/\-])|) { 02 $buff=(defined ($buff) && length ($buff)>0?"$buff$1":$1); 03} else { 04 if (length ($buff)) { 05 print (m/db\s+0/)?" db '$buff', 0\n":" db '$buff'\n$_"; 06 $buff=""; 07} else { 08 print; 09} 10}

Комментарий: IDA хорошо собирает строковые литералы и даже дает им осмысленные имена, но только в случае, если на строку есть ссылка. К сожалению, если этих ссылок нет, то строка так и остается "толпой одиноких байт". Приведенный выше код исправляет ситуацию: если встречается строка типа db 65h; A - мы начинаем накапливать строку в переменной $buff. Все последующие символы добавляются в строку, до тех пор пока не встретим что-то другое. "Что-то другое" может быть db 0 или нет - в первом случае мы предполагаем, что строка "закрывается" этим символом, и присоединяем его к строке. В противном случае наша программа выводит строку, за которой идет то, что распознано нами как не-строка (поз 05). Поскольку в следующем проходе мы будем "складывать" повторяющиеся db 0 в один dup, то удобнее будет заранее "сложить" строки, чтобы потом не приходилось выискивать db 0 в dup'ах. Это та причина, по которой данный проход имеет номер 05 - он был добавлен сюда позже.

Проход 10_squezee.pl, упаковка

01 if (!m/^\s*(;|$)/ &&!m/(align|assume|model|segment|p386n|public)/) { 02 s/\s+/ /g; 03 if (m/unexplored/) { 04 $unxcnt=($unxcnt?$unxcnt+1:1); 05} elsif (m/db 0/) { 06 $zeros=($zeros?$zeros+1:1); 07} else { 08 if ($unxcnt) {print " db $unxcnt dup (?)\n"; $unxcnt=0;} 09 elsif ($zeros) {print $zeros==1?" db 0\n":" db $zeros dup (0)\n"; $zeros=0;} 10 s/;....
XREF:.*$//; 11 s/0(FFFF)?FFFFh/-1/; 12 print $_,"\n"; 13} 14}

Комментарий: директивы в строке 01 имеют смысл только для ассемблера, для нас же они - мусор на 100%, так что просто игнорируем их. Строка 02 заменяет все "blank spaces" (то есть последовательности пробелов, табуляций и прочих "невидимок") одним пробелом. Возможно, это уменьшает читабельность, но она нам пока ни к чему. Следующий блок "скатывает" последовательности db 0 и db?. Первое вхождение такой строки начинает отсчет, и вся последовательность превращается в одну строку типа db 100 dup (?). Слово unexplored ничего нам не дает, так как? именно это и значит. Строка 10 "убивает" все перекрестные ссылки - поскольку у нас уже нет адресов в левой части листинга, то они тоже мало что дают. В строке 12 добавляется перевод строки к строкам, которые мы пропускаем без обработки, поскольку он тоже blank, и поэтому был удален в строке 02.

Проход 20_subrouter.pl, обработка определений функций:

01 if (!m/(mov esp, ebp|push ebp|mov ebp, esp|pop ebp|push e [sd] i|pop e [sd] i)/&&!m/^(var|arg)/) { 02 if (m/ proc /) { 03 s/^(.+) proc.*$/\n$1 {/; 04} 05 if ($retn) { 06 if (m/endp/) { 07 s|^(.+) endp|}|; 08} else {print "}\n";} 09} 10 $retn=m/retn/; 11 if (!$retn) {print;} 12}

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

Проход 30_caller.pl, обработка вызовов функций:



01 if (!m/add esp/) { 02 s/^ call (.+); (.+)$/ $3/; 03 s/ds://; 04 s/^ call (.+) / $1/; 05 print; 06}

Комментарий: первая строка отфильтровывает строки типа add esp, 10h - компилятор использует их только для коррекции после вызова функций из стандартных библиотек типа libc - и никак иначе. Команды call заменяются на комментарии от IDA в случае "хорошо известных" вызовов (эти комментарии нарочно не удалялись) или на имена функций нашей программы, если IDA нам ничего не подсказывает. В более полном варианте в этом же проходе можно "скатать" стек. При этом учитывается, какие переменные были помещены в стек перед вызовом, и вместо пачки push аргументы перечисляются в скобках.

Проход 40_reasm.pl, замена ассемблерных конструкций:

s/\[ebp\+(.+)\]/$1/; s/\]//; s/\[//; s/mov (.+), (.+)/$1=$2/; s/lea (.+), (.+)/$1=&$2/; s/xor (.+), $1/$1\=0/; s/sub (.+), (.+)/$1-=$2/; s/add (.+), (.+)/$1+=$2/; s/offset /*/; s/ptr //; s/short //; s/unknown_libname/lib/; print;

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

В этом месте мы уже достигли определенного прогресса: текст СБ.asm уменьшился ровно в 14 раз (с 28 Мб до 2 Мб), работать с ним стало приятно и полезно. Не хочу утомлять вас более сложным кодом - сейчас главное понять, как это делается, и почувствовать вкус к такого рода "улучшению мира".

Несколько лет назад Британский институт

Несколько лет назад Британский институт стандартов (BSI) при участии коммерческих организаций, таких как Shell, National Westminster Bank, Midland Bank, Unilever, British Telecommunications, Marks & Spencer, Logica и др. занялся разработкой стандарта информационной безопасности. И в 1998 г. был принят национальный стандарт BS 7799 управления информационной безопасностью организации вне зависимости от сферы деятельности компании. Служба безопасности, IT-отдел, руководство компании начинают работать согласно общему регламенту. Неважно, идет речь о защите бумажного документооборота или электронных данных. Британский стандарт BS 7799 поддерживается в 27 странах мира, в числе которых страны Британского Содружества, а также, например, Швеция и Нидерланды. В конце 2000 г. международный институт стандартов ISO на базе британского BS 7799 разработал и выпустил международный стандарт менеджмента безопасности ISO/IEC 17799.

Непрерывность бизнеса в нештатных ситуациях

Б.Д. Альтерман, В.И. Дрожжинов, Г.Е. Моисеенко
№8 2003

эксперт по информационной безопасности, исполнительный

Илья Медведовский, к.т.н., эксперт по информационной безопасности, исполнительный директор компании

Для получения сертификата соответствия ISO

Для получения сертификата соответствия ISO 17799 компания должна пройти аудит информационной безопасности, провести подготовку информационной системы на соответствие стандарту, внедрить изменения и провести окончательную проверку соответствия стандарту. Данную работу целесообразно разбить на несколько этапов. Предварительный этап, который заключается в проведении аудита и, на его основании, подготовки необходимых изменений системы управления информационной безопасностью, может выполнить специализированная секьюрити компания, имеющая опыт в проведение подобных работ. Затем, после подготовки комплекта необходимых документов и внесения изменений в систему, необходимо провести итоговую проверку соответствия ISO 17799, для чего требуется участие специалистов одной из консалтинговых компаний (KPMG и др.), которые владеют эксклюзивным правом выдачи данного сертификата и имеют аккредитацию при UKAS (United Kingdom Accreditation Service) - уполномоченном государственном органе Великобритании. Также, отметим, что в настоящее время официальная сертификация возможно только по BS7799 (до выхода 2-ой части ISO 17799, которая намечена на конец 2002 года).

Какие же преимущества получает компания,

Какие же преимущества получает компания, которая провела аудит безопасности своих информационных ресурсов и получила сертификат соответствия системы управления информационной безопасности по стандарту ISO 17799?

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

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

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

Среда обработки данных

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

Указатель чрезвычайного Плана Отдела Информационных технологий

ПЛАН ДЕЙСТВИЙ ПРИ КРУПНЫХ БЕДСТВИЯХ (КАТАСТРОФАХ) Обнаружение и реагирование Идентификация проблемы; уведомление руководства

Аварийные службы

Среда эксплуатации

Физическая безопасность

Уменьшение вероятности дополнительного ущерба

Отказ кондиционера воздуха

Процедуры при пожарной тревоге

Процедуры при отказе электрического питания

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

Эвакуация помещения Уведомление Группы управления в чрезвычайной ситуации Определение последовательности шагов, выполняемых на этапе обнаружения и реагирования Начало выполнения процедур по развертыванию резервного помещения Уведомление других групп Группой управления в чрезвычайной ситуации Создание Центра управления Начало деятельности Группы восстановления после бедствия и регистрация информации в Журнале регистрации действий по восстановлению после бедствия Полное восстановление деятельности в резервном помещении Обеспечение перемещения аппаратных средств, ПО и других ресурсов в резервное помещение; запуск и тестирование прикладных систем Обеспечение функционирования сети связи Контрольные перечни Группы восстановления после бедствия Восстановление производственных помещений и их функционирования в первоначальном и (или) резервном производственных помещениях. ГРУППЫ ВОССТАНОВЛЕНИЯ ДЕЯТЕЛЬНОСТИ ПОСЛЕ БЕДСТВИЯ Организационная структура Отдела информационных технологий Состав, функции и обязанности групп Координатор планирования на случай бедствий Группа управления в чрезвычайной ситуации Группа эксплуатации вычислительных систем

Эксплуатация компьютеровПодготовка помещенияЗамена оборудованияПодготовка "холодного" резервного помещенияОборудование, обеспечивающее функционирование компьютеровМатериалы Группа ввода и контроля ввода-вывода данных

Ввод данныхКонтроль данных Группа специальных проектов

Перевозка в резервные помещения и из них

Обучение

Административные услуги

Группа технической поддержки

Системное программное обеспечение

Сеть связи

Группа базы данных

Восстановление базы данных и обеспечение ее целостности Группа систем и программного обеспечения

Восстановление прикладных систем и возобновление их работы

Прикладные программы

Группа Отдела страхования

Страхование и компенсация за спасение имущества Группа Отдела внутреннего аудита Заблаговременное планирование и текущие функциональные обязанности групп Координатор планирования на случай бедствий Группа управления в чрезвычайной ситуации Группа эксплуатации вычислительных систем Группа ввода и контроля ввода-вывода данных Группа специальных проектов Группа технической поддержки Группа баз данных Группа систем и программного обеспечения Группа Отдела страхования Группа Отдела внутреннего аудита ПОСТАВЩИКИ Поставщики нового и бывшего в употреблении оборудования Поставщики программного обеспечения Поставщики средств связи Поставщики специального оборудования Поставщики вспомогательного офисного оборудования Поставщики специальных бланков УПОРЯДОЧЕНИЕ ВСЕХ ПРИКЛАДНЫХ СИСТЕМ ПО ПРИОРИТЕТАМ Ранжирование всех систем по приоритетам ЗАЩИТА НОСИТЕЛЕЙ ИНФОРМАЦИИ Защита и сохранение жизненно важных документов

Защита базы данных

Резервные копии базы данных

Обновления

Описание базы данных

Исходные тексты программного обеспечения



Стандартные процедуры создания резервных копий

Ежедневная обработка данных

Еженедельная обработка данных

Ежемесячная обработка данных

Ежегодная обработка данных

Циклы прикладных систем

Создание резервных копий дисков

Хранение вне производственного помещения Документация для систем и программ Резервные копии документации для ввода данных Создание резервных копий файлов персональных компьютеров Специальные бланки Процедуры для микрофишей ПРОЦЕДУРЫ ЭКСПЛУАТАЦИИ ПОМЕЩЕНИЯ, В КОТОРОМ НАХОДЯТСЯ КОМПЬЮТЕРЫ Процедуры включения питания Процедуры начальной загрузки Процедуры выключения питания Графики Регистрация вычислительных работ Operations Run-Books Ответственные за прикладные системы ОПЕРАЦИОННАЯ СИСТЕМА Операционная среда Список всех приобретенных пакетов программ Накопители на дисках и размещение файлов ФИЗИЧЕСКОЕ ОБЕСПЕЧЕНИЕ БЕЗОПАСНОСТИ И УПРАВЛЕНИЕ ДОСТУПОМ Персонал, обслуживающий компьютеры Персонал Отдела информационных технологий Специалисты по техническому обслуживанию и сопровождению Персонал других компаний Аппаратные средства Средства связи Прочее Управление доступом Контроль доступа в охраняемое помещение с бланками Доступ к хранилищу Нерабочее время Обязанности по обеспечению безопасности: охрана Обеспечение безопасности офиса ЗАЩИТА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Пароли на доступ к системам Сопровождение прикладных систем Ведение паролей РЕЗЕРВНЫЕ ПОМЕЩЕНИЯ Абонирование резервного помещения План помещения Техническое и программное обеспечение Средства связи Запасы материалов Испытания Первоначальное испытание Восстановление файлов и библиотек Испытание критически важных прикладных систем Испытание систем связи Имитация бедствий Испытания компиляции программ ВЗАИМНЫЕ СОГЛАШЕНИЯ ОБЪЕМ СТРАХОВОЙ ОТВЕТСТВЕННОСТИ Страхование обработки данных Страхование аппаратного обеспечения компьютеров Страхование от прерывания деятельности ВЕДЕНИЕ И ВЫПОЛНЕНИЕ ПЛАНА ВЕДЕНИЕ ПЛАНА ДЕЙСТВИЙ В НЕПРЕДВИДЕННЫХ ОБСТОЯТЕЛЬСТВАХ Обязанности координатора планирования на случай бедствий Обязанности руководителя группы КОНТРОЛЬНЫЙ ПЕРЕЧЕНЬ ДЛЯ ПЛАНИРОВАНИЯ НА СЛУЧАЙ БЕДСТВИЙ Общие сведения Вычислительный центр Ввод данных Контроль данных Помещение, в котором находятся компьютеры Библиотека резервных копий Системы и программирование Техническая поддержка Администрирование базы данных Внутренний аудит СтрахованиеРезервное помещениеВзаимные соглашения

---

---