Смекни!
smekni.com

Анализ и реинжиниринг системы информационной безопасности на предприятии ГУ Банка России (стр. 6 из 9)

Сервис регистрации обеспечивает:

– информирование прикладных процессов о работоспособности сервиса регистрации;

– уникальную идентификацию файлов регистрационных журналов;

– запись регистрационных сообщений в файл оперативного регистрационного журнала с формированием защитных контрольных сумм;

– очистку оперативного журнала с переносом его данных в архивный журнал по команде администратора ИБ, или по наступлению предварительно сконфигурированных событий (по смене дат или по достижению оперативным журналом определенного размера).

Имя файла оперативного регистрационного журнала фиксированное: «syslog.tk». Имена файлов архивных журналов строятся следующим образом

DDMMYYYY_hh-mm_BBBBB_EEEEE.tk,

где:

– DDMMYYYY – календарная дата первой записи журнала;

– hh-mm – время в часах и минутах первой записи журнала;

– BBBBB – контрольная сумма первой записи журнала;

– EEEEE – контрольная сумма последней записи журнала.

В состав каждой регистрационной записи включаются:

– дата (число, месяц, год);

– время;

– имя вычислительной установки (HostName);

– уровень приоритета события (2 – «критическое», 4 – «важное», 6 – «информационное»);

– имя пользователя в операционной системе (UserName);

– номер пользователя по таблице пользователей подсистемы;

– идентификатор задачи, выполнившей регистрацию события;

– идентификатор класса события;

– идентификатор (код) события;

– текстовая строка с параметрами сообщения;

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

Последнее поле регистрационной записи используется для контроля целостности и непрерывности регистрационного журнала. Для первого регистрационного журнала (запуск сервиса регистрации в условиях отсутствия в каталоге файла syslog.tk) контрольная сумма «нулевой» записи принимается равной нулю. При закрытии текущего журнала и открытии нового, последнюю регистрационную запись (которой будет запись об открытии нового файла регистрационного журнала) – сформирует сам сервис регистрации. Эта же запись дублируется (с той же контрольной суммой) в качестве первой записи вновь открываемого оперативного журнала.

Необходимым условием работы прикладных средств регистрации являются функционирование процесса «сервис регистрации». Этот процесс организуется программой task808.ovl, запускаемой в режиме сервиса операционной системы с правами специального пользователя «mservice». Файлы регистрационного журнала ведутся в специально выделяемом каталоге %pathxpress%\syslog\ (путь к нему указывается при конфигурировании сервиса).

Наличие и работоспособность сервиса регистрации проверяется программным обеспечением ПК РКЦ РАБИС-НП при запуске АРМ и отдельных программ. Запуск АРМ и программ блокируется при отсутствии или неработоспособности этого процесса с выдачей соответствующего сообщения. Для корректного обращения процессов АРМ к сервису регистрации, на каждой рабочей станции должна быть определена переменная окружения SERVICES_FILE, указывающая полный путь к файлу, в котором в секции REGSERVER описывается имя серверной установки и номер порта, на которых функционирует сервис регистрации подсистемы.

Отдельная функция проверки работоспособности сервиса регистрации включена в состав АРМ администратора информационной безопасности.

Работа с регистрационным журналом осуществляется на АРМ администратора информационной безопасности подсистемы.

В процессе загрузки файла регистрационного журнала на просмотр выполняется контроль его целостности по контрольным суммам записей. Результат контроля целостности регистрационного журнала выводится на экран («Регистрационный журнал целостен!», или «Целостность регистрационного журнала нарушена, начиная с записи №ХХХ»).

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

В качестве сервисных функций администратора информационной безопасности при работе с регистрационными журналами предусмотрены:

– проверка работоспособности сервера регистрации;

– очистка оперативного регистрационного журнала с переносом его данных в файл архивного регистрационного журнала;

– загрузка на просмотр файла архивного регистрационного журнала.

– контроль целостности регистрационного журнала.

Наряду с ведением прикладного регистрационного журнала, сервис регистрации может выполнять параллельную запись прикладных событий РАБИС-НП в журнал ApplicationLog операционной системы сервера подсистемы (передается текстовая строка в формате регистрационной записи РАБИС-НП, но без контрольной суммы). Необходимость и степень детальности регистрации в системном журнале операционной системы конфигурируются при настройке сервиса регистрации.

5.5. Средства контроля целостности прикладного программного обеспечения подсистем в процессе сопровождения. Паспорта прикладного программного обеспечения АРМ

Концепция контроля целостности прикладного программного обеспечения подсистем УБР, ТУ, ТЦОИ и ОИТУ КЦОИ в процессе сопровождения ТПК РАБИС-НП основана на следующих принципах:

– разработчик ТПК РАБИС-НП предоставляет сведения о составе и характеристиках тиражируемых файлов ПК РКЦ РАБИС-НП непосредственно в составе дистрибутивных материалов и пакетов модификаций (в защищенном технологической подписью разработчика виде);

– штатный инструментарий, используемый администраторами программного обеспечения для модификации программных модулей ПК РКЦ РАБИС-НП, обеспечивает ведение файла контрольного списка (эталонного состояния) исполняемых и ресурсных модулей подсистемы, защищаемого подписью (КА) администратора программного обеспечения;

– штатный инструментарий сопровождения ПК РКЦ РАБИС-НП обеспечивает контроль происхождения и целостности новых версий модифицируемых в процессе сопровождения модулей программного обеспечения по контрольным данным разработчика, и соответствующую актуализацию контрольного списка исполняемых и ресурсных модулей подсистем;

– администраторы программного обеспечения подсистем ответственны за использование штатных средств сопровождения ПК РКЦ и, соответственно, за состояние исполняемых и ресурсных модулей ПК РКЦ РАБИС-НП подсистем, фиксируемое в контрольном списке, защищаемом их подписями (КА);

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

Дистрибутивные материалы ПК РКЦ РАБИС-НП, помимо собственно инсталляционных модулей, включают инструментарий контроля целостности, а также контрольный файл distr_files_V.lst (V – номер версии дистрибутива). Контрольный файл содержит описание состава и контрольных характеристик, исполняемых и ресурсных файлов, которые должны быть получены в результате корректной инсталляции дистрибутивных материалов ПК РКЦ РАБИС-НП. Контрольный файл защищен технологической подписью (в отдельном файле distr_files_V.sgn) разработчика ПК РКЦ (средства технологической подписи, используемые для сопровождения ТПК РАБИС-НП).

В процессе инсталляции сервера подсистемы из дистрибутивных материалов ПК РКЦ РАБИС-НП формируется ядро исполняемой системы ПК РКЦ РАБИС-НП («дерево» подкаталогов и файлов от «корневого» каталога %kernel%) и технологический инструментарий сопровождения ПК РКЦ (в каталоге tools). На завершающем этапе инсталляции выполняется проверка целостности контрольного файла, и целостности сформированных файлов ядра исполняемой системы и инструментария сопровождения по контрольному файлу. Сам контрольный файл дистрибутива вместе с файлом его технологической подписи сохраняются для дальнейшего использования в каталоге %kernel%/control_files/.

Для первого (после установки ПО сервера подсистемы) формирования файла контрольного списка исполняемых и ресурсных модулей подсистемы, должны быть предварительно подготовлены следующие условия:

– должна быть выполнена настройка подсистемы для работы со средствами подписи (КА), применяемыми для защиты электронных сообщений на региональном уровне;

– в подсистеме должен быть зарегистрирован хотя бы один реальный пользователь - администратор ПО,

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

– для администратора ПО должны быть настроены все необходимые параметры для работы с указанными средствами подписи (КА);

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

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

Первое формирование файла контрольного списка исполняемых и ресурсных модулей подсистемы выполняется администратором ПО с помощью программы task835.exe «Применение пакетов модификации», в автоматическом (если программа самостоятельно может установить происхождение, корректность состава и целостность всех программных модулей), или «ручном» (с принятием администратором ПО решений для каждой обнаруживаемой проблемной ситуации) режимах. Сформированный файл контрольного списка исполняемых и ресурсных модулей подсистемы защищается подписью (КА) администратора ПО. Для защиты контрольного файла используются средства подписи (КА), применяемые для защиты электронных сообщений на региональном уровне. Сформированный и подписанный файл контрольного списка исполняемых и ресурсных модулей подсистемы kernel_files.lst размещается в каталоге %kernel%/control_files/. Там же сохраняется его резервная копия с именем kernel_files.cpy.