Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
В Каталогах IT-Grundschutz рекомендуются стандартизованные меры безопасности ИТ для типичного офисного окружения. Но так как каждый офис имеет свои особенности, то меры безопасности ИТ должны быть адаптированы к ним. Они должны соответствовать защищаемым бизнес-процессам, обрабатываемой информации и используемым ИТ-системам и приложениям. Обзор используемых ИТ-приложений и систем поэтому важен, т.к. многие меры безопасности очень отличаются в зависимости от используемого ИТ-окружения.
На практике, критически важная для бизнеса информация и ИТ-приложения обычно определяются анализом бизнес-процессов и затем затронутые ИТ-системы документируются. Но в зависимости от ситуации, сначала может понадобиться задокументировать ИТ-системы, а затем ИТ-приложения, которые работают в них.
Даже когда используемый подход такой же, как описанный выше, обратное направление также очень рекомендуется: с одной стороны, проверка была выполнена на предмет, все ли системы ИТ задокументированы. Часто есть ИТ-системы, которые не были ранее отнесены ни к одному ИТ-приложению, т.к., напр., их важность не была известна владельцу информации. С другой стороны, целенаправленная проверка выполняется для ИТ-приложений, действительно установленных в ИТ-системах. Это определит, были ли пропущены критически важные приложения безопасности.
Анализ структуры ИТ используется для предварительного исследования информации, необходимой для дальнейшего подхода к разработке концепции безопасности ИТ в соответствии с IT-Grundschutz. Он делится на следующие подзадачи:
• Исследование плана сети;
• Сбор информации об ИТ-системах;
• Сбор информации об ИТ-приложениях и относящихся к ним данных;
• Сбор информации об участках ИТ;
• Упрощение с помощью выделения в группы сходных ресурсов.
Эти подзадачи описаны ниже и поясняются с помощью примера. Подробный вариант примера можно найти во вспомогательных материалах IT-Grundschutz.
Анализ плана сети
План сети (напр., в форме топологического плана сети) может быть полезной отправной точкой для анализа структуры ИТ. План сети – графическое представление компонент, используемых в ИТ и рассматриваемые коммуникационные технологии, а также способ их объединения в сеть. План должен отображать следующие объекты:
• ИТ-системы, т.е. клиентские и серверные компьютеры, активные сетевые компоненты (такие как концентраторы, коммутаторы, маршрутизаторы, точки доступа в беспроводную ЛВС), сетевые принтеры и т.д.;
• Сетевые соединения между этими системами, т.е. ЛВС соединения (такие как Ethernet, token ring), беспроводные ЛВС, базовые технологии (FDDI, ATM) и т.д.;
• Соединения между рассматриваемыми областями и внешним миром, т.е. dial-in доступ через ISDN или модем, Интернет-соединения с использованием аналоговых технологий или маршрутизаторов, радиоканалов или выделенных линий для удаленных зданий или узлов, и т.д.
Кроме того, для каждого из представленных объектов, должен быть минимальный набор данных, которые можно получить из определенного каталога. Как минимум, следующая информация должна быть записана для каждой ИТ-системы:
• Уникальное имя (напр., полное имя на сервере или идентификационный номер);
• Тип и функции (напр., база данных сервера для приложения X);
• Платформа, лежащая в основе (напр., аппаратная платформа и операционная система);
• Размещение (напр., здание, номер комнаты);
• Ответственный администратор;
• Доступные интерфейсы связи (напр., Интернет-соединение, Bluetooth, адаптер беспроводной ЛВС);
• Тип сетевого соединения и сетевой адрес.
Определенная информация необходима не только для самих ИТ-систем, но также для сетевых соединений между системами и для соединений с внешним миром, а именно:
• Тип кабельной системы или линий связи (напр., оптоволоконный кабель или беспроводная ЛВС, основанная на IEEE 802.11);
• Максимальная скорость передачи данных (напр., 10 Mb/с);
• Сетевые протоколы, используемые на нижних уровнях (напр., Ethernet, TCP/IP);
• Для внешних соединений, детали внешних сетей (напр., Internet, название провайдера).
Следует выделить области с разными требованиями защиты.
Нет необходимости готовить план сети на бумаге. Если информационная технология в компании или учреждении вышла за пределы определенного размера, следует использовать подходящую программу для регистрации и поддержки плана сети, т.к. бумажный документ будет очень сложным и подлежащим постоянным изменениям.
Обновление плана сети
Так как структура ИТ обычно приспосабливается к специфическим требованиям организации и поддержка плана сети объединяет определенные ресурсы, план сети не всегда будет актуальным. В действительности, часто только основные изменения в структуре ИТ на отдельных участках приводит к обновлению плана сети.
Принимая во внимание использование плана для анализа структуры ИТ, следующим шагом является сравнение существующего плана сети (или частичных планов, если общий план был разделен на меньшие части для удобства его чтения) с действительно существующей структурой ИТ и при необходимости его обновление, чтобы отразить текущую ситуацию. Во время выполнения этих действий ответственные за ИТ и все администраторы отдельных приложений и сетей должны консультироваться. Если для централизованного управления сетью и системой используется какая-то программа, то следует проверить, поддерживает ли эта программа составление плана сети. Однако, следует заметить, что функция автоматического или полуавтоматического обнаружения компонентов временно создает дополнительный трафик в сети. Должны предприниматься шаги, гарантирующие, что этот сетевой трафик не навредит другим операциям ИТ.
Пример: Bundesamt für Organisation und Verwaltung (Федеральная служба организации и администрирования, Federal Agency for Organisation and Administration, BOV) - Часть 1
Придерживаемся примерного скорректированного плана сети для вымышленного госучреждения – BOV. Следует заметить, что структура ИТ BOV далеко не оптимальна с точки зрения безопасности ИТ. Пример просто используется, чтобы показать применение IT-Grundschutz. Только обзор, предоставленный здесь, сложный пример, найденный во вспомогательных материалах для IT-Grundschutz.
Допустим, что BOV – это официальный орган с персоналом 150 человек, 130 из них имеют рабочие места. Географически, персонал делится на главный офис в Бонне и дополнительное размещение в Берлине, где они обрабатывают такие подзадачи как выполнение, стандарты и координирование. Из этих 130 человек со своими ИТ рабочими станциями 90 работают в Бонне и 40 в Берлине.
Все рабочие станции объединены в сеть, чтобы сотрудники могли выполнять свою работу. Берлинский филиал подключен по выделенной линии. Все сотрудники могут в любое время обращаться к необходимым им модулям рекомендаций, нормативов, форм и текстов. Все относящиеся к работе продукты размещены в центральной базе данных. Черновые документы готовятся, распространяются и подписываются исключительно в электронном виде. Чтобы внедрять и поддерживать всю необходимую функциональность, в Бонне был организован ИТ департамент.
Рисунок: Пример скорректированного плана сети
В показанном плане сети каждая ИТ-система (сервер, клиентский или другой активный сетевой компонент) показана с идентификационным номером (Sn, Cn, Nn и т.д.), а также в скобках указана функциональность и, при необходимости, операционная система.
И в Берлине и в Бонне клиенты собраны в соответствующие группы. Все 130 клиентов имеют одинаковую виртуальную конфигурацию, но есть разница между ними относительно приложений, интеграции в сеть и базовой инфраструктуры. Группа С1 представляет 5 клиентов в отделе персонала. У них есть доступ к серверу S1 в отделе персонала в Бонне. С2 и С3 представляют 10 клиентов в административном отделе и 75 клиентов в отделах конечных пользователей в Бонне. Единственное отличие здесь в отношении к используемым прикладным программам. Наконец, группа С4 представляет клиентов в отделах конечных пользователей в Берлине. Они отличаются от групп С1-С3 инфраструктурой окружения и их интеграцией в общую сеть.
Выполненные действия:
• Анализ с помощью существующих графических изображений сети, напр., топологические планы сети;
• При необходимости обновление или разработка планов сети;
• Анализ с помощью существующей дополнительной информации о содержащихся ИТ-системах и при необходимости их обновление и завершение;
• Анализ существующей дополнительной информации о каналах связи и при необходимости их обновление и завершение.
С целью определения требований защиты и моделирования ресурсов ИТ, которые в дальнейшем должны выполняться, следует разработать список существующих и планируемых ИТ ресурсов в форме таблицы. Термин "ИТ ресурсы" относится не только к компьютерам, но также к активным сетевым компонентам, сетевым принтерам, телекоммуникационным системам и т.д. Внимание сосредоточено на технической реализации ИТ-систем, напр., отдельных рабочих станций ПК, сервера Windows NT, клиента Windows XP, сервера Unix, телекоммуникационных систем. С этой точки зрения, только такие системы будут рассматриваться (напр., сервер UNIX), а не индивидуальные элементы, которые составляют соответствующую ИТ-систему (т.е. компьютер, клавиатура, монитор и т.д.).
Завершенная и корректная документация по существующим и планируемым ИТ-системам используется не только для разработки концепции безопасности ИТ. Она также нужна для проверки, поддержки, поиска неисправностей и восстановления ИТ-систем.
И объединенные в сеть и необъединенные в сеть ИТ-системы, в особенности те, которые не включены в план сети, должны быть включены. ИТ-системы, которые объединены в группы как часть упрощения плана сети, теперь могут рассматриваться как один объект. Даже ИТ-системы, не перечисленные в плане сети, должны быть проверены на предмет, возможно ли создать соответствующие группы. Это может быть возможно, напр., для большого количества отдельных рабочих станций ПК, которые удовлетворяют требования по разделу "Упрощении с помощью формирования групп", и поэтому они могут быть объединены.
При сборе данных следующая информация, которая потребуется на дальнейших этапах, должна быть отмечена:
• Уникальное имя ИТ-системы;
• Описание (тип и функции);
• Платформа (напр., аппаратная архитектура / операционная система);
• Если есть группы, то чисто ИТ-систем в группе;
• Узел установки ИТ-систем;
• Статус ИТ-систем (операционный, на этапе тестирования, на этапе планирования);
• Пользователь/администратор ИТ-систем.
Например: Bundesamt für Organisation und Verwaltung (Федеральная служба организации и администрирования, Federal Agency for Organisation and Administration, BOV) Часть 2
В качестве примера ниже приведена таблица, которая показывает специалистов из списка ИТ-систем в BOV. Полный список содержится на CD-ROM.
|
No. |
Описание |
Платформа |
Количество |
Размещение |
Статус |
Пользователь(ли) / Администратор |
|
S1 |
Сервер для отдела персонала |
Сервер Windows NT |
1 |
Бонн, R 1.01 |
Операционный |
Отдел персонала |
|
S2 |
Первичный контроллер домена |
Сервер Windows NT |
1 |
Бонн, R 3.10 |
Операционный |
Все пользователи ИТ |
|
C1 |
Группа клиентов в отделе обработки данных персонала |
Рабочая станция Windows NT |
5 |
Бонн, R 1.02 - R 1.06 |
Операционный |
Отдел персонала |
|
C2 |
Группа клиентов в отделе администрирования |
Рабочая станция Windows NT |
10 |
Бонн, R 1.07 - R 1.16 |
Операционный |
Административ-ный отдел |
|
C6 |
Группа ноутбуков для Берлинского офиса |
Ноутбук с Windows 95 |
2 |
Берлин, R 2.01 |
Операционный |
Все пользователи ИТ в Берлинском офисе |
|
N1 |
Маршрутизатор соединения с Интернет |
Маршрути-затор |
1 |
Бонн, R 3.09 |
Операционный |
Все пользователи ИТ |
|
N2 |
Файервол |
Прикладной шлюз на UNIX |
1 |
Бонн, R 3.09 |
Операционный |
Все пользователи ИТ |
|
N3 |
Коммутатор |
Коммутатор |
1 |
Бонн, R 3.09 |
Операционный |
Все пользователи ИТ |
|
T1 |
Приватная ветка обмена для Бонна |
ISDN PBX |
1 |
Бонн, B.02 |
Операционный |
Весь персонал в главном офисе Бонна |
ИТ-системы/группы S1, S2, C1, C2, N1, N2 и N3 взяты прямо из плана сети. Дополнительно не присоединенная к сети группа С6 (ноутбуки) и Т1 (PBX) добавлены.
Выполненные действия:
• Проверка, соответствуют ли существующие базы данных или существующие либо планируемые ИТ-системы дальнейшему подходу;
• Составление или обновление и завершение списка присоединенных к сети и отдельных ИТ-систем;
• Назначение ИТ-системам или группам ИТ-систем уникального имени или аббревиатуры.
Чтобы уменьшить количество требуемых попыток, в каждом случае только наиболее важные ИТ-приложения, работающие или планирующиеся к работе на рассматриваемых ИТ-системах, включаются. В терминах эффективного использования нет необходимости записывать все приложения полностью, если хотя бы ИТ-приложения, работающие на имеющих отношение к делу ИТ-системах, записаны.
• Для которых важно, чтобы их данные/информация и программы оставались конфиденциальными (т.е. максимальные требования конфиденциальности);
• Для которых обязательно, чтобы их данные/информация и программы были корректными и не изменялись (т.е. максимальные требования целостности);
• У которых самое малое допустимое время простоя (т.е. максимальные требования к доступности).
Чтобы обеспечить это, при записи ИТ-приложений следует спросить оценки пользователей или ответственных за приложения
Определение или документирование ИТ-приложений легче, если ИТ-приложения перечислены рядом со своими системами. Из-за их широкого влияния, сервера должны быть первыми элементами, на которых собирается информация. Чтобы достичь как можно лучшего баланса, документирование может быть завершено для клиентских и индивидуальных система рабочих мест. Затем должно быть установлено, какие переключающие элементы сети какие ИТ-приложения поддерживают.
В таком контексте полезно назначить серийный номер каждому приложению в качестве справочной информации. Так как многие сотрудники отдела безопасности ИТ также несут ответственность за защиту персональных данных как сотрудник отдела защиты данных, полезно отметить сохраняет ли и/или обрабатывает ли персональные данные ИТ-приложение. Т.к. требования защиты приложений обычно следуют из требований безопасности информации, которую оно (приложение) обрабатывает, этот тип информации также должно быть зарегистрировано в таблице.
Тогда в каждом случае приложения назначаются ИТ-системам, которые должны их запустить. Это могут быть ИТ-системы, в которых выполняются ИТ-приложения, но также это могут быть ИТ-системы, которые передают данные, созданные в приложениях.
Результат этих действий – обзор, какие основные ИТ-приложения на каких ИТ-системах обрабатываются, используются и передаются.
Стоит отметить, какие бизнес-процессы поддерживают ИТ-приложения и какую информацию они обрабатывают. У каждого бизнес-процесса есть владелец или ответственное лицо. У соответствующих ИТ-приложений есть пользователи. Эта информация также должна быть записана, чтобы легче можно было определить и связаться с людьми по вопросам ИТ-безопасности или быстро добраться до затронутых групп пользователей.
Рекомендуется записывать результаты в форме таблицы.
Пример: Bundesamt für Organisation und Verwaltung (Федеральная служба организации и администрирования, Federal Agency for Organisation and Administration, BOV) – Часть 3
Следует выдержка из документации по ИТ-приложениям и назначение затронутых ИТ-систем в выдуманном примере BOV:
|
Описание ИТ-приложений |
ИТ-системы |
||||||||
|
Прилож. №. |
ИТ приложение / информация |
Личные данные |
S1 |
S2 |
S3 |
S4 |
S5 |
S6 |
S7 |
|
A1 |
Обработка данных персонала |
X |
X |
|
|
|
|
|
|
|
A2 |
Обработка выгод |
X |
X |
|
|
|
|
|
|
|
A3 |
Учет дорожных расходов |
X |
X |
|
|
|
|
|
|
|
A4 |
Аутентификация пользователя |
X |
|
X |
|
|
|
X |
|
|
A5 |
Системное управление |
|
|
X |
|
|
|
|
|
|
A6 |
Обмен информацией (E-mail, календарь деловых встреч) |
X |
|
|
X |
|
|
|
|
|
A7 |
Центральное управление документацией |
|
|
|
|
X |
|
|
|
Ключ: Ai X Sj = выполнение ИТ-приложения Ai зависит от ИТ-системы Sj.
Регистрация зависимостей между ИТ-приложениями
Опционально, зависимости между ИТ-приложениями могут быть показаны, чтобы обеспечить лучшее общее представление (напр., зависимость приложения от определенной базы данных).
Выполненные действия:
• Если не все ИТ-приложения задокументированы, спросите ответственного за приложение о его мнении о том, у какого из ИТ-приложений в каждой ИТ-системе наивысшие требования безопасности;
• Сделайте краткий обзор всех ИТ-приложений и отметьте их уникальным номером или кодом;
• Назначьте ИТ-приложения ИТ-системам (сервера, клиенты, сетевые элементы переключения и т.д.), необходимым для работы;
• Для каждого ИТ-приложения отметьте соответствующий бизнес-процесс, обрабатываемую информацию, владельца и, при необходимости, пользователей;
• Для каждого приложения отметьте объем обрабатываемых им данных.
Бизнес-процессы и рассматриваемые приложения для специалистов не только обрабатываются определенных ИТ-системах, но также в пределах географической инфраструктуры организации. В зависимости от размеров организации и многих других факторов, организация может размещаться в своем собственном здании или на общем этаже. Много организаций также используют свойства, далекие или которые необходимо делить с другими пользователями. Все свойства, с помощью которых бизнес-процессы и приложения для специалистов работают, должны быть включены в концепцию безопасности. Сюда относятся свойства, здания, этажи, участки и соединения между ними. Все линии связи, которые проходят через соединения, проходящие через свойства, доступные третьим лицам, должны считаться внешними.
Для дальнейшего подхода моделирования согласно IT-Grundschutz и для планирования полезно создать краткий обзор свойств, особенно для участков, в которых расположены ИТ-системы или которые используются для работы ИТ. Сюда относятся участки, которые используются только для работы ИТ (серверные комнаты, архивы носителей данных), те, в которых другие ИТ-системы работают (офисы), а также линии связи. Если ИТ-системы хранятся в защищенном шкафу вместо специальной технической комнаты, то шкаф должен быть зарегистрирован как участок.
Замечание: при записи ИТ-систем место для установки уже должно быть зарегистрировано.
К тому же, следует проверить, хранится ли информация, требующая защиты, на других участках. Затем эти участки должны быть зарегистрированы. Обрабатываемая информация, должна быть очищена от этой документации.
Следующая таблица показывает, каким может быть табличный обзор участков. Есть место для определения требований безопасности участков, но эти колонки заполняются на более поздних этапах.
|
Участок |
ИТ / информация |
Требования безопасности |
||||
|
Имя |
Тип |
Место |
ИТ системы / носитель данных |
Конфиден-циальность |
Целост-ность |
Доступность |
|
R U.02 |
Архив носителей данных |
Здание в Бонне |
Носитель резервных копий (еженедельная копия серверов S1 до S5) |
|
|
|
|
R B.02 |
Технологический участок |
Здание в Бонне |
Система связи |
|
|
|
|
R 1.01 |
Серверная комната |
Здание в Бонне |
S1, N4 |
|
|
|
|
R 1.02 - R 1.06 |
Офисы |
Здание в Бонне |
C1 |
|
|
|
|
R 3.11 |
Защитный шкаф на участке R 3.11 |
Здание в Бонне |
Резервные носители данных (ежедневные копии серверов S1 до S5) |
|
|
|
|
R E.03 |
Серверная комната |
Здание в Берлине |
S6, N6, N7 |
|
|
|
|
R 2.01 - R 2.40 |
Офисы |
Здание в Берлине |
C4, некоторые с факсами |
|
|
|
Выполненные действия:
• Создание списка всех перечисленных свойств, зданий и участков при записи ИТ-систем;
• Добавление других участков, в которых хранится информация, требующая защиты или обработанная другим способом.
Следующий шаг – удалить любую ненужную для следующего набора задач информацию из плана сети, чтобы упростить его использование. Соответственно, любые идентичные элементы следует объединить в одну группу, которая представлена на плане сети единым объектом.
Если есть только несколько основных конфигураций, соответствующее формирование групп также имеет преимущества значительного упрощения администрирования. С помощью возможной стандартизации ИТ окружения, количество потенциальных слабых мест защиты также уменьшается и меры безопасности в данной области могут внедряться, не выделяя самые разные уязвимые места.. это не только преимущества для безопасности ИТ, но это также уменьшает затраты..
Компоненты могут назначать одной и той же группе, если все компоненты:
• одного типа;
• имеют одинаковую или почти одинаковую конфигурацию;
• соединены с сетью одинаковым или почти одинаковым образом (напр., на одном коммутаторе);
• подчиняются одним и тем же административным и инфраструктурным основным условиям;
• используют одинаковые приложения;
• имеют одинаковые требования защиты.
На основе требований, установленных для формирования групп, можно предположить для безопасности ИТ, что пример группы предоставляет статус безопасности ИТ группы.
Наиболее важный пример для группировки компонент на плане сети – это группировка клиентов. Компании и госучреждения в общем случае имеют большое количество клиентов, которые, однако, можно классифицировать в соответствии со схемой, показанной выше, в определенное количество групп. Если количество ИТ-ресурсов очень большое и по причине избыточности или пропускной способности много серверов выполняют одну и ту же задачу, эти сервера могут также быть объединены в группу.
После завершения группировки объединенные элементы показываются на плане сети как один объект. Тип и количество компонентов в одной группе должны быть указаны.
Выполненные действия:
• Объединение подобных элементов в группы;
• Создание откорректированного плана сети, в котором каждая группа показана отдельным объектом;
• Указание типа и количества каждого из объединенных элементов.
ЗАДАНИЕ:
На основание приведенных примеров, организовать Анализ ІТ структуры своего предприятия.