Мошак_Птицына_ Учебное пособие. Федеральное государственное бюджетное образовательное учреждение высшего образования санктпетербургский

• Название: Федеральное государственное бюджетное образовательное учреждение высшего образования санктпетербургский
• Дата: 08.05.2023
• Размер: 3.09 Mb.
• Имя файла: Мошак_Птицына_ Учебное пособие.pdf
• Тип: Учебное пособие; #1115671
• страница: 10 из 16

5.3. Этап «РЕАЛИЗАЦИЯ» процедур СОИБ
Задача этапа «РЕАЛИЗАЦИЯ» заключается в выполнении всех планов, связанных с построением, вводом в действие и совершенствованием СУИБ, определенных на этапе «ПЛАНИРОВАНИЕ» и/ или реализации решений, определенных на этапе «СОВЕРШЕНСТВОВАНИЕ» и не требующих вы- полнения деятельности по планированию соответствующих улучшений.
В рамках выполнения процессов этапа «РЕАЛИЗАЦИЯ» СОИБ предусматривается проведение следующих основных работ:
1.
Внедрение системы управления рисками.
2. Внедрение системы управления инцидентами.
3. Внедрение системы интегрального мониторинга ИБ.
5. Внедрение системы «Анализ функционирования СОИБ».
6.Внедрение типовой системы «Обеспечение непрерывности бизнеса».
5.3.1. Внедрение системы управления рисками
Управление рисками — процесс циклический. По существу, последний этап — это оператор конца цикла, предписывающий вернуться к началу.
Проведение оценки рисков и выбор контрмер, как было обозначено, проводится на этапе «ПЛАНИРОВАНИЕ», на этапе «ВНЕДРЕНИЕ» выбранные контрмеры внедряются в СИБ, далее на этапе «МОНИТОРИНГ» осуществляется контроль и оценка эффективности внедренных контрмер, которая служит основанием для переоценки рисков на этапе
«СОВЕРШЕНСТВОВАНИЕ» и на этапе «ПЛАНИРОВАНИЕ» цикл завершается планированием корректировки контрмер, которые, в свою очередь, внедряются далее на этапе «ВНЕДРЕНИЕ».
Для эффективного управления ИБ, в т. ч. управления рисками ИБ, разработаны различные специальные методики и инструментальные средства на основе международных и национальных стандартов ISO 15408, ISO 17799,

РС БР ИББС, BS 7799-2:2005, ISO 27001, ISO 13335, BSI, COBIT, NIST 80030,
COSO, SAS , Software Tool, MethodWare, Risk Advisor,
CRAMM
,
RiskWatch,
COBRA, ГРИФ, АванГард и др. [7, 8, 42, 43, 47-55].
На отечественном рынке имеется ряд продуктов указанного класса позволяющие осуществить управление рисками ИС с учетом различного уровням зрелости организаций. Указанные методики управления рисками разработаны, как правило, на основе требований международного стандарта
ISO 17799.
Приведем краткое описание некоторых отечественных и зарубежных
инструментальных средства управления информационными рисками (с учетом возможности их адаптации и применения в отечественных условиях), возможности которых приведены в [42, 43, 55].
5.3.1.1. Внедрение количественных методик и инструментальных средств управления рисками
К наиболее востребованных в нашей стране классу количественных методик и инструментальных средств управления рисками из зарубежных продуктов относятся CRAMM, RiskWatch, Risk Advisor, а также отечественная экспертная система «АванГард».
CRAMM. Управление рисками в методике СRAMM осуществляется в несколько этапов, на которых:
1) определяются границы исследуемой информационной системы организации, состав и структура ее основных информационных активов и транзакций;
2) идентифицируются активы, и определяется их стоимость;
3) идентифицируются и оцениваются угрозы и уязвимости информационных активов организации;
4) проводится анализа рисков, который позволяет получить качественные и количественные оценки рисков (расчет ущерба). Для оценки возможного ущерба предлагается ряд способов обработки рисков;
5) поиск адекватных контрмер (меры и средств уменьшения или уклонения
от риска). На этом этапе CRAMM генерирует несколько вариантов контрмер, адекватных выявленным рискам и их уровням.
CRAMM имеет средства генерации ряда отчетов, необходимых при проведении аудита информационной безопасности в соответствии с требованиями стандарта BS 7799 (ISO 17799).
CRAMM – пример методики анализа рисков и управления рисками, в которой первоначальные оценки даются на качественном уровне, и потом производится переход к количественной оценке (в баллах).
Указанная методика также может быть применима в отечественной практике, хотя требования по ИБ российских РД и зарубежных стандартов различаются. Недостаток метода CRAMM с позиции отечественного потребителя состоит также в сложности русификации и большом объеме выходных документов (сотни страниц).
Методика RiskWatch. В основе продукта RiskWatch положена методика

анализа рисков, которая состоит из четырех этапов.
1)Этап определение предмета исследования. Используются шаблоны по типу ИС организации (коммерческая ИС, государственная ИС и т. д.). В шаблонах в соответствии с типом ИС надо выбрать из указанных перечней: категорию защищаемых ресурсов, потерь, угроз, уязвимостей и мер защиты.
2) Этап ввода данных. Описывающих конкретные характеристики системы (ресурсы, потери и классы инцидентов). С помощью опросного листа выявляются возможные уязвимости. Задается частота возникновения угроз, степень уязвимости и ценность ресурсов.
3) Этап количественной оценки риска (рассчитывается профиль рисков и выбираются контрмеры).
4) Этап генерации отчетов.
К достоинству RiskWatch можно отнести простота и масштабируемость применения, легкая адаптация к требованиям ИБ отечественных регуляторов.
Risk Advisor (организация MethodWare). ПО Risk Advisor позволяет идентифицировать риски и угрозы, а также определить ущерб по результату реализации угроз и предложить контрмеры.
По сравнению с CRAMM методика Risk Advisor значительно проще в применении итребует существенно меньшей трудоемкости.
Экспертная система АванГард (Институт системного анализа РАН)
[49]. Типовой пакет программ системы АванГард включает два программных продукта: «АванГард-Анализ» и «АванГард-Контроль». При этом ПО
«АванГард-Анализ» решает задачи управления ИБ (анализ рисков, формулирование целей безопасности и требований политики безопасности), а
ПО «АванГард-Контроль» - решает задачу контроля уровня защищенности ИС
(определение уязвимых мест защиты, т.е. таких мест в ИС, где требования ИБ не выполняются).
Экспертная система АванГард может использоваться для построения корпоративных методик анализа и управления рисков с учетом требования
ПИБ организации и РД по ИБ отечественных регуляторов.
Единой методики, по которой можно было бы определить количественную величину риска, на сегодняшний день не существует. Во- первых, это обусловлено отсутствием необходимого объема статистической информации о возможности возникновения какой-либо конкретной угрозы.
Во-вторых, играет немаловажную роль тот факт, что определить величину стоимости конкретного информационного ресурса порой очень трудно. Например, владелец информационного ресурса легко может указать стоимость оборудования и носителей, однако назвать точную стоимость данных, находящихся на этом оборудовании и носителях, он фактически не в состоянии. Поэтому самой часто используемой является качественная оценка информационных рисков, главные задачи которой – это идентифицировать факторы риска, определить возможные уязвимые области риска и оценить воздействие каждого из видов. [55].
5.3.1.2. Внедрение качественных методик и инструментальных средств

управления рисками
Качественные методики управления рисками используют оценку риска на качественном уровне (например, по шкале "высокий", "средний", "низкий"). К методикам указанного класса относятся методики COBRA, RA Software Tool,
FRAP и OCTAVE т др. Опишем кратко возможности наиболее востребованных у нас.
Методика управления рисками COBRA. Эта методика достаточно проста в применении, т. к. для оценки информационных рисков организации использует небольшое количество тематических вопросников (check list’s). Ответы автоматически обрабатываются, и с помощью соответствующих правил логического вывода формируется итоговый отчет c текущими оценками информационных рисков организации и рекомендациями по их управлению.
При необходимости перечень учитываемых требований можно дополнить различными требованиями отечественных нормативных документов по ИБ регуляторов и/или организации.
Методика и инструментальные средства управления рисками RA
Software Tool. В состав RA Software Tool входит ряд программных модулей, обеспечивающих проведение оценки рисков в соответствии как с требованиями базового уровня, так и c более детальными спецификациями руководства по оценке рисков PD 3002 Британского института стандартов
(BSI).
5.3.2. Внедрение системы управления инцидентами
ИБ
Международный стандарт ISO 27001:2005 обращает особое внимание на необходимость внедрения процедуры управления инцидентами ИБ.
В общем случае инцидент ИБ определяется как событие (или совокупность событий), которое может скомпрометировать бизнес–процессы организации или угрожает ее информационной безопасности (ISO/IEC TR
18044:2004). Под процедурой управления инцидентами ИБ будем понимать своевременную реакцию на инциденты безопасности и устранение их последствий с целью эффективного функционирования бизнес-процессов. При реализации процессов управления инцидентами ИБ рекомендуется использовать ГОСТ Р ИСО/МЭК ТО 18044.
Внедрение процесса управления инцидентам ИБ позволяет оценить эффективность функционирования СУИБ в целом и системы управления рисками, в частности. Частота появления и количество инцидентов ИБ, зафиксированных системой интегрального мониторинга в ИС, – один из наглядных показателей эффективности функционирования СУИБ. Внедрение процесса управления инцидентам ИБ позволяет количественно оценить эту эффективность.
Для внедрения процедуры управления инцидентами ИБ необходимо провести следующие организационно-технические мероприятия.
1. Утвердить процедуры разработки управления инцидентами ИБ (как и всех процедур в организации) по инициативе ее руководства. Как правило, процедура управления инцидентами разрабатывается в рамках внедрения

СУИБ, поэтому важна позиция руководства по вопросу ее создания и функционирования. На данном этапе важно, чтобы все сотрудники организации понимали, что обеспечение информационной безопасности в целом и управление инцидентами ИБ в частности являются основными бизнес–целями организации.
2. Разработать необходимые нормативные документы по управлению
инцидентами. Такие документы должны описывать:
– определение инцидента ИБ, перечень событий, являющихся инцидентами ИБ (что в организации является инцидентом);
– порядок оповещения ответственных лиц о возникновении инцидента
ИБ (необходимо определить формат отчета, а также отразить контактную информацию лиц, которых следует оповещать об инциденте);
– порядок устранения последствий и причин инцидента ИБ;
– порядок расследования инцидента ИБ (определение причин инцидента
ИБ, виновных в возникновении инцидента ИБ, порядок сбора и сохранения улик);
– внесение дисциплинарных взысканий; реализация необходимых корректирующих и превентивных мер.
3. Определить понятие инцидента ИБ, так как в организации отсутствует методика определения инцидентов ИБ, а сотрудники не знают, какие события являются инцидентами ИБ. Следует понимать, что все события, которые не войдут в указанный перечень, будут рассматриваться как штатные (даже если они несут угрозу информационной безопасности). В частности, инцидентами ИБ могут быть:
– отказ в обслуживании сервисов, средств обработки информации, оборудования;
– нарушение конфиденциальности и целостности ценной информации;
– несоблюдение требований к ИБ, принятых в организации (например, нарушение правил обработки информации);
– несанкционированный мониторинг ИС;
– вредоносные программы;
– компрометация ключевой системы (например, разглашение пароля пользователя).
Поскольку инцидентом ИБ является неразрешенное событие, оно должно быть запрещено, следовательно, необходимо разработать документ, в котором четко классифицированы инциденты ИБ, описаны все действия, которые можно выполнять в ИС пользователю и которые выполнять запрещено. Важно, чтобы были налажены такие процедуры, как интегральный мониторинг событий безопасности, своевременное удаление неиспользуемых учетных записей, контроль действий легальных пользователей в ИС, в том числе привилегированных, и пр.
4. Разработать процедуру оповещения о возникновении инцидента ИБ.
Сотрудники организации зачастую не осведомлены о том, кого и в какой форме следует ставить в известность при возникновении инцидента, —

например, не определены ни формы отчетов, ни перечень лиц, которым необходимо отправлять отчеты об инцидентах. Даже если сотрудник заметит, что его коллега уносит для работы домой конфиденциальные документы организации, он не всегда знает, какие действия следует предпринимать в данной ситуации.
5. Разработать методику регистрации инцидента ИБ.Ответственным лицам (даже если таковые назначены) часто не предоставляется методика регистрации инцидентов — не существует специальных журналов их регистрации, а также правил и сроков заполнения.
Требуется разработать инструкцию для специалиста, в обязанности которого входит регистрация инцидента. Сотрудник, обнаруживший инцидент, связывается с сотрудником, ответственным за регистрацию инцидента и выполнение дальнейших действий. В небольших организациях сотрудники обращаются напрямую к специалисту, который может устранить последствия и причины инцидента (например, к системному администратору или администратору безопасности). В достаточно крупных организациях, как правило, выделяют сотрудника, который регистрирует инцидент и передает информацию об инциденте соответствующим специалистам. Такая инструкция может содержать, например, правила и срок регистрации инцидента, перечень необходимых первоначальных инструкций для сотрудника, обнаружившего инцидент, кроме того, описание порядка передачи информации об инциденте соответствующему специалисту, порядок контроля за устранением последствий и причин инцидента.
6. Разработать процедуру устранения последствий и причин инцидента
ИБ.
В организациях, как правило, отсутствует документально зафиксированная процедура, описывающая действия, которые необходимо выполнить с целью устранения последствий и причин инцидента. В первую очередь такая процедура должна предусматривать, чтобы мероприятия по устранению последствий и причин инцидента не нарушали процедуры их расследования: устранение последствий инцидента не должно «заметать следы», чтобы невозможно было установить виновных в инциденте.
Инструкция по устранению причин и последствий инцидента включает описание общих действий, которые необходимо предпринять (конкретные действия для каждого вида инцидента определять трудоемко и не всегда целесообразно), а также сроки, в течение которых следует устранить последствия и причины инцидента. Сроки устранения последствий и причин инцидента зависят от уровня инцидента.
Следует разработать классификацию инцидентов – определить количество уровней критичности инцидентов, описать инциденты каждого уровня и сроки их устранения.
Документ, определяющий, какие события в организации следует считать инцидентом, также может описывать и уровни инцидентов.
Таким образом, инструкция по устранению последствий и причин инцидента может включать: описание действий, предпринимаемых для устранения последствий и причин инцидента, сроки устранения и указание на ответственность за несоблюдение инструкции.

7. Разработать Инструкцию по расследованию инцидента ИБ. На этапе расследования инцидентов основную роль играют: ведение журналов регистрации событий, четкое разделение полномочий пользователей, ответственность за выполненные действия – важны доказательства того, кто участвовал в инциденте и какие действия он выполнял.
Расследование инцидента включает в себя определение виновных в его возникновении, сбор доказательств и улик инцидента, определение соответствующих дисциплинарных взысканий. В крупных организациях, как правило, выделяют комиссию по расследованию инцидентов информационной безопасности (в состав которой может входить сотрудник, регистрирующий инциденты). Инструкция по расследованию инцидентов должна описывать: действия по расследованию инцидента (в том числе определение виновных в его возникновении), правила сбора и хранения улик
(особенно в случае, если может потребоваться использование улик в судебных органах) и правила внесения дисциплинарных взысканий.
Как правило, если организации был нанесен какой–либо ущерб, то к виновным в возникновении инцидента (которые определены без необходимых в таких случаях процедур) все же применяются различные взыскания, однако внесение дисциплинарных взысканий не всегда подчиняется утвержденным процедурам и другие действия по предотвращению повторения инцидента выполняются тоже не всегда.
После устранения последствий инцидента и восстановления нормального функционирования бизнес–процессов организации, возможно, потребуется выполнить действия по предотвращению повторного возникновения инцидента. Для определения необходимости реализации таких действий следует провести анализ рисков, в рамках которого определяется целесообразность корректирующих и превентивных действий.
Через определенное время (как правило, через полгода или год) необходимо заново пересмотреть перечень событий, называемых инцидентами, форму отчета и пр., внедрить обновленную процедуру в информационную систему, проверить ее функционирование и эффективности и реализовать превентивные действия. Таким образом, цикл модели PDCA будет непрерывно повторяться и гарантировать четкое функционирование процедуры управления инцидентами и, главное, ее постоянное улучшение.
Во многих крупных организациях внедряется служба поддержки Service
Desk, в обязанности которой входит управление инцидентами в области информационных технологий. Процедура управления ИТ–инцидентами регулируется стандартом ISO/IEC 20000:2005, пришедшим на смену BS
15000:2002, который, в свою очередь, взял за основу библиотеку ITIL. Сама процедура управления инцидентами ИТ очень близка к процедуре управления инцидентами ИБ с той лишь разницей, что в последнем случае больший упор делается на его расследование, сбор улик, наказание виновных
(вплоть до обращения в суд).

Управление инцидентами ИБ, как правило, возлагается на службу поддержки, обрабатывающую инциденты ИТ (в том случае, если такая служба существует в организации). Это еще раз доказывает то, что целесообразно разработать одну систему управления всеми процессами в организации, так как управление схожими процессами в разных областях ее деятельности часто выполняется по одной схеме
Важно, чтобы ни один инцидент ИБ не остался незамеченным, было проведено расследование, выявлены виновные, и, самое главное, выполнены корректирующие и превентивные действия. Главной особенностью инцидентов ИБ является то, что они не всегда заметны (не всегда мешают в работе пользователей), однако возможный ущерб от таких инцидентов сложно недооценить. Следовательно, необходима четкая процедура регистрации и расследования инцидентов безопасности, а также информирование пользователей о правилах определения инцидентов ИБ.
Необходимо понимать, что управление инцидентами ИБ не предупреждает нанесение ущерба организации (как правило, организация уже понесла ущерб, связанный с инцидентом), однако расследование инцидента ИБ и своевременное внедрение превентивных и корректирующих мер снижает вероятность его повторения (и, следовательно, вероятность повторения нанесения ущерба). Отметим также, что статистика инцидентов
ИБ представляет особую ценность для организации как показатель эффективности функционирования СУИБ. Статистику инцидентов ИБ следует также регулярно анализировать в рамках аудита системы управления информационной безопасностью.
5.3.3. Внедрение системы интегрального мониторинга ИБ
После проведения анализа рисков, выбора и внедрения контрмер, необходимо оценить их эффективность. Как правило, эффективность внедренных средств защиты определяется с помощью повторного анализа рисков. Необходимо понять, насколько действительно снизился риск.
Внедрение системы интегрального мониторинга ИБ направлено на решение
задачи обеспечения постоянного контроля эффективности контрмер
(контроля рисков) для периодической переоценки рисков. Таким образом, суть контроля эффективности контрмер состоит в том, чтобы убедиться, что риски заключены в приемлемые рамки (и остаются таковыми). Критерием эффективности внедренных контрмер может служить, например, количество и частота зафиксированных инцидентов ИБ за определенный временной период. При реализации системы интегрального мониторинга ИБ
рекомендуется использовать ГОСТ Р ИСО/МЭК ТО 18044.
На этапе «ПЛАНИРОВАНИЕ» было определено, что система интегрального мониторинга информационной безопасности (ЕСМИБ) должна обеспечить
– полноту и непрерывность сбора первичных событий ИБ от объектов области действия СОИБ с целью идентификации инцидентов ИБ;
– процедуру формирования оценки ИБ и ведения базы данных

коррелированных событий ИБ;
– выработку рекомендаций по оперативному блокированию инцидентов
ИБ;
– проведения отложенного анализа интегральных событий ИБ.
Приведем краткий обзор рынка систем интегрального мониторинга ИБ зарубежного и отечественного производства
5.3.3.1. Система сбора, анализа и корреляции информации netForensics
Система netForensics производства организации netForensics [56] предназначена для сбора, анализа и корреляции информации, поступающей от средств обнаружения попыток НСД, маршрутизаторов, МЭ, ОС, VPN и
WEB- серверов. Устройства, которые не поддерживаются системой, могут быть легко интегрированы при помощи универсальных агентов.
Информация, поступающая от устройств, подвергается четырём стадиям обработки: нормализация, агрегация, корреляция и визуализация.
На этапе нормализации каждое сообщение преобразуется в одно из ста внутренних сообщений системы.
На этапе агрегации, последовательности событий группируются на основе одного или нескольких критериев. В качестве критериев могут выступать: адрес источника, порт источника, адрес получателя, порт получателя, тип события, тип источника, протокол передачи, процесс, текст сообщения.
Далее, данные подвергаются корреляции. В системе реализовано два механизма корреляции – статистическая и корреляция, основанная на правилах. Статистическая корреляция позволяет проводить оценку рисков.
Корреляция, основанная на правилах, позволяет создавать событие, соответствующее реализации определённого сценария атаки, определяемого как последовательность событий, сгруппированных по определённым признакам с помощью логических операций.
После процессов нормализации, агрегации и корреляции, консолидированные данные отображаются в реальном времени на консоли.
Система реализована в трёхзвенной архитектуре, что даёт большие возможности масштабируемости, распределения компонентов и повышения надёжности. Основные компоненты системы – агенты, engines, master engine, консоль, база данных.
Функции агентов – приём данных, нормализация, преобразование в формат XML и передача по защищённому соединению engine. Engine агрегирует и коррелирует полученные от агентов данные. Master engine агрегирует и коррелирует данные полученные от engine (возможна конфигурация с несколькими engine). Консоль отвечает за отображение данных.
Все соединения между компонентами системы защищены. netForensics имеет гибкую систему генерации отчётов. Возможно создание пользовательских отчётов, и имеется большое количество предопределённых. Формат отчётов
– HTML, CVS, PDF. Имеется возможность ролевого управления.

В качестве СУБД используется промышленная СУБД Oracle9i.
Поддерживаемые ОС – Windows, Solaris, Linux.
5.3.3.2. Система сбора, анализа и корреляции информации EnVision
Система EnVision производства организации Network-Intelligence [57] предназначена для сбора, анализа и корреляции информации, поступающей от средств обнаружения попыток НСД, маршрутизаторов, МЭ, ОС, VPN. В отличие от netForensics, в enVision реализован единственный механизм корреляции – корреляции, основанной на правилах.
Система принимает все сообщения на порт №514 (нет возможности изменения без обращения в службу поддержки) по протоколу UDP. Далее сообщения записываются в файл, и, через настраиваемый интервал времени, записываются в базу данных.
EnVision имеет двухзвенную архитектуру и нет возможности распределения компонентов. Система генерации отчётов позволяет создавать пользовательские отчёты и имеет около 350 предопределённых. Формат отчётов – HTML.
Основные компоненты системы: DashBoard, Event Viewer, Alert Monitor,
Alert Browser, Report VU. DashBoard позволяет контролировать состояние компонентов системы. Event Viewer – консоль, позволяющая просматривать сообщения в реальном масштабе времени. Alert Monitor предназначен для просмотра коррелированных событий и событий, определённых в представлениях (views). Alert Browser позволяет просматривать сообщения, которые были сохранены в базе данных. Report VU – система генерации отчётов. Система имеет WEB интерфейс.
В системе реализован один вид корреляции – корреляция, основанная на правилах. Система не производит нормализацию сообщений, как система netForensics, и поэтому правила определяются для конкретных сообщений устройств. Каждое правило имеет следующие общие параметры:
– Message ID – идентификатор сообщения;
– Message text – текст сообщения;
– Class – класс корреляционного правила;
– Category – категория, соответствующая классу правила;
– Decay time – время, в течении которого должны произойти все события;
– Level – значимость сообщения (от 0 до 7);
– IP address matching – условие на IP адреса, обнаруженные в сообщениях;
Description – описание правила;
– Action – действие при соответствии полученной информации корреляционному правилу;
Последовательность сообщений, образующих правило – одно или несколько Circuit (совокупность операций), связанных одним из операторов:
– Or (или);
– And (и);

– And not (и не);
– Or not (или не);
– Followed by (следует за).
Временное действие каждого оператора можно ограничить (по умолчанию – бесконечность), после окончания заданного интервала состояние правила сбрасывается в начальное.
В системе имеется около 350 предопределённых отчётов. Все отчёты распределены по группам. Процесс создание пользовательских отчётов – пошаговое создание SQL запроса к базе данных с помощью графического интерфейса. Возможна генерация отчётов по расписанию.
5.3.3.3. Система управления средствами защиты, анализа и корреляции
ISS RealSecure SiteProtector
ISS RealSecure SiteProtector производства организации ISS [58] предназначена для управления средствами защиты, производимыми организацией ISS, анализа и корреляции поступающих данных. С помощью
Third Party Module возможно получение информации от МЭ Cisco PIX и
CheckPoint FW. При использовании Fusion Module возможно осуществление корреляции данных, поступающих от ПО Network Sensor, Server Sensor и
Internet Scanner.
Отличительная особенность системы – возможность корреляции данных об атаках с информацией о реальных уязвимостях, полученной после сканирования с помощью ISS Internet Scanner.
Система имеет распределённую архитектуру, что даёт большие возможности для распределения компонентов, масштабируемости и повышения надёжности. Основные компоненты системы: DataBase,
Application Server, Sensor Controller, Event Collector, Console, Fussion Module,
Third Party Module и сенсоры (Network Sensor, Server Sensor и т.д.) DataBase – база данных, которая отвечает за хранение всех данных, циркулирующих в системе. Application
Server
– сервер приложений, отвечающий взаимодействие компонентов. Event Collector отвечает за приём информации от сенсоров и передачу в СУБД. Console – приложение, которое позволяет управлять, конфигурировать и просматривать информацию о состоянии компонентов системы и отображать информацию о событиях, зарегистрированных сенсорами. Fussion Module отвечает за корреляцию данных, поступающих от сенсоров. Third Party Module предназначен для получения сообщений от МЭ Cisco PIX и CheckPoint FW.
Все соединения между компонентами системы защищены.
В качестве СУБД используется MS SQL Server 2000 или MSDE.
Система обрабатывает события, поступающие от ПО ISS Network
Sensor, Server Sensor, Desktop Protector, System Scanner, Internet Scanner, а также ПО МЭ Cisco PIX и CheckPoint FW.
Механизмы корреляции реализуется модулем Security Fusion Module. В системе реализовано два механизма корреляции:
– Event Correlation – корреляция информации об атаках и реально

существующих уязвимостях;
– Attack Correlation – корреляция, основанная на правилах.
Отличительной особенностью системы является наличие механизма
Event Correlation. Механизм Event Correlation реализуется компонентом
Impact Analysis Component модуля Security Fusion Module. Работа этого механизма позволяет уменьшить количество бесполезной информации на консоли системы. Это достигается путём изменения приоритета события от значения, заданного в политиках сенсора. Основываясь на результатах сканирования с помощью Internet Scanner, подключенного к системе ISS
SiteProtector, и информации, поступающей от сенсоров, IAC может оценить возможность реализации атаки, и затем выполнить одно или несколько действий из следующего списка:
– изменить приоритет события;
– записать событие в базу данных;
– отобразить информацию о событии на консоли;
– послать электронное письмо;
– послать SNMP;
– реакция, определённая пользователем.
Механизм Attack Correlation реализуется компонентом Attack Pattern
Component модуля Security Fusion Module. Данная корреляция – корреляция, основанная на правилах. Работа этого механизма позволяет сопоставить информацию от многих сенсоров предопределённых шаблонам атак и определить наличие таких событий, как попытки вторжения (в том числе и происходящие в «несколько шагов»), несанкционированное сканирование и прочие. Также модуль позволяет уменьшить количество информации на консоли путём комбинирования данных, полученных от многих сенсоров, которые соответствуют одному и тому же событию.
При минимальном соответствии полученных данных одному из шаблонов, модуль создаёт инцидент. Если при дальнейшем анализе будут получены данные, связанные с уже обнаруженным инцидентом, они будут добавлены к существующему.
Возможно создание исключений (Exception) из определённых событий или инцидентов. Событие или инцидент, добавленные в исключение, убираются из дальнейшего рассмотрения системой.
В системе реализовано 20 шаблонов атак. Возможности создания собственных шаблонов нет.
Система генерации отчётов позволяет создавать отчёты, соответствующие текущему представлению данных на консоли. Формат отчётов – HTML, CVS, PDF.
5.3.3.4. Система визуального анализа данных VisualLinks
Организация Visual Analytics Inc. [59] является лидером в области разработки программных продуктов визуального анализа данных и извлечения знаний (Visual Data Mining), организации информационного взаимодействия и коллективной работы аналитиков. Решения организации

Visual Analytics Inc.
VisuaLinks – платформенно-независимый инструмент визуального анализа данных, используемый для выявления шаблонов, тенденций, взаимосвязей и скрытых закономерностей в любых по типам и объемам источниках данных. VisuaLinks поддерживает полный цикл анализа информации – от обеспечения доступа к информационным источникам и их интеграции до создания отчетных документов, и представления результатов анализа. VisuaLinks предлагает единое и полное решение для широкого класса аналитических задач. VisuaLinks включает широкий набор инструментов и позволяет:
– объединять множество баз данных, имеющих различный формат и территориальное расположение;
– отображать неограниченные объемы данных;
– выявлять прямые и косвенные связи между объектами;
– обеспечить прямой доступ к любым базам данных без перезагрузки информации;
– раскрывать пересечения и взаимосвязи между различными типами данных;
– графически представлять результаты анализа в виде схем и диаграмм;
– использовать мощные аналитические функции для выявления шаблонов и тенденций;
– проводить расследование в упреждающем режиме;
– поддерживать работу аналитических групп в режиме on-line;
– сохранять данные в различных форматах, включая базы данных,
HTML, XML, изображения и текстовые файлы.
VisuaLinks поддерживает архитектуру клиент-сервер, что позволяет пользователям проводить анализ и обмениваться различными типами информации в ходе выполнения широкого круга задач. Объектами для данной системы может служить любая предметная область. Для обеспечения эффективного формирования наблюдаемых объектов
VisualLinks предоставляет средства, позволяющие провести:
– разработку унифицированных подходов к формированию описания предметной области;
– формирование требуемого набора объектов и связей, адекватно описывающих предметную область;
– разработку правил идентификации поступающей информации по объектам учета и ее сопоставления с хранящимися в системе данными.
Решение первых двух задач позволяет при работе с системой оперировать понятиями предметной области. В качестве элементов предметной области могут выступать типы объектов и связей. В качестве источников информации могут выступать информационные ресурсы, такие как:
– «витрины» (представления) данных из любых типов хранилища данных;
– БД, содержащие информацию службы электронного почтового

обмена, а также сведения о компьютерных вирусах, нарушителях, отпусках сотрудников;
– при необходимости, дополнительные БД любых форматов, поддерживающих JDBC или ODBC интерфейс (Oracle, MS SQL Server, MS
Access, DB2, MySQL и т.п.).
Система VisualLinks при функционировании обеспечивает поддержку следующих основных этапов выявления нарушений:
– формирование информационных массивов для целей анализа;
– оперативная обработка и анализ информации;
– представление результатов расследования.
Формирование информационных массивов для целей анализа – это этап сбора информации, достижение ее понимания и определение релевантности связей каждого элемента со всеми остальными. На данном этапе ведется целенаправленный сбор информации при помощи различных средств из всех доступных источников. Использование современных технологий позволит концентрировать усилия на сборе конкретной информации, относящейся к текущей деятельности. Данный элемент процесса расследования имеет важнейшее значение для работы всей системы, поскольку он позволяет минимизировать непроизводительные затраты времени и ресурсов. В рамках формирования информационных массивов для целей комплексного анализа обеспечивается информационно-аналитическая поддержка следующих процессов:
– извлечение, преобразование и загрузка данных;
– хранение данных.
Оперативная обработка и анализ информации – это объективный анализ результатов этапа формирования информационных массивов для достижения понимания целого. Данный этап является ключевым и включает:
– поиск значимых информационных объектов и связей;
– выявление признаков нарушений;
– проведение интерактивного детального анализа данных;
– выявление скрытых связей и закономерностей;
– проверка версий, выдвинутых в процессе выявления, раскрытия и расследования инцидентов, формирование направлений дальнейших действий.
Представление результатов расследования, формально, - это передача достигнутого понимания пользователям с целью практического использования полученных сведений. Система комплексного анализа обеспечивает представление результатов расследования (в том числе визуальное) в виде отчетов, схем, таблиц, графиков и диаграмм.
Подход к интегральному анализу данных системы VisualLinks включает
(рис.5.2):
– Методы и инструменты выявления закономерностей (Data Mining) предназначены для автоматизированного первичного отбора информации, содержащей признаки нарушений при использовании критических ресурсов.
– Инструменты многомерного анализа статистических данных (OLAP)

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