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


"Алексей Марков, к.т.н., с.н.с.,
Сергей Ермолаев"

Введение

При аттестации распределенных объектов информатизации (ОИ) самым сложным и трудоемким является испытание программных ресурсов (ПР) ОИ по требованиям информационной безопасности (ИБ) [4]. Так, если вопросы спецпрповерок и специсследований аппаратуры, категорирования помещений, защиты отдельного компьютера достаточно проработаны [2,7,9], то задача анализа и контроля защищенности ПР сложных распределенных систем до сих пор не имеет законченного решения.

Особенно актуальными сейчас являются две задачи:

  1. Как в приемлемые сроки и с необходимой степенью достоверности аттестовать весь ПР распределенного ОИ по требованиям ИБ?
  2. 2. Как обеспечить выполнение аттестационных условий при эксплуатации ОИ на фоне динамичности среды и появления новых уязвимостей?

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

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

Под ОИ будем понимать многопользовательскую многомашинную автоматизированную систему (АС) в защищенном исполнении.

Аттестация ОИ представляет собой процесс комплексной проверки выполнения заданных функций АС по обработке защищаемой информации на соответствие требованиям стандартов и/или нормативных документов в области защиты информации и оформления документов о ее соответствий выполнять функции по обработке защищаемой информации (ГОСТ 51583-2000).

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

Согласно Положению по аттестации [6] в части касающейся ПР к ОИ предъявляются требования по защите информации от несанкционированного доступа (НСД), в том числе от компьютерных вирусов.

На практике основным нормативным документом аттестации ПР ОИ является руководящий документ (РД) Гостехкомиссии РФ «АС. Защита от НСД к информации..» от 1992 г. [1]. Однако при испытаниях возможна проверка соответствия требованиям по ИБ, вытекающим из: ГОСТов 51188-89, 51583-00, 51624-00, 51275-99, других РД и СТР/СТР-К Гостехкомисии РФ, внутриведомственных нормативных документов по защите информации, а также, в будущем, задания по безопасности (в соответствии с ГОСТ 15408-02) и технических регламентов.

С учетом [1,6] можно определить основные этапы аттестационных испытаний ПР ОИ по требованиям ИБ:

  1. Идентификация ПР АС;
  2. Проверка подсистемы управления доступом;
  3. Проверка подсистемы регистрации и учета;
  4. Проверка подсистемы обеспечения целостности;
  5. Проверка антивирусной подсистемы;
  6. Анализ возможности выполнения условий аттестации ОИ при его эксплуатации.

Идентификация программных ресурсов автоматизированной системы

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

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

На данном этапе целесообразно провести анализ уязвимости сети с целью корректировки и фиксации обновлений и настроек ОС и приложений.

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

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

В настоящее время достаточно много сканеров уязвимостей представлено на рынке. Выделяется ряд критериев для выбора таких средств: количество реально обнаруживаемых ими уязвимостей (в т. ч. в сервисах, установленные на нестандартных портах), количество ложных срабатываний, удобство пользования сканером (http://www.securitylab.ru/39591.html). Для выявления актуальных угроз очень важным является поддержка регулярных обновлений баз уязвимостей и интеграция по ним с IDS-продуктами. Из общеизвестных сканеров можно выделить следующие.

Продукты компании ISS (Internet Scanner, System Scanner) как полнофункциональные системы анализа защищенности, поддерживающие базу уязвимостей XForce, современные технологии сканирования, технологию клиент-сервер и т.д. [8]. Одна из версий Internet Scanner имела сертификат Гостехкомиссии РФ. К недостаткам относят высокую стоимость, медленность сканирования.

Сетевой сканер Nessus (www.nessus.org) – единственный сканер, сертифицированная версия которого распространяется Гостехкомиссией РФ бесплатно. Серверная часть сканера работает в среде Unix. Nessus предоставляет широкие возможности по поиску уязвимостей сетей и исследованию структуры сетевых сервисов, постоянно обновляется и является одним из самых эффективных сетевых сканеров. Нельзя не сказать об отечественном сетевом сканере - XSpider (Positive Tech.), к сожалению, не сертифицированного. В печати отмечается его эффективность, однако при лаконичности отчетной информации.

В качестве системных сканеров следует выделить средства, поставляемые разработчиками операционных сред, а именно: MSBA для Windows 2000/XP, ASET для Solaris. Сканеры проверяют типовые уязвимости, правильность конфигурации, контролируют целостность файлов, своевременность установки сервисных пакетов операционных сред.

В системах, основанных на промышленных базах данных, могут быть использованы сканеры уязвимости СУБД, например Database Scanner (ISS).

Таким образом, обследовав систему сканерами и получив автоматизированные протоколы, можно решить две задачи:

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

Проверка подсистемы управления доступом

В рамках проверки подсистемы управления доступом контролируются:

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

Возможности проверки осложняются тем, что средств автоматизации поставленной задачи существует очень мало. Такими средствами осуществляется контроль защищенности установленной разрешительной системы доступа для каждого рабочего места (АРМ) АС.

Рассмотрим средства проверки разрешительной системы доступа линеек НКВД (КРДИ) и Ревизор (ЦБИ).

Анализатор уязвимостей НКВД 2.3 – средство автоматизации процесса моделирования системы разграничения доступа (СРД) пользователей к различным объектам доступа (файловые и периферийные ресурсы АРМ и сетевые ресурсы ЛВС). НКВД 2.3 автоматически сканирует ресурсы файловой системы АРМ, а также доступные данному субъекту сетевые ресурсы АС, определяет подключенные к АРМ или доступные в сети периферийные устройства. Результаты сканирования автоматически сохраняются в файле описания структуры и состава объектов доступа АРМ. Используя полученные данные, НКВД 2.3 создает описание логической структуры объектов доступа, отображающее логическую структуру ресурсов файловой системы АРМ, а также сетевых ресурсов и доступных субъекту доступа АРМ периферийных устройств. Сканирование выполняется с терминала администратора АС, имеющего полный доступ ко всем объектам доступа АРМ. НКВД 2.3 выводит на экран монитора АРМ иерархическую структуру объектов доступа АРМ и связанную с ней таблицу полномочий пользователя по отношению к объектам. Установка полномочий пользователя к объектам доступа производиться путем расстановки соответствующих знаков («+» – разрешено, «–» – запрещено) в таблице полномочий. Моделирование СРД выполняется для каждого пользователя АРМ отдельно. Указанное средство используют совместно с НКВД 2.2.

Анализатор уязвимостей НКВД 2.2 – средство автоматизации проверки соответствия полномочий, предоставляемых пользователям СЗИ аттестуемой АС по доступу к объектам доступа, полномочиям пользователей, указанным в модели СРД, разработанной на основе НКВД 2.3. НКВД 2.2 сравнивает данные, полученные после сканирования структуры объектов доступа с данными, указанными в описании модели СРД пользователей к объектам доступа, потом проверяет установленные в модели СРД полномочия пользователей по доступу к объектам доступа на соответствие установленным правилам разрешительной системы доступа. НКВД 2.2 осуществляет проверку реального предоставления пользователям полномочий по доступу к объектам доступа в соответствии с установленными моделью СРД полномочиями. По результатам проверок формируются соответствующие протоколы аттестационных испытаний в виде текстовых файлов.

Ревизор - 1 – средство автоматизации процесса моделирования СРД, аналогичное НКВД 2.3 (рис.1).

R - чтение, W - запись, D - удаление, А - добавить/создать, X - выполнить, С/СС - гриф секретности

Ревизор1

Рис.1. Ревизор 1

Ревизор - 2 – средство автоматизированной проверки соответствия прав пользователей по доступу к защищаемым информационным ресурсам АС, аналогичное НКВД 2.2 (рис.2).

Ревизор2

Рис. 2. Ревизор 2

В общем, указанные средства проверки СРД выполняют одинаковые функции и являются сертифицированными Гостехкомиссией РФ, однако линейка НКВД по функциональным возможностям уступают линейке Ревизоров. При сканировании локальных или сетевых ресурсов Ревизор позволяет выбрать для сканирования конкретный диск, НКВД же сканирует все диски сразу. Кроме того, Ревизор, помимо проверки дискреционного принципа доступа (доступа субъектов доступа к защищаемым ресурсам в соответствии с матрицей доступа), позволяет проверить и мандатный принцип контроля доступа (управление потоками информации с помощью меток конфиденциальности), что принципиально при аттестации ОИ. Еще одно преимущество линейки Ревизор – они работают не только в среде Windows, но и Linux.

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

Проверка подсистемы регистрации и учета

При проверке подсистемы регистрации и учета АС контролируются:

  • регистрация и учет событий средствами установленной СЗИ от НСД на всех этапах технологического процесса обработки и хранения информации;
  • порядок вывода защищаемых материалов на печать;
  • маркировка защищаемых файлов;
  • порядок регистрации и учета носителей секретной информации;
  • и качество очистки освобождаемых областей памяти ПЭВМ.

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

Из сертифицированных средств следует указать только средства контроля очистки памяти: Terrier (ЦБИ), НКВД 2.4, НКВД 2.5 (КРДИ).

Terrier – программа, предназначенная для поиска задаваемых сигнатур на магнитных дисках и CD-ROMах. На жестких магнитных дисках поиск можно задать как по всему физическому диску, так и в пределах логического диска.

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

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

К сожалению, Terrier не позволяет проверить качество очистки оперативной памяти.

Анализатор механизма очистки внешней памяти НКВД 2.4 выполняет следующие действия:

  • выбор файла, для хранения которого выделяется проверяемая область памяти;
  • создание контрольной копии данных;
  • удаление файла с использованием штатных средств АС (освобождение области памяти);
  • сравнение данных, считанных из проверяемой области внешней памяти, с контрольной копией данных (при совпадении данных делается вывод об отсутствии или неработоспособности средств очистки данных);
  • вывод на экран содержимого проверяемой области внешней памяти ЭВМ до и после ее освобождения;
  • формирование отчета о проведенной проверке, вывод его на экран или в файл;
  • восстановление исходного состояния данных АС в области внешней памяти ЭВМ по окончанию проверки.

Анализатор очистки оперативной памяти НКВД 2.5 выполняет следующие действия:

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

К достоинствам средств проверки качества очистки освобождаемых областей памяти НКВД следует отнести простоту использования, автоматизацию процесса проверки и вывод исчерпывающих отчетов о проверке. Недостаток же в том, что указанные средства, в отличие от Terrier, функционируют только в ОС Windows 9x, и, как следствие, даже не воспринимают файловую систему NTFS.

Проверка подсистемы обеспечения целостности

При испытании подсистемы обеспечения целостности АС согласно [1] осуществляются:

  • проверка обеспечения целостности ПО СЗИ от НСД, а также неизменности программной среды;
  • проверка отсутствия в АС средств разработки и отладки программ;
  • проверка проведения периодического тестирования СЗИ от НСД;
  • проверка используемых программ на наличие вирусов;
  • проверка наличия средств восстановления как используемой программной среды и приложений, так и СЗИ от НСД;
  • проверка целостности СЗИ от НСД, в том числе проверка соответствия установленной версии ПО СЗИ.

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

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

В программе ФИКС 2.0 используются три различных алгоритма контрольного суммирования:

  • взвешенное контрольное суммирование;
  • аналог формированию имитовставки по ГОСТ 28147-89 (Уровень-1);
  • аналог формированию контрольной суммы в системе «Аккорд» (Уровень-2).

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

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

Программа расчета контрольных сумм ADINFlst (ДиалогНаука, ADinf DT) аналогично программе ФИКС 2.0 вычисляет для каждого проверяемого файла контрольные суммы и формирует отчет, в котором фиксируются полученные контрольные суммы. Контрольные суммы вычисляются по алгоритму LAN64 (ЛАН Крипто), рассчитываемый по всему файлу. Размерность хэш-функции 64 бит. Особенностью данного типа контрольной суммы является высокая надежность обнаружения случайных изменений в файле, а также невозможность вычисления дополнительных байтов, сохраняющих значение хэш-функции после преднамеренной модификации файла. Достоинство ADINFlst состоит в его малом объеме и функционировании через командную строку, что позволяет максимально быстро и эффективно рассчитать контрольные суммы проверяемого ПР.

Для проверки отсутствия в АС средств разработки и отладки программ предлагается воспользоваться детектором отладки процессов НКВД 3.2, который осуществляет:

  • контроль наличия в ПР средств отладки программного кода и их активности (функционирования);
  • вывод на экран информации об активных процессах программной среды АС, которые на момент контроля находятся в состоянии отладки;
  • формирование отчета о проведенной проверке и ее результате.

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

Недостаток НКВД 3.2 (аналогично прочим продуктам линейки НКВД) состоит в том, что они функционируют только в ОС Windows 9x.

Проверка антивирусной подсистемы

Частично наличие антивирусных средств проверяется на предыдущем этапе. В общем случае указанное испытание включает в себя проверки того, что:

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

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

Со сравнительным анализом антивирусных средств можно ознакомиться на www.virusbtn.com.

В нашей стране известны три сертифицированных антивирусных средства.

Антивирусные системы «Лаборатории Касперского» имеют в своем составе следующие основные компоненты:

  • антивирусный сканер, который позволяет проверять компьютер на присутствие вирусов по запросу пользователя;
  • резидентный антивирусный монитор, который позволяет проверять на присутствие вирусов все запускаемые и открываемые на компьютере файлы;
  • программа для антивирусной защиты электронной почты, которая проверяет на присутствие вирусов все сообщения, принимаемые и отправляемые пользователем;
  • скрипт-блокиратор, который позволяет защитить компьютер от проникновения скрипт-вирусов и «червей», выполняющихся непосредственно в памяти компьютера.

Аналогичные компоненты присутствуют и в другой известной антивирусной программе Dr.Web («СалД»). Все программы Dr.Web построены по модульному принципу, используют одинаковое ядро (engin) и одни и те же вирусные базы.

Интеллектуальный антивирусный программный комплекс Stocona Antivirus (СТОКОНА), сертифицированный ЗАО «НПП «БИТ», предназначен для защиты компьютера от макровирусов и макропрограммных закладок в документах Microsoft Office 97/2000/XP, при обмене сообщениями электронной почты и при просмотре страниц Internet.

Анализ возможности выполнения условий аттестации объекта информатизации при его эксплуатации

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

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

  • технический контроль, который проводят администраторы сети;
  • инспекционный контроль, который проводят эксперты органа по аттестации или испытательной лаборатории.

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

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

Для автоматизированного контроля состояния сертифицированных программных СЗИ имеется сертифицированная программа ФИКС 3.0. ФИКС 3.0 предназначено для выполнения контрольного суммирования и проверки целостности содержимого файлов сертифицированных СЗИ по информации, импортированной из глобальной базы данных (БД) сертифицированных СЗИ Гостехкомиссии РФ.

Основные возможности:

  • считывание и разбор исходных данных, импортированных из БД СЗИ Гостехкомиссии РФ и содержащих сведения об исходном размещении и эталонных контрольных суммах файлов сертифицированных СЗИ;
  • поиск контролируемых файлов на АРМ проверяемого ОИ (в том числе в ЛВС);
  • контроль целостности файлов по эталонным контрольным суммам;
  • формирование отчетов о результатах поиска и контроля целостности файлов СЗИ на ОИ.

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

Из несертифицированных программ, контролирующих версии, отметим следующие.

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

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

Заключение

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

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

Что осталось за рамками данной статьи?

Во-первых, - это средства моделирования и описания ОИ (его структуры, информационных потоков, угроз). Здесь могут быть использованы различные CASE/CAD-системы, а также специализированные продукты анализа рисков [3].

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

Литература

  1. Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем и требования по защите информации. Гостехкомиссия России. - М.: Военное издательство, 1992.
  2. Астахов А. Аттестация автоматизированных систем // Jet Info, 2000 - № 11. - 20 с.
  3. Марков А.С., Миронов С.В., Цирлов В.Л. Разработка политики безопасности организации в свете новейшей нормативной базы // Защита информации. Конфидент, 2004. - №2. – С. 20-28.
  4. Марков А.С., Цибин В.В. К вопросу о сертификации программных ресурсов автоматизированных систем по требованиям безопасности информации // АДЭ, 2004.
  5. Марков А.С., Щербина С.А. Испытания и контроль программных ресурсов // InformationSecurity, 2003. – № 6 – С. 25.
  6. Положение об аттестации объектов информатизации по требованиям безопасности информации. Гостехкомиссия России, 1994.
  7. Просянников Р. Проблемы аттестации автоматизированных систем // Netweek. 2002, - № 9.
  8. Разработка систем информационно-компьютерной безопасности / Зима В.М., Котухов М.М., Ломако А.Г., Марков А.С., Молдовян А.А. – СПб: ВКА им. А.Ф.Можайского, 2003. – 327 с.
  9. Цибин В.В. Теория и практика аттестации объектов информатизации по требованиям безопасности информации – ЗАО «НПП «БИТ», 2000.

Возврат к списку