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

О бязательная оценка соответствия автоматизированных систем (АС) требованиям безопасности информации проводится в форме аттестации объектов информатизации или сертификации средств защиты информации (СЗИ) [1]. Кроме того, процедура оценки соответствия может применяться на этапах приемо-сдаточных испытаний, внутреннего аудита и контроля эффективности защиты информации. Базовым документом, в котором определены требования к подсистемам безопасности АС, является руководящий документ Гостехкомиссии России [2]. Существующие типовые методики аттестационных или сертификационных испытаний носят описательный характер, что затрудняет автоматизацию и оптимизацию процессов оценки соответствия АС. При этом исследования показывают, что более половины средств, выделяемых на разработку АС в защищенном исполнении, тратится именно на этапы испытаний и внедрения системы.

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

Формализованное описание методики проведения испытаний

Под АС, согласно ГОСТ 34.003-90, будем понимать систему, состоящую из персонала и комплекса средств автоматизации его деятельности, реализующую информационную технологию выполнения установленных функций. Таким образом, АС представляет собой совокупность следующих объектов: средства вычислительной техники, программное обеспечение, каналы связи, информация на различных носителях, персонал и пользователи системы, эксплуатационная и организационно-распорядительная документация.

Пусть R = {r₁, r₂,…,r_n} – множество требований, предъявляемых к АС Σ , T = {t₁, t₂,…,t_n} – множество тестовых процедур, проверяющих реализацию требований. Каждая тестовая процедура t_i ∈ T характеризуется следующими элементами: цель выполнения, объекты проверки (факторы оценки соответствия), последовательность выполняемых действий, критерий принятия положительного решения.

Под методом разработки тестовых процедур будем понимать отображение M: Σ × R → T [3]. Функция M на основе

РЛХЛ = \

^.',) =

требования r_i ∈ R и информации о реализации АС Σ, подлежащего процедуре оценки соответствия, выполняет генерацию тестовой процедуры t_i ∈ T , выполняемой для проверки удовлетворения АС требованию r_i ∈ R . Отметим, что функция M для данной АС Σ является биективным отображением.

Введем операторы выполнения требования F_R и корректности выполнения тестовой процедуры F_C для данных Σ, r i t i .

Оператор выполнения требования r_i для АС Σ F_R : Σ × R → {0,1} :

• 1,    требование г( выполнено для АС Е , О, в противном случае.

Оператор корректности выполнения тестовой процедуры t i для АС Σ F C : Σ × T → {0,1} :

• 1    ,тест t, выполнен успешно для АС Е , О, в противном случае.

Методикой оценки соответствия АС назовем набор из пяти объектов A = { Σ , R, M, F_R, F_C} , где R - множество требований, предъявляемых к AC Σ, M ‒ метод разработки тестовых процедур, F_R и F_C –операторы выполнения требования и корректности выполнения тестовой процедуры соответственно, а также для ∀ r_i ∈ R справедливо F_R( Σ ,r_i) ⇒ F_C( Σ , M( Σ ,r_i)) .

Методика предусматривает наличие трех стадий: планирование , тестирование и анализ результатов .

На стадии планирования выполняется анализ документации и особенностей работы АС. Перед началом проведения тестирования эксперты должны установить, что в документации на объект испытаний (например, в задании по безопасности на АС) декларируется соответствие АС требованиям R , то есть F_R( Σ ,r_i) = 1 для ∀ r_i ∈ R . На основании данных, полученных в ходе анализа документации, тестовых запусков АС и предъявляемых требований, формируется множество тестовых процедур T = {t₁, t₂,…,t_n} , где t_i = M( Σ ,r_i) .

Тестирование АС выполняется с использованием набора тестовых процедур T = {t₁, t₂,…,t_n} . В результате тестирования для каждой тестовой процедуры определяются результаты выполнение тестовой процедуры t_i ∈ T , подлежащие регистрации. При проведении оценки соответствия АС, как правило, применяются следующие методы: экспертнодокументальный метод, метод опроса и инструментальный метод.

На стадии анализа фактических и эталонных значений получают множество упорядоченных пар вида (t_i, FC( Σ ,r_i)) . Для АС Σ декларируется соответствие требованиям R = {r₁, r₂,…, r_n} , если:

то есть в ходе проведения испытаний установлено соответствие реальных возможностей АС по декларируемым в документации или нормативном документе [1, 2].

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

Руководящий документ Гостехкомиссии России [2] устанавливает классификацию АС, подлежащих защите от несанкционированного доступа (НСД) к информации, и задаeт требования по защите информации в АС различных классов. Рассмотрим формализованный порядок проверки для следующих наиболее ресурсоемких требований R_IS = {r₁, r₂, r₃} :

• ♦    требование r 1 : должна осуществляться идентификация и проверка подлинности субъектов доступа при входе в систему по идентификатору (коду) и паролю условнопостоянного действия, длиной не менее шести буквенноцифровых символов;

• ♦    требование r₂ : должен осуществляться контроль доступа субъектов к защищаемым ресурсам в соответствии с матрицей доступа;

• ♦    требование r₃ : должна быть обеспечена целостность программных средств защиты информации (СЗИ) от НСД, а также неизменность программной среды.

Перед началом проведения тестирования эксперты должны установить, что в технической документации (например, в задании по безопасности на АС) на объект испытаний декларируется соответствие АС требованиям R_IS , то есть F R (Σ,r i ) = 1 для ∀ r i ∈ R IS .

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

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

Введем определения, используемые при описании тестовой процедуры. Пусть A ‒ алфавит паролей и идентификаторов субъектов доступа (пользователей АС). Обозначим идентификатор пользователя id ∈ ID ⊆ A* , пароль – pwd ∈ PWD ⊆ A* . Учетная запись субъекта доступа s_i ∈ S характеризуется следующим кортежем s_i = (id j , pwd_k) . Введем оператор корректности учетных данных F_AUT : S → {0, 1} :

{ 1, выполнен вход в систему, О,в противном случае.

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

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

  
  
  

• ♦    требования к сложности паролей (длина, сложность);

• ♦    обязанности администратора безопасности по реализации парольной политики АС (генерация паролей, распределение паролей);

• ♦    обязанности пользователей по реализации парольной политики АС (генерация паролей, смена паролей);

• 2)    определить установленные СЗИ от НСД в АС значения для следующих параметров: минимальная длина пароля, сложность пароля (алфавит паролей), максимальный срок действия пароля, максимальное число неудачных попыток входа пользователей в АС, после которого осуществляется блокировка работы пользователя, реакция АС на превышение максимального числа неудачных попыток входа пользователя; произвольным образом выбрать несколько АРМ и выполнить запросы на идентификацию и проведение аутентификации с использованием различных сочетаний учетных данных: зарегистрированный/незарегистрированный идентификатор, верный/неверный пароль try_i = (id j , pwd_k) ;

• 3)    под учетными записями пользователей произвести попытки установить пароль, не соответствующий нормативным требованиям [2], для этого осуществить:

• ♦    попытку установить пароль, длина которого менее 6 символов;

• ♦    попытку установить пароль, состоящий исключительно из цифр, либо только из букв.

Результатами выполнения тестовой процедуры, подлежащей регистрации, являются:

• 1)    положения документации на АС относительно реализации и сопровождения системы парольной защиты;

• 2)    конфигурация СЗИ от НСД АС в части реализации парольной защиты;

• 3)    полученные результаты тестовых запросов на идентификацию и аутентификации – множество {F_AUT (try₁), F_AUT (try₂),…} .

• 4)    полученные результаты тестовых попыток изменения паролей.

В данном случае критериями принятия положительного решения являются следующие.

• 1.    В нормативных документах организации, эксплуатирующей АС, установлены требования (сложность, минимальная длина) к паролям пользователей рассматриваемой АС соответствующие нормативным требованиям [2].

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

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

• 4.    После ввода зарегистрированного идентификатора и пароля пользователю предоставляется доступ к АС: F AUT (try i ) = 1 ⇔ try i ∈ S .

• 5.    После ввода незарегистрированного идентификатора и/ или неверного пароля пользователю отказывается в доступе к АС: F_AUT (try_i) = 0 ⇔ try_i ∈ S .

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

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

Целью проверки является определение степени соответствия фактических настроек системы дискреционного разграничения доступа требуемым настройкам, определенным в матрице доступа. Исходными данными для формирования тестовой процедуры являются: множество возможных субъектов доступа S = {S₁, S₂,…} , множество защищаемых объектов O = {O₁, O₂,…} , конечное множество прав доступа P = {P₁, P₂,…} и матрица доступа.

Последовательность выполняемых действий следующая.

• 1.    Идентификация субъектов (например, пользователей)

• 2.    Идентификация матрицы доступа субъектов к защищаемым объектам.

• 3.    Для каждой тройки (S_i, O j , P_k) ∈ S × O × P выполнение тестирования фактического наличия права P_k у субъекта S_i по отношению к объекту O j (тестирование настроек СЗИ АС).

• 4.    Сравнение фактических прав доступа с требуемыми правами, определенными в матрице доступа.

S = {S₁, S₂,…} , и объектов доступа (например, объектов файловой системы) O = {O₁, O₂,…} .

Результаты выполнения тестовой процедуры, подлежащие регистрации:

• 1)    матрица доступа субъектов к защищаемым объектам;

• 2)    фактические результаты тестирования системы дискреционного разграничения доступа.

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

Частная методика проверки механизмов контроля целостности

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

Пусть FILE = {file₁, file₂, …, file_g} ‒ множество файлов СЗИ от НСД (конфигурационные файлы, программные модули). Введем операторы нарушения целостности F_MOD и контроля целостности файлов СЗИ от НСД F_INT .

Оператор нарушения целостности F_MOD : FILE → {0, 1} :

FmoiAW^

целостность файла нарушена при проведении испытаний,

О, в противном случае.

Оператор контроля целостности файлов СЗИ от НСД F_INT FILE → {0, 1} :

F (file) = INT           J

зафиксировано нарушение целостности файла,

О, в противном случае.

Обозначим

‒ множество файлов СЗИ от НСД, модифицированных в ходе проведения испытания. При этом выполняется модификация файла filei в файл fileiΔ. При проверке корректности реализации механизма контроля целостности может быть использована следующая последовательность выполняемых действий.

• 1.    Идентификация множества файлов СЗИ от НСД FILE = {file 1 , file 2 , …} .

• 2.    Внесение изменений в файлы (изменение конфигурации, подмена (модификация) исполняемых файлов и т. п.) – получение множества измененных файлов FILE^Δ = {file 1 ^Δ, file 2 ^Δ, …} .

• 3.    Инициализация проверки целостности файлов СЗИ от НСД (создание условий, при которых СЗИ от НСД осуществляет контроль целостности).

• 4.    Анализ реакции СЗИ от НСД на нарушение целостности своей программной или информационной части.

Результаты выполнения тестовой процедуры, подлежащие регистрации: 1) множество файлов

FILE ={file 1 , file 2 , …} ;

• 2)    множество модифицированных файлов FILE^Δ = ={file₁^Δ, file₂^Δ, …} ;

• 3)    реакции СЗИ от НСД на нарушение целостности: F INT (file 1 ^Δ), F INT (file 2 ^Δ), …, F INT (file g ^Δ) .

Критерием принятия положительного решения является то, что СЗИ от НСД обнаружены все факты нарушения целостности:

F INT (file i ) = F MOD (file i ^Δ) .

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

Из представленных частных методик следует, что основной проблемой, с которой сталкиваются организации при проведении оценки соответствия, является рост временных и материальных затрат. Например, при проведении проверки механизма дискреционного разграничения доступа необходимо выполнить |S|·|O|·|P| типовых операций. В общем случае можно показать, что время τ _Σ, затрачиваемое на проведение испытаний, носит экспоненциальный характер роста:

τΣ ~n · vW, где n – число проверяемых требований, w ‒ число факторов тестирования (например, «учетная запись пользователя»), v – число возможных значений фактора тестирования.

Задача оптимизации процедуры проведения оценки соответствия АС может быть сформулирована следующим образом. Пусть τ_Σ : T × Σ → Nq – время, затрачиваемое экспертами на выполнение оценки соответствия АС Σ с использованием тестовой процедуры t_i . Пусть отображение вида C : R × Σ → Nq – затраты на проведение оценки соответствия АС Σ требованиям R . Задача оптимизации может выглядеть следующим образом (минимизация времени тестирования при ограничениях на затраты):

^^(/^Z) —> min,