Неизвестная уязвимость функции printf

Статья была опубликована в журнале

"Машинная программа выполняет то, что вы ей приказали делать, а не то, что бы вы хотели, чтобы она делала".

Третий закон Грида

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

У разработчиков существует шутливое высказывание: "Программ без ошибок не бывает. Бывает – плохо искали". Пример программы, приведенной ниже, позволяет убедиться, насколько эта шутка порой близка к истине. На первый (и даже на второй!) взгляд здесь нет ни одной ошибки, способной привести к несанкционированному вторжению в систему.

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

#include <string.h>

void main() { FILE *psw; char buff[32]; char user[16]; char pass[16]; char _pass[16];

printf("printf bug demo\n"); if (!(psw=fopen("buff.psw","r"))) return; fgets(&_pass[0],8,psw);

printf("Login:");fgets(&user[0],12,stdin); printf("Passw:");fgets(&pass[0],12,stdin);

if (strcmp(&pass[0],&_pass[0])) sprintf(&buff[0],"Invalid password: %s",&pass[0]); else sprintf(&buff[0],"Password ok\n");

printf(&buff[0]);

}

Неуловимость допущенной ошибки объясняется психологической инерцией мышления: вместо тщательного анализа кода к нему последовательно примеряются типовые штаммы и шаблоны. Если ни один из них не подходит, – программа считается защищенной.
Комизм ситуации заключается в том, что некоторые вещи настолько привычны, что перестают обращать на себя внимание, и мысль проверить их, просто не приходит в голову.

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

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

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

Такую ситуацию позволяет продемонстрировать следующий пример: “main(){int a=0xa;int b=0xb;printf("%x %x\n",a);}”, в котором присутствует один "беспарный" спецификатор “%x”. Поскольку содержимое стека на момент вызова функции “printf” зависит от используемого компилятора, то поведение данного кода неопределенно. Например, результат работы программы, полученной с помощью Microsoft Visual C++ 6.0, выглядит так: “a b”

Функция вывела два числа, несмотря на то, что ей передавали всего одну переменную “a”. Каким же образом она сумела получить содержимое переменной “b”? Ответить на этот вопрос поможет дизассемблирование машинного кода программы, в результате которого удается установить содержимое стека на момент вызова функции printf (сам дизассемблерный листинг в журнальном варианте статьи опущен, полный текст содержится в книге "Техника сетевых атак", которую планируется выпустить в скором будущем):

off aXX ('%x %x') (строка спецификаторов) var_4 ('a') (аргумент функции printf)

var_8 ('b') (локальная переменная) var_4 ('a') (локальная переменная)

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

Для поддержки функций с переменным количеством аргументов в языке Си был принят обратный порядок заталкивания параметров в стек, т.е. самый левый аргумент заносится в последнюю очередь и оказывается на верхушке стека. Было бы замечательно, если бы компилятор напоследок передавал бы функции число используемых аргументов или, по крайней мере, сообщал бы их суммарный размер (тем более, что технически в этом нет ничего затруднительного). Но, увы! Разработчики языка не реализовали такой механизм, и отсюда следует неутешительное заключение о принципиальной невозможности защиты содержимого стека материнской функции. Дочерняя функция может беспрепятственно обращаться к любой ячейке стека – от верхушки до самого низа, читая как "свои", так и "чужие" данные.

При вызове “printf("%x %x\n",a)“ функция извлекает из стека на одно слово больше, чем было ей передано, и в результате происходит вторжение в область памяти, занятой локальными переменными материнской функции. Переменная “b” принимается за аргумент функции и выводится на экран. (В зависимости от используемого компилятора в заданном месте стека может оказаться все что угодно, например переменная “a”, сохраненные значения регистров общего назначения, "черная дыра" – область памяти, отведенная для выравнивания данных и т.д.).

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


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

В тех случаях, когда функция printf используется для вывода единственной символьной строки, строку спецификаторов обычно опускают, т.е. вместо “printf (“%s”, &buff[0])” пишут “printf(&buff[0])”. На первый взгляд обе формы записи равносильны, но это не так! Самый левый аргумент всегда проверяется функцией printf на наличие спецификаторов, даже если он передан функции в единственном числе. Поэтому использовать его для вывода строки можно в том и только том случае, когда она гарантированно не содержит никаких "внеплановых" спецификаторов, в противном случае, работа приложения окажется нестабильной. Особенно опасно полагаться на отсутствие спецификаторов в данных, введенных пользователем, и недопустимо передавать их функции printf в первом слева аргументе.

Возможные последствия такого подхода позволяет продемонстрировать программа, приведенная в начале статьи: если злоумышленник введет вместо пароля один или несколько спецификаторов, на экране появится содержимое локальных переменных, в том числе и буфера, хранящего эталонный пароль. Компилятор Microsoft Visual C++ 6.0 располагает этот буфер на вершине стека и просмотреть его можно следующим образом (предполагается, что файл “buff.psw” содержит строку “K98PN*”):

printf bug demo Login:kpnc Passw:%x %x %x Invalid password: 5038394b a2a4e 2f4968

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



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


Такое поведение объясняется тем, что, встретив спецификатор “%s”, функция printf ожидает увидеть указатель на строку, но не саму строку. В результате происходит обращение по адресу 0x5038384B (“K98PN” в символьном представлении), который находится вне пределов досягаемости программы, что и вызывает исключение.

Спецификатор “%s” пригоден для отображения содержимого указателей, ссылающихся на строки или другие читабельные структуры данных. Его использование продемонстрировано в следующем примере:

#include <stdio.h>

#include <string.h>

#include <malloc.h>

void main() { FILE *f; char *pass; char *_pass; pass= (char *)malloc(100); _pass=(char *)malloc(100); if (!(f=fopen("buff.psw","r"))) return; fgets(_pass,100,f); _pass[strlen(_pass)-1]=0; printf("Passw:");fgets(pass,100,stdin); pass[strlen(pass)-1]=0; // Код, проверяющий истинность пароля, введенного // пользователем, для упрощения понимания, опущен printf(pass); }

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

В приведенном примере указатель _pass оказался расположен на верхушке стека, поэтому использование спецификатора “%s” приводит к выводу на экран эталонного пароля, в чем позволяет убедиться следующий эксперимент:

Passw:%s K98PN*

Используя спецификатор “%s”, необходимо доподлинно знать, в каком именно месте стека находится искомый указатель. В противном случае произойдет обращение к незапланированной области памяти. Большинство локальных переменных, находящихся в стеке, содержат значения, не превышающие 0x40000, поэтому попытка использовать их в качестве указателя под операционной системой Microsoft Windows NT приведет к исключению.


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

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

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

Однако существует механизм, позволяющий прочитать содержимое практически любой ячейки памяти независимо от ее местоположения (разумеется, при условии, что приложение обладает правами на ее чтение). Если строка, введенная пользователем, помещается в стек (а именно так чаще всего и происходит), существует возможность "вручную" сформировать требуемый указатель и затем вывести строку, на которую он ссылается посредством спецификатора “%s”.



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

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

Описанную выше уязвимость можно было бы отнести к забавным курьезам, если бы она ограничивалась одной лишь функцией printf. Но функции с переменным количеством аргументом – не редкость в программистской практике, и многие из них используют ненадежные алгоритмы определения числа переданных параметров. Кроме того, существует множество "швейцарских" функций многоцелевого назначения. Например, функция “open” языка Perl в зависимости от символов, содержащихся в имени файла, может не только открывать файлы, но и запускать другие приложения, клонировать манипуляторы, выдавать содержимое директории и т.д.

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

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


Такая путаница объясняется тем, что термин "машинное слово" в одних случаях равен разрядности процессора, а в других приравнивается к двум байтам. Поэтому использование nargs порождает совершенно непереносимый код, работоспособность которого может быть нарушена даже изменением некоторых опций компилятора!

Некоторые разработчики предлагают собственный вариант реализации nargs, который сводится к следующему алгоритму: из стека извлекается адрес возврата из функции и, исходя из предположения, что он указывает на команду наподобие ADD SP, xx, производится попытка определить значение ‘xx’, равное количеству байт, помещенных в стек перед вызовом функции. Недостатки такого приема следующие: он не переносим на отличные от Intel 80x86 платформы; современные компиляторы ведут себя не так, как пять-десять лет назад, и генерируют чрезвычайно запутанный код, допускающий дисбаланс стека на некотором промежутке, отчего процедура анализа количества переданных функции аргументов по сложности приближается к самому компилятору.

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

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

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

1 Здесь и далее первый аргумент функции printf называется "строкой спецификаторов", а все последующие "переменными"   

2 Ну чем не трюк для соревнований в "магическом программировании"?   

3 Базовый адрес загрузки большинства приложений равен 0x400000   

4 Спецификатор "%f" "съедает" восемь байт, но сам занимает два байта, таким образом, в ста байтах вводимой строки можно расположить не более пятидесяти спецификаторов "%f", которые выведут четыреста байт.   

5 Тем самым он откроет доступ к коду и данным 32-разрядных приложений, исполняющихся под управлением операционной системы Windows NT, поскольку большинство из них расположено в памяти по адресу выше 0x00401000   

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

Сергей Петренко, Сергей Симонов, &laquoIT Manager&raquo, #3/2003

Понятия «оценка рисков» (Risk Assessment) и «управление рисками» (Risk Management) появились сравнительно недавно и сегодня вызывают постоянный интерес специалистов в области обеспечения непрерывности бизнеса (Business Continuity) и сетевой безопасности (Network Security). Примерно с 1995 года в ряде высокотехнологичных стран мира, главным образом в США, Великобритании, Германии и Канаде, проводятся ежегодные слушания специально созданных комитетов и комиссий по вопросам управления информационными рисками. Подготовлено более десятка различных стандартов и спецификаций, детально регламентирующих процедуры управления информационными рисками, среди которых наибольшую известность приобрели международные спецификации и стандарты ISO 17799­2002 (BS 7799), GAO и FISCAM, SCIP, NIST, SAS 78/94 и COBIT. Насколько методики и технологии управления информационными рисками могут быть полезны для вашей компании? Давайте посмотрим вместе.

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

Не секрет, что сегодня наблюдается повсеместное усиление зависимости успешной бизнес­деятельности отечественных компаний от используемых организационных мер и технических средств контроля и уменьшения риска. Для эффективного управления информационными рисками разработаны специальные методики, например методики международных стандартов ISO 15408, ISO 17799 (BS7799), BSI; а также национальных стандартов NIST 800­30, SAC, COSO, SAS 55/78 и некоторые другие, аналогичные им. В соответствие с этими методиками управление информационными рисками любой компании предполагает следующее. Во­первых, определение основных целей и задач защиты информационных активов компании. Во­вторых, создание эффективной системы оценки и управления информационными рисками. В­третьих, расчет совокупности детализированных не только качественных, но и количественных оценок рисков, адекватных заявленным целям бизнеса. В­четвертых, применение специального инструментария оценивания и управления рисками. Давайте рассмотрим некоторые качественные и количественные международные методики управления информационными рисками, обращая основное внимание на возможность их адаптации и применения в оте­чественных условиях.

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

Качественные методики управления рисками приняты на вооружение в технологически развитых странах многочисленной армией внутренних и внешних IT­аудиторов. Эти методики достаточно популярны и относительно просты, и разработаны, как правило, на основе требований международного стандарта ISO 17799­2002. История развития которого началась в 1993 году, когда Министерство торговли Великобритании опубликовало пособие, посвященное практическим аспектам обеспечения информационной безопасности (ИБ). Пособие оказалось настолько удачным, что его стали использовать администраторы безо­пасности многих организаций. Позже доработанная версия этого пособия была принята в качестве британского стандарта BS7799 «Практические правила управления информационной безопасностью» (1995).


Стандарт стали применять на добровольной основе не только в Великобритании, но и в других странах. В 1998 году вышла вторая часть стандарта, посвященная вопросам аудита информационной безопасности. В 2000 году был принят международный стандарт ISO 17799, в основу которого был положен BS7799. В сентябре 2002 года основные положения ISO 17799 были пересмот­рены и дополнены с учетом развития современных информационных технологий и требований к организации режима ИБ. Сегодня это наиболее распространенный стандарт во всем мире среди организаций и предприятий, которые используют подобные стандарты на добровольной основе.

Стандарт ISO 17799 содержит две части.

В Части 1: Практические рекомендации по управлению информационной безо­пасностью, 2002 г., определены основные аспекты организации режима информационной безопасности в компании:

• Политика безопасности.

• Организация защиты.

• Классификация и управление информационными ресурсами.

• Управление персоналом.

• Физическая безопасность.

• Администрирование компьютерных систем и сетей.

• Управление доступом к системам.

• Разработка и сопровождение систем.

• Планирование бесперебойной работы организации.

• Проверка системы на соответствие требованиям ИБ.

Часть 2: Спецификации, 2002 г., рассматривает эти же аспекты с точки зрения сертификации режима информационной безопасности компании на соответствие требованиям стандарта. С практической точки зрения эта часть является инструментом для IT­аудитора и позволяет оперативно проводить внутренний или внешний аудит информационной безопасности любой компании.

К качественным методикам управления рисками на основе требований ISO 17999 относятся методики COBRA и RA Software Tool. Давайте кратко рассмот­рим названные методики.

COBRA

Во второй половине 90­х годов компания C & A Systems Security Ltd. разработала одноименные методику и соответствующий инструментарий для анализа и управления информационными рисками под названием COBRA. Эта методика позволяет выполнить в автоматизированном режиме простейший вариант оценивания информационных рисков любой компании.


Для этого предлагается использовать специальные электронные базы знаний и процедуры логического вывода, ориентированные на требования ISO 17799. Существенно, что при желании перечень учитываемых требований можно дополнить различными требованиями отечественных нормативно­регулирующих органов, например, требованиями руководящих документов (РД) Гос­техкомиссии при Президенте РФ.

Методика COBRA представляет требования стандарта ISO 17799 в виде тематических вопросников (check list’s), на которые следует ответить в ходе оценки рисков информационных активов и электронных бизнес­транзакций компании (). Далее введенные ответы автоматически обрабатываются,и с помощью соответствующих правил логического вывода формируется итоговый отчет c текущими оценками информационных рисков компании и рекомендациями по их управлению.

RA Software Tool

Методика и одноименное инструментальное средство RA Software Tool () основаны на требованиях международных стандартов ISO 17999 и ISO 13335 (части 3 и 4), а также на требованиях некоторых руководств Британского национального института стандартов (BSI), например, PD 3002 (Руководство по оценке и управлению рисками), PD 3003 (Оценка готовности компании к аудиту в соответствии с BS 7799), PD 3005 (Руководство по выбору системы защиты) и пр.

Эта методика позволяет выполнять оценку информационных рисков (модули 4 и 5) в соответствии с требованиями ISO 17799, а при желании в соответствии с более детальными спецификациями руководства PD 3002 Британского института стандартов.

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

Вторую группу методик управления рисками составляют количественные методики, актуальность которых обу­словлена необходимостью решения различных оптимизационных задач, которые часто возникают в реальной жизни. Суть этих задач сводится к поиску единственного оптимального решения, из множества существующих. Например, необходимо ответить на следующие вопросы: «Как, оставаясь в рамках утвержденного годового (квартального) бюджета на информационную безопасность, достигнуть максимального уровня защищенности информационных активов компании?» или «Какую из альтернатив построения корпоративной защиты информации (защищенного WWW сайта или корпоративной E­mail) выбрать с учетом известных ограничений бизнес­ресурсов компании?» Для решения этих задач и разрабатываются методы и методики количественной оценки и управления рисками на основе структурных и реже объектноориентированных методов системного анализа и проектирования (SSADM — Structured Systems Analysis and Design).


На  практике такие методики управления рисками позволяют:

• Создавать модели информационных активов компании с точки зрения безопасности;

• Классифицировать и оценивать ценности активов;

• Составлять списки наиболее значимых угроз и уязвимостей безопасности;

• Ранжировать угрозы и уязвимости безопасности;

• Обосновывать средства и меры контроля рисков;

• Оценивать эффективность/стоимость различных вариантов защиты;

• Формализовать и автоматизировать процедуры оценивания и управления рисками.

Одной из наиболее известных методик этого класса является методика CRAMM.

CRAMM

В 1985 году Центральное агентство по компьютерам и телекоммуникациям (CCTA) Великобритании начало исследования существующих методов управления информационной безопасностью для выдачи рекомендаций по их использованию в правительственных организациях, обрабатывающих конфиденциальную информацию. Ни один из рассмотренных методов не подошел.Поэтому сначала был создан метод, а затем одноименная методика CRAMM (анализа и контроля рисков), соответствующая требованиям CCTA. Затем появилось несколько версий методики, ориентированных на требования различных государственных и коммер­ческих организаций и структур. Одна из версий «коммерческого профиля» широко распространилась на рынке средств защиты информации.

Основными целями методики CRAMM являются:

• Формализация и автоматизация процедур анализа и управления рисками;

• Оптимизация расходов на средства контроля и защиты;

• Комплексное планирование и управ­ление рисками на всех стадиях жизненного цикла информационных систем;

• Сокращение времени на разработку и сопровождение корпоративной системы защиты информации;

• Обоснование эффективности предлагаемых мер защиты и средств контроля;

• Управление изменениями и инциден­тами;

• Поддержка непрерывности бизнеса;

• Оперативное принятие решений по вопросам управления безопасностью и пр.

Управление рисками в методике СRAMM осуществляется в несколько этапов (рис. 3).



На первом этапе инициации — «Initiation» — определяются границы исследуемой информационной системы компании, состав и структура ее основных информационных активов и транзакций.

На этапе идентификации и оценки ресурсов — «Identification and Valuation of Assets» — четко идентифицируются активы и определяется их стоимость. Расчет стоимости информационных активов однозначно позволяет определить необходимость и достаточность предлагаемых средств контроля и защиты.

На этапе оценивания угроз и уязвимостей — «Threat and Vulnerability Assessment» — идентифицируются и оцениваются угрозы и уязвимости информационных активов компании.

Этап анализа рисков — «Risk Analysis» — позволяет получить качественные и количественные оценки рисков.

На этапе управления рисками — «Risk management» — предлагаются меры и средства уменьшения или уклонения от риска.

Давайте рассмотрим возможности CRAMM на следующем примере. Пусть проводится оценка информационных рисков следующей корпоративной информационной системы (рис. 4).



В этой схеме условно выделим следующие элементы системы:

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

• почтовый сервер, на который информация поступает с удаленных узлов сети через Интернет;

• сервер обработки, на котором установлена СУБД;

• сервер резервного копирования;

• рабочие места группы оперативного реагирования;

• рабочее место администратора безопасности;

• рабочее место администратора БД.

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

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

Определение границ исследования. Этап начинается с решения задачи определения границ исследуемой системы.


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

Идентификация ресурсов и построение модели системы с точки зрения ИБ. Проводится идентификация ресурсов: материальных, программных и ин­формационных, содержащихся внутри границ системы. Каждый ресурс необходимо отнести к одному из предопределенных классов. Классификация физических ресурсов приводится в приложении. Затем строится модель информационной системы с точки зрения ИБ. Для каждого информационного процесса, имеющего самостоятельное значение с точки зрения пользователя и называемого пользовательским сервисом (End­User­Service), строится дерево связей используемых ресурсов. В рассматриваемом примере будет единственный подобный сервис (рис. 5). Построенная модель позволяет выделить критичные элементы.

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

• недоступность ресурса в течение определенного периода времени;

• разрушение ресурса — потеря информации, полученной со времени последнего резервного копирования или ее полное разрушение;

• нарушение конфиденциальности в случаях несанкционированного доступа штатных сотрудников или посторонних лиц;

• модификация рассматривается для случаев мелких ошибок персонала (ошибки ввода), программных ошибок, преднамеренных ошибок;

• ошибки, связанные с передачей информации: отказ от доставки, недоставка информации, доставка по неверному адресу.

Для оценки возможного ущерба предлагается использовать следующие критерии:

• ущерб репутации организации;



• нарушение действующего законодательства;

• ущерб для здоровья персонала;

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

• финансовые потери от разглашения информации;

• финансовые потери, связанные с восстановлением ресурсов;

• потери, связанные с невозможностью выполнения обязательств;

• дезорганизация деятельности.

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

Для данных и программного обеспечения выбираются применимые к данной ИС критерии, дается оценка ущерба по шкале со значениями от 1 до 10.

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

Возможен такой ответ: провал сразу по нескольким параметрам из перечисленных выше, причем каждый аспект следовало бы рассмотреть подробнее и присвоить самую высокую из возможных оценок.

Затем разрабатываются шкалы для выбранной системы параметров. Они могут выглядеть следующим образом.

Ущерб репутации организации:

2 — негативная реакция отдельных чиновников, общественных деятелей;

4 — критика в средствах массовой информации, не имеющая широкого общественного резонанса;

6 — негативная реакция отдельных депутатов Думы, Совета Федерации;

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

10 — негативная реакция на уровне Президента и Правительства.

Ущерб для здоровья персонала:

2 — минимальный ущерб (последствия не связаны с госпитализаций или длительным лечением);

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



6 — серьезные последствия ( длительная госпитализация, инвалидность одного или нескольких сотрудников);

10 — гибель людей.

Финансовые потери, связанныес восстановлением ресурсов:

2 — менее $1000;

6 — от $1000 до $10 000;

8 — от $10 000 до $100 000;

10 — свыше $100 000.

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

2 — отсутствие доступа к информации до 15 минут;

4 — отсутствие доступа к информации до 1 часа;

6 — отсутствие доступа к информации до 3 часов;

8 — отсутствие доступа к информации от 12 часов;

10 — отсутствие доступа к информации более суток.

Далее рассматриваются основные сценарии, приводящие к различным негативным последствиям, описываемым в терминах выбранных параметров ().

На этом этапе может быть подготовлено несколько типов отчетов (границы системы, модель, определение ценности ресурсов). Если ценности ресурсов низкие, можно использовать базовый вариант защиты. В таком случае исследователь может перейти от этой стадии сразу к стадии анализа рисков. Однако для адекватного учета потенциального воздействия какой­либо угрозы, уязвимости или комбинации угроз и уязвимостей, которые имеют высокие уровни, следует использовать сокращенную версию стадии оценки угроз и уязвимостей. Это позволяет разработать более эффективную систему защиты информации компании.

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

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

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



Уровень угроз оценивается, в зависимости от ответов, как:

• очень высокий;

• высокий;

• средний;

• низкий;

• очень низкий.

Уровень уязвимости оценивается, в зависимости от ответов, как:

• высокий;

• средний;

• низкий;

• отсутствует.

Возможно проведение коррекции результатов или использование других методов оценки. На основе этой информации рассчитываются уровни рисков в дискретной шкале с градациями от 1 до 7 (этап анализа рисков). Полученные уровни угроз, уязвимостей и рисков анализируются и согласовываются с заказчиком. Только после этого можно переходить к заключительной стадии метода.

Управление рисками. Основные шаги стадии управления рисками представлены на рис. 9.



На этом этапе CRAMM генерирует несколько вариантов мер противодействия, адекватных выявленным рискам и их уровням. Контрмеры разбиваются на группы и подгруппы по следующим категориям:

• Обеспечение безопасности на сетевом уровне.

• Обеспечение физической безопасности.

• Обеспечение безопасности поддерживающей инфраструктуры.

• Меры безопасности на уровне системного администратора.

В результате выполнения данного этапа формируется несколько видов отчетов.

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

Методика MethodWare

Компания MethodWare разработала свою собственную методику оценки и управления рисками и выпустила ряд соответствующих инструментальных средств. К этим средствам относятся:

• ПО анализа и управления рисками Operational Risk Builder и Risk Advisor. Методика соответствует австралийскому стандарту Australian/New Zealand Risk Management Standard (AS/NZS 4360:1999) и стандарту ISO17799.



• ПО управления жизненным цик­лом информационной технологии в соответствии с CobiT Advisor 3rd Edition (Audit) и CobiT 3rd Edition Management Advisor. В руководствах CobiT существенное место уделяется анализу и управлению рисками.

• ПО для автоматизации построения разнообразных опросных листов Questionnaire Builder.

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

Описание контекста. На этапе описания контекста описывается модель взаимодействия организации с внешним миром в нескольких аспектах: стратегическом, организационном, бизнес­цели, управление рисками, критерии. Стратегический аспект описывает сильные и слабые стороны организации с внешних позиций, варианты развития, классы угроз и отношения с партнерами. Организационный контекст описывает отношения внутри организации: стратегию, цели на организационном уровне, внутреннюю политику. Контекст управления рисками описывает концепцию информационной безопасности. Контекст бизнес­целей — основные бизнес­цели. Критерии оценки — критерии оценки, используемые при управлении рисками.

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

Описание угроз. В начале формируется список угроз.


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

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

Анализ результатов. В результате построения модели можно сформировать подробный отчет (около 100 разделов), посмотреть на экране агрегированные описания в виде графа­рисков.

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

Заключение

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

Киберкрыша

Александр Мурадян, руководитель направления "Эффективность IT", "Коминфо Консалтинг"

&laquoIT News&raquo, #1(2)/2004

На сегодняшний день существует одна проблема, весьма серьезная и актуальная как никогда. Способная радикально изменить не только интенсивность финансовых вливаний в Интернет, но и его дальнейшее развитие.

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

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

Но с вирусами можно бороться радикальным способом: нет притока файлов из недостоверных источников - нет заразы. В этом случае нет нужды в антивирусах. С Интернетом этот метод явно не годится.

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

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

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

Сейчас взломы сайтов производятся в большинстве случаев ради любопытства, из рекламных соображений и в исключительно редких случаях - с целью извлечения реальной выгоды. Либо хозяевами ресурсов для саморекламы. Но вполне может возникнуть ситуация, когда на киберобщество обратит внимание и реальный криминал. Ведь все виды деятельности, на которых он зарабатывает, основываются на одном экономическом принципе. Его, кстати, исповедуют и весьма успешные легальные бизнесы. В основном в рамках закона. Принцип этот: "Любое дело должно приносить максимальную прибыль при минимальных затратах. При постоянно возрастающем спросе. И полной несостоятельности конкурентов. Если таковые имеются".

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


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

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

Кто должен нести ответственность за каждый случай взлома сайта? В первую очередь те, кто способствовал этому. Создатели "дырявого" программного обеспечения. И провайдеры. Почему именно они? По большому счету, можно найти брешь в любой защите. Только вопрос: во сколько и во что это выльется? Если на взлом сайта или электронного магазина понадобится больше времени и ресурсов, чем ожидаемый куш от подобного взлома, никто серьезный этим заниматься не будет. И вопрос о кибермафии отпадет. За неимением источников прибыли. Но... пока бал правят творцы лицензионных соглашений, которые дают создателям "кривых" программ реальную и уникальную возможность делать деньги на хламе. Чего стоит, например, следующий опус: "...или его поставщики ни при каких условиях не несут ответственности за какой-либо ущерб, связанный с использованием или невозможностью использования данного продукта (или услуги)... в любом случае сумма возмещения согласно данному договору не может превышать сумму, фактически уплаченную вами за программу (или услугу)". Тот еще шедевр! Получается, что, приобретая программу для создания интернет-магазина, например, покупатель берет ее на свой страх и риск, а будут ли работать те возможности, которые красиво расписаны на коробке или в эксплуатационной документации (исключительная секретность и гарантированная невозможность взлома), - это его головная боль.За что же тогда деньги заплачены! Сделай такое фирма, производящая бытовую технику или осуществляющая, скажем, авиаперевозки, она бы разорилась на удовлетворении исков. Не предлагают же авторы книг, кинокартин и песен (а это ведь тоже, кстати, плод интеллектуальной деятельности) заполнить лицензию, в которой они отказываются от ответственности за то, что, прочтя, послушав или посмотрев их опус, читатель (или зритель) совершит уголовно наказуемое действие. Еще как отвечают! Что-то не слышно и о предполетном заполнении соглашения, согласно которому за пропажу груза или авиакатастрофу авиакомпания ответственности не несет. Еще как несет!

Вот только провайдеры хостинга на пару с творцами программ успешно отгородились от проблем соглашениями и договорами. А конца-то карт-бланшу не видно. Увы...

Инструкции по использованию компьютера

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

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

И все же пиратство - это только полбеды. Компьютерные вирусы свободно передаются с одного компьютера на другой через дискеты и интернет. К сожалению, к тому времени, когда вирус проявляется или когда его обнаруживают, он успевает заразить несколько систем. Если все программное обеспечение, используемое в сети, тщательно проверено и утверждено, если оно распространяется из единого источника, эту проблему проще контролировать.

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

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

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

Недовольство пользователей. Не переборщите. В лучшем случае пользователи не станут выполнять слишком строгую инструкцию, создающую серьезные неудобства,- особенно если им непонятно, насколько эти меры оправданы. В худшем же случае возможно нарастание скрытой агрессии и открытый конфликт. Будьте внимательны: некоторые выходки, которые на первый взгляд представляются невинной, хотя и грубой шуткой, часто являются средством выплеснуть недовольство. Наказания. Если правило подразумевает принятие некоторых болезненных мер, то оно всегда должно выполняться с максимальной значительностью и строгостью - "чтобы другим не повадно было". В идеале такие меры должны приниматься один раз.

Политика сетевых соединений

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

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

Если пользователям разрешено соединение через виртуальную частную сеть (Virtual Private Network, VPN), необходимо разработать специальные документы с подробным описанием настройки портативных и настольных компьютеров.

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

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

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

И все равно любой, без исключений, доступ к сети должен осуществляться через VPN или коммутируемый канал с использованием брандмауэра. Даже если сетевые политики будут строго запрещать сотрудникам использовать компьютеры компании и мобильные компьютеры для посторонних вещей, обеспечить соблюдение такой политики наверняка не удастся - такова природа человеческая. Пользователи все равно будут проверять личные почтовые ящики, заходить на любимые сайты и, что еще хуже, загружать невинные на вид программы, MP3-плееры например. В защищенной сетевой среде такие вещи недопустимы - и единственным средством оградить от них сеть является брандмауэр.

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

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

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

Елена Полонская,

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

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

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

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

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

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

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

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

Рассмотрим эти документы подробнее.

Сотрудники

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

Устранение последствий вторжения

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

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

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

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

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

Наверное, одним из самых сложных моментов для менеджера является увольнение сотрудника. Хорошо еще, если сотрудник покидает компанию добровольно и сохраняет дружеские отношения с руководством. Тогда достаточно отключить его учетную запись и убедиться, что все двери доступа закрыты. Но если отношения испорчены, необходимо принять все меры, чтобы гарантированно заблокировать уволенному работнику все способы доступа к сети, которые он имел прежде. Если работник был уволен за намеренное причинение ущерба сети, не оставил ли он после себя "мину замедленного действия"? Какие меры нужно предпринять, чтобы изолировать ресурсы, которые были доступны этому работнику, пока будет идти дальнейшее расследование? Нужно ли менять пароли и учетные записи других пользователей - например, тестовые учетные записи или локальные учетные записи компьютеров, к которым работник мог иметь доступ?

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

Внешние соединения

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

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

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

Что не так с ребятами из IT?

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

«Я работал в средней по величине компании, занимающейся разработкой программного обеспечения. При доступе к основным серверам у меня были привилегии администратора. Только чтобы размять свой ум, я обдумывал, как можно использовать этот доступ злонамеренно, и разработал следующий план. Во-первых, взломать систему резервного копирования. В нашей компании все копии шифровались в целях безопасности прямо во время создания и дешифровались в процессе восстановления. Другими словами, резервные данные в зашифрованном виде никому не нужны. Взлом системы копирования предполагает, естественно, извлечение ключей шифрования. Во-вторых, подождать год или дольше. В-третьих, стереть всю информацию на серверах, включая взломанное программное обеспечение для шифрования/дешифрования резервных данных. Таким образом, у предприятия останутся лишь зашифрованные резервные копии (без ключа). В-четвертых, предложить компании купить ключи, которые удалось получить еще на первом шаге. Если фирма откажется, то потеряет годы своей работы. Это, конечно, всего лишь гипотетический план. Я не пытался претворить его в жизнь, поэтому не знаю, сработал бы он или нет…», — Филиэс Купио (Filias Cupio). «Большинство специалистов по информационным технологиям, которых я знаю, даже еще начинающие ребята, сразу же при вступлении в должность первым делом устанавливают программу скрытого управления (rootkit) в корпоративную систему. Это рефлекс. Ребята не хотят никому навредить и не строят вредоносных планов, им просто нужен надежный доступ к системе, чтобы можно было спокойно работать из дома или колледжа», — Бен.

Что такое саботаж?

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

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

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

D3.shtml

Диаграмма 3. Финансовые потери вследствие внутреннего саботажа

Деструктивная активность саботажников

Глубокая психологическая подоплека акта саботажа часто приводит к тому, что рассерженный служащий угрожает начальству или сослуживцам, например, по электронной почте. Иногда он даже делится своими мыслями с кем-то из коллег. Другими словами, информация о готовящейся диверсии есть не только у саботажника. Аналитики подсчитали, что в 31% случаев сведениями о планах диверсанта располагают другие люди. Из них 64% — коллеги, 21% — друзья, 14% — члены семьи, а еще 14% —сообщники.

Также удалось установить, что 62% корпоративных диверсантов продумывают свои действия заблаговременно. В 47% случаев они совершают подготовительные действия (например крадут резервные копии конфиденциальных данных). В 27% — конструируют и проверяют механизм атаки (готовят логическую бомбу в корпоративной сети, дополнительные скрытые входы в систему и т. д). При этом в 37% случаев активность сотрудников можно заметить: из этого количества 67% подготовительных действий заметны в режиме online, 11% — offline, 22% — обоих сразу.

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

Таким образом, 57% саботажников имеют права администратора в системе, из них 85% на момент совершения диверсии лишились таких широких полномочий на доступ к корпоративной среде.

Что касается самой атаки, то 61% саботажников предпочитают простые и незамысловатые механизмы, к примеру, команды пользователя, обмен информацией, эксплуатацию физических уязвимостей безопасности. Оставшиеся 39% применяют более изощренные методы атаки: собственные программы или сценарии, автономные агенты и т. д. В 60% случаев злоумышленники компрометируют учетные записи, чтобы потом с их помощью провести атаку.

В 33% инцидентов это компрометация имени пользователя и пароля; в 20% — неавторизованное создание новой учетной записи. Подчеркнем, что в 92% случаев заметить подозрительную активность в данной сфере до момента совершения диверсии почти невозможно.

Как выявить диверсанта?

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

Если перевести эти данные на язык цифр, то получится, что 63% атак были замечены лишь потому, что в системе появились сильные отклонения. В 42% случаев система вышла из строя. При этом в 70% инцидентов злоумышленника удается вычислить по журналам системных событий, в 33% — по IP-адресу, в 28% — по телефонным записям, в 24% — по имени пользователя, в 13% — путем процедур аудита. Таким образом, журналы событий () являются наиболее эффективным средством. В тех случаях, когда используются журналы системных событий, чаще всего нужно исследовать журнал событий удаленного доступа (73%). За ним с большим отставанием следуют журнал доступа к файлам (37%), журнал изменения системных файлов (37%), журналы приложений и баз данных (30%), почтовые журналы (13%). В общем, в 31% случаев для идентификации злоумышленника используются сразу несколько журналов ().

Но не все так просто. В 76% инцидентов диверсанты пытаются скрыть свою личность (31%), действия (12%) или одновременно и то и другое (33%). Повторим, что саботажники могут модифицировать или удалять журналы событий, создавать скрытые входы в систему и неавторизованные учетные записи, подделывать свой IP-адрес. При этом 71% саботажей совершается сотрудниками, не связанными с обеспечением IT-безопасности.

Портрет типичного саботажника

Исследование Секретной службы США установило, что в 98% случаев диверсантом является мужчина. Правда, портрет корпоративного саботажника не включает таких характеристик, как семейный статус, возраст и расовая принадлежность. Другими словами, это может быть как женатый мужчина, так и холостой, как 17-летний юнец, так и уходящий на пенсию служащий. Не подтвердилось также популярное убеждение, что большинство саботажников — это люди, имеющие криминальную историю. Так, лишь в 30% исследованных случаев диверсант был хотя бы раз арестован.

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

Однако эти мотивы представляют собой следствия более ранних событий, которые вывели служащего из равновесия (диаграмма 6). По сведениям аналитиков, в 92% случаев саботажу предшествует неприятный инцидент на работе или целая серия таких инцидентов. В 47% случаев — увольнение, в 20% — спор с нынешними или бывшими коллегами, 13% — отсутствие повышения.

Диаграмма 6. Какие события предшествуют саботажу

Другими словами, 85% всех внутренних диверсантов рассержены на кого-то, кого они ассоциируют с компанией. Так, в 57% случаев сослуживцы саботажника характеризовали его как чрезвычайно рассерженного и раздраженного человека.

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

Все-таки, несмотря на все эти сведения, более или менее различимая черта портрета типичного саботажника (помимо пола) — его профессия (диаграмма 7). Как показало исследование CERT, практически все корпоративные диверсанты являются специалистами, так или иначе связанными с информационными технологиями. На долю технически подкованных диверсантов приходится 86% инцидентов. Среди них 38% системных администраторов, 21% программистов, 14% инженеров, 14% специалистов по IT. Что же до саботажников, не работающих в технических департаментах, 10% работают среди прочего редакторами, менеджерами, аудиторами и т. д., а 3% саботажников приходится на сферу обслуживания, в частности, на общение с клиентами.

Диаграмма 7. Портрет типичного саботажника

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

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

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

Диаграмма 1.Соотношение наличия и отсутствия финансовых потерь вследствие корпоративного саботажа

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

Для оценки финансового ущерба вследствие саботажа воспользуемся результатами исследований CERT (). Заметим, что чуть меньше половины всех респондентов, ставших жертвами саботажа, понесли «незначительный» урон — до $20 тыс. По сравнению со средним ущербом в результате утечки конфиденциальной информации ($255 тыс., по сведениям ФБР) это действительно немного. Однако наибольшую озабоченность экспертов вызывает именно та одна десятая часть, которая приходится на потери свыше $1 млн (9% — от $1 млн до $5 млн и 2% — более $10 млн). Это лишний раз указывает на некоторую относительность статистики ФБР, где суммарный ущерб за год оценен лишь в $341 тыс.

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

Диаграмма 4. Последствия саботажа для коллег диверсанта

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

Профилактика — лучший метод защиты

По мнению экспертов компании InfoWatch, наилучшее средство предотвращения корпоративного саботажа — профилактические меры. Прежде всего компаниям нужно проверять рекомендации и места предыдущей работы нанимаемых служащих. Таким способом удается исключить те 30% претендентов, которые имели криминальную историю.

Еще один чрезвычайно эффективный метод — регулярные тренинги или семинары, на которых до персонала доводится информация об угрозах IT-безопасности и саботаже как таковом. При таком подходе руководство делает ставку на тех сотрудников, которые взаимодействуют с саботажником в офисе, видят его нервозное поведение, получают угрозы в свой адрес и т. п. Все эти служащие должны знать, что о подобных инцидентах нельзя умалчивать. Напротив, о них следует тут же извещать уполномоченных лиц.

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

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

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

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

Саботаж в корпоративной среде

Алексей Доля

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

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

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

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

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

Разработчик приложений потерял свое место в компании, работающей в секторе информационных технологий, вследствие сокращения штатов. В отместку бывший служащий атаковал сеть фирмы как раз перед рождественскими праздниками. Спустя три недели после увольнения он удаленно вошел в корпоративную сеть, воспользовавшись учетной записью и реквизитами одного из своих бывших коллег, модифицировал данные на веб-сервере компании, изменил текст и вставил порнографические изображения. Вслед за тем рассерженный разработчик отправил всем клиентам компании электронные письма с предложением открыть корпоративный веб-сайт и убедиться, что он был взломан. В каждом сообщении содержались имя и пароль клиента для доступа к веб-сайту. Было начато расследование, но установить личность преступника не удалось. Спустя полтора месяца злоумышленник снова удаленно вошел в сеть и запустил программу-сценарий, которая изменила все сетевые пароли и 4 тыс. записей в базе данных цен. На этот раз саботажника удалось вычислить и поймать. Его приговорили к пяти месяцам тюрьмы и двум годам условно. Также наказание включало штраф в размере $48,6 тыс., которые он должен был выплатить своему прежнему работодателю.

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

Дискреционная защита

В современных СУБД достаточно развиты средства дискреционной защиты.

Дискреционное управление доступам (discretionary access control) — разграничение доступа между поименованными субъектами и поименованными объектами. Субъект с определенным правом доступа может передать это право любому другому субъекту.

Дискреционная защита является многоуровневой логической защитой.

Логическая защита в СУБД представляет собой набор привилегий или ролей по отношению к защищаемому объекту. К логической защите можно отнести и владение таблицей (представлением). Владелец таблицы может изменять (расширять, отнимать, ограничивать доступ) набор привилегий (логическую защиту) . Данные о логической защите находятся в системных таблицах базы данных и отделены от защищаемых объектов (от таблиц или представлений).

Информация о зарегистрированных пользователях базы данных хранится в ее системном каталоге. Современные СУБД не имеют общего синтаксиса SQL-предложения соединения с базой данных, так как их собственный синтаксис сложился раньше, чем стандарт ISO. Тем не менее часто таким ключевым предложением является CONNECT. Ниже приведен синтаксис данного предложения для Oracle и IBM DB2 соответственно: CONNECT [[logon] [AS {SYSOPER|SYSDBA}]] пользователь/пароль[@база_данных] CONNECT TO база_данных USER пользователь USING пароль

В данных предложениях отражен необходимый набор атрибутов, а также показано различие синтаксиса. Формат атрибута база_данных, как правило, определяется производителем СУБД, так же как и имя пользователя, имеющего по умолчанию системные привилегии (SYSDBA/SYSOPER в случае Oracle).

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

Следуя технологии открытых систем, субъект доступа может обращаться посредством СУБД к базе данных только из программ, поставляемых в дистрибутиве или подготовленных им самим, и только с помощью штатных средств системы.

Все субъекты контроля системы хранятся в таблице полномочий системы и разделены для системы на ряд категорий, например CONNECT, RESOURCE и DBA. Набор таких категорий определяется производителем СУБД. Мы не случайно предлагаем указанный порядок рассмотрения — именно так происходит нарастание возможностей (полномочий) для каждого отдельного вида подключения: CONNECT — конечные пользователи. По умолчанию им разрешено только соединение с базой данных и выполнение запросов к данным, все их действия регламентированы выданными им привилегиями; RESOURCE — привилегированные пользователи, обладающие правом создания собственных объектов в базе данных (таблиц, представлений, синонимов, хранимых процедур).
Пользователь — владелец объекта обладает полным набором привилегий для управления данным объектом; DBA — категория администраторов базы данных. Включает возможности обеих предыдущих категорий, а также возможность вводить (удалять) в систему (из системы) субъекты защиты или изменять их категорию.

Следует особо отметить, что в некоторых реализациях административные действия также разделены, что обусловливает наличие дополнительных категорий. Так, в Oracle пользователь с именем DBA является администратором сервера баз данных, а не одной-единственной базы данных. В СУБД «Линтер» компании РЕЛЭКС понятие администратора сервера баз данных отсутствует, а наличествует только понятие администратора конкретной базы данных. В IBM DB2 существует ряд категорий администраторов: SYSADM (наивысший уровень; системный администратор, обладающий всеми привилегиями); DBADM (администратор базы данных, обладающий всем набором привилегий в рамках конкретной базы данных).


Привилегии управления сервером баз данных имеются у пользователей с именами SYSCTRL (наивысший уровень полномочий управления системой, который применяется только к операциям, влияющим на системные ресурсы; непосредственный доступ к данным запрещен, разрешены операции создания, модификации, удаления базы данных, перевод базы данных или экземпляра (instance) в пассивное состояние (quiesce), создание и удаление табличных пространств), SYSMAINT (второй уровень полномочий управления системой, включающий все операции поддержки работоспособности экземпляра (instance); непосредственный доступ к данным этому пользователю запрещен, разрешены операции изменения конфигурационных файлов базы данных, резервное копирование базы данных и табличных пространств, зеркалирование базы данных). Для каждой административной операции в IBM DB2 определен необходимый набор административных категорий, к которым должен принадлежать пользователь, выполняющий тот или иной запрос администрирования. Так, выполнять операции назначения привилегий пользователям может SYSADM или DBADM, а для того чтобы создать объект данных, пользователь должен обладать привилегией CREATETAB.

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

СУБД позволяет зарегистрировать пользователя и хранить информацию о его уникальном идентификаторе. Например, подсистема безопасности Oracle позволяет создавать пользователей базы данных посредством предложения: CREATE USER IDENTIFIED пользователь BY пароль

Подсистема безопасности IBM DB2 может использовать идентификаторы пользователей операционной системы; ее синтаксис SQL не содержит предложения, аналогичного предложению CREATE USER. Microsoft SQL Server может использовать аутентификацию как базы данных, так и операционной системы.


Но мы не станем здесь обсуждать достоинства и недостатки выбранных производителями способов аутентификации — все они позволяют строить корректные схемы определения подлинности пользователей. Использование дополнительных средств аутентификации в рамках информационной системы не запрещается.

Набор привилегий можно определить для конкретного зарегистрированного пользователя или для группы пользователей (это могут быть собственно группы пользователей, роли и т.п.). Объектом защиты может являться таблица, представление, хранимая процедура и т.д. (подробный список объектов защиты имеется в документации к используемой СУБД). Субъектом защиты может быть пользователь, группа пользователей или роль, а также хранимая процедура, если такое предусматривается используемой реализацией. Если из используемой реализации следует, что хранимая процедура имеет «двойной статус» (она и объект защиты, и субъект защиты), то нужно очень внимательно рассмотреть возможные модели нарушителей разграничения прав доступа и предотвратить эти нарушения, построив, по возможности, соответствующую систему защиты.

При использовании хранимых процедур следует обращать особое внимание на то, от имени какого пользователя выполняется данная хранимая процедура в каждом конкретном случае. Так, в Oracle до недавнего времени хранимые процедуры выполнялись от имени владельца хранимой процедуры, а не от имени пользователя, выполнившего ее вызов. Текущая версия Oracle предоставляет возможность указать, под чьим именем будет выполняться вызванная хранимая процедура, пользователь же должен иметь только привилегию EXECUTE для данной процедуры. В «Линтер», например, выполнение хранимых процедур всегда происходит от имени пользователя, вызвавшего процедуру.

Привилегии конкретному пользователю могут быть назначены администратором явно и неявно, например через роль. Роль — это еще один возможный именованный носитель привилегий. С ролью не ассоциируют перечень допустимых пользователей — вместо этого роли защищают паролями, если, конечно, такая возможность поддерживается производителем СУБД.


Роли удобно использовать, когда тот или иной набор привилегий необходимо выдать (или отобрать) группе пользователей. С одной стороны, это облегчает администратору управление привилегиями, с другой — вносит определенный порядок в случае необходимости изменить набор привилегий для группы пользователей сразу. Нужно особо отметить, что при выполнении хранимых процедур и интерактивных запросов может существовать зависимость набора привилегий пользователя от того, как они были получены: явно или через роль. Имеют место и реализации, например в Oracle, где в хранимых процедурах используются привилегии, полученные пользователем явно. Если используемая вами реализация обладает подобным свойством, то изменение привилегий у группы пользователей следует реализовать как набор команд или как административную процедуру (в зависимости от предпочтений администратора).

Предложения управления привилегиями: назначение привилегии: GRANT привилегия [ON объект] TO субъект [WITH GRANT OPTION]

отмена привилегии: REVOKE привилегия [ON объект] FROM субъект



Если субъект=пользователь, то привилегия назначается ему явно. Если субъект=роль, то для управления привилегиями используются соответственно: GRANT ROLE имя_роли [ON объект] TO субъект [WITH GRANT OPTION] REVOKE ROLE имя_роли [ON объект] FROM субъект

Назначение привилегии всем пользователям системы осуществляется следующим образом: GRANT привилегия [ON объект] TO PUBLIC

В этом случае каждый новый созданный пользователь автоматически получит такую привилегию. Отмена привилегии осуществляется так: REVOKE привилегия [ON объект] FROM PUBLIC

Необходимо иметь в виду, что некоторые реализации, например IBM DB2, используют группы пользователей, определенные в операционной системе. Поэтому следует обращать внимание на особенности реализации аналогов ролей в СУБД. Нужно выяснить, содержит ли реализация SQL-предложения вида: CREATE ROLE имя_роли DROP ROLE имя_роли

При управлении доступом к таблицам и представлениям набор привилегий в реализации СУБД определяется производителем.



Привилегии выборки и модификации данных:

SELECT — привилегия на выборку данных;
INSERT — привилегия на добавление данных;
DELETE — привилегия на удаление данных;
UPDATE — привилегия на обновление данных ( можно указать определенные столбцы, разрешенные для обновления).

Привилегии изменения структуры таблиц:

ALTER — изменение физической/логической структуры базовой таблицы (изменение размеров и числа файлов таблицы, введение дополнительного столбца и т.п.);
INDEX — создание/удаление индексов на столбцы базовой таблицы;
ALL — все возможные действия над таблицей.

В реализациях могут присутствовать другие разновидности привилегий, например:

CONTROL (IBM DB2) — комплексная привилегия управления структурой таблицы,
REFERENCES — привилегия создания внешних ключей,
RUNSTAT — выполнение сбора статистической информации по таблице и другие.

Однако дискреционная защита является довольно слабой, так как доступ ограничивается только к именованным объектам, а не собственно к хранящимся данным. В случае реализации информационной системы с использованием реляционной СУБД объектом будет, например, именованное отношение (то есть таблица), а субъектом — зарегистрированный пользователь. В этом случае нельзя в полном объеме ограничить доступ только к части информации, хранящейся в таблице. Частично проблему ограничения доступа к информации решают представления и использование хранимых процедур, которые реализуют тот или иной набор бизнес-действий.

Представление (view) — это сформированная выборка кортежей, хранящихся в таблице (таблицах). К представлению можно обращаться точно так же, как и к таблицам, за исключением операций модификации данных, поскольку некоторые типы представлений являются немодифицируемыми. Часто в реализациях view хранится как текст, описывающий запрос выборки, а не собственно выборка данных; выборка же создается динамически на момент выполнения предложения SQL, использующего view. Но разграничить доступ, например, к двум документам, которые удовлетворяют одному и тому же условию выборки, уже нельзя.Это связано с тем, что даже если ввести отдельный атрибут, который будет хранить информацию о метке конфиденциальности документа, то средствами SQL можно будет получить выборку данных без учета атрибута данной метки. Фактически это означает, что либо сам сервер баз данных должен предоставить более высокий уровень защиты информации, либо придется реализовать данный уровень защиты информации с помощью жесткого ограничения операций, которые пользователь может выполнить посредством SQL. На некотором уровне такое разграничение можно реализовать с помощью хранимых процедур, но не полностью — в том смысле, что само ядро СУБД позволяет разорвать связь «защищаемый объект Ц метка конфиденциальности».

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

Лилия Козленко, 3'2002

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

Для СУБД важны три основных аспекта информационной безопасности - конфиденциальность, целостность и доступность. Темой настоящей статьи является первый из них - средства защиты от несанкционированного доступа к информации. Общая идея защиты базы данных состоит в следовании рекомендациям, сформулированным для класса безопасности C2 в «Критериях оценки надежных компьютерных систем».

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

Мандатная защита

Средства мандатной защиты предоставляются специальными (trusted) версиями СУБД.

Мандатное управление доступом (mandatory access control) — это разграничение доступа субъектов к объектам данных, основанное на характеризуемой меткой конфиденциальности информации, которая содержится в объектах, и на официальном разрешении (допуске) субъектов обращаться к информации такого уровня конфиденциальности.

Для чего же нужна мандатная защита? Средства произвольного управления доступом характерны для уровня безопасности C. Как правило, их, в принципе, вполне достаточно для подавляющего большинства коммерческих приложений. Тем не менее они не решают одной весьма важной задачи — задачи слежения за передачей информации. Средства произвольного управления доступом не могут помешать авторизованному пользователю законным образом получить секретную информацию и затем сделать ее доступной для других, неавторизованных, пользователей. Нетрудно понять, почему это так. При произвольном управлении доступом привилегии существуют отдельно от данных (в случае реляционных СУБД — отдельно от строк реляционных таблиц), в результате чего данные оказываются «обезличенными» и ничто не мешает передать их кому угодно даже средствами самой СУБД; для этого нужно лишь получить доступ к таблице или представлению.

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

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

Использование СУБД с возможностями мандатной защиты позволяет разграничить доступ собственно к данным, хранящимся в информационной системе, от доступа к именованным объектам данных. Единицей защиты в этом случае будет являться, в частности, запись о договоре N, а не таблица или представление, содержащее информацию об этом договоре. Пользователь, который будет пытаться получить доступ к договору, уже никак не сможет обойти метку конфиденциальности. Существуют реализации, позволяющие разграничивать доступ вплоть до конкретного значения конкретного атрибута в конкретной строке конкретной таблицы. Дело не ограничивается одним значением метки конфиденциальности — обычно сама метка представляет собой набор значений, отражающих, например, уровень защищенности устройства, на котором хранится таблица, уровень защищенности самой таблицы, уровень защищенности атрибута и уровень защищенности конкретного кортежа.

За исключением атрибута собственности (логическая защита), разбивающего данные (таблицы) на собственные (принадлежащие данному субъекту) и чужие, физическая защита разбивает данные более тонко. Но можно ли обойтись без физической защиты или, по крайней мере, попытаться, реализовав, например, сложный набор хранимых процедур. В общем-то некоторое подобие такой защиты реализуемо в случае, когда метки добавляются в таблицу в качестве дополнительного атрибута, доступ к таблицам запрещается вообще и ни одно приложение не может выполнить интерактивный SQL-запрос, а только хранимую процедуру и т.п. Ряд реализаций подобного уровня защиты использует вызов набора хранимых процедур с весьма абстрактными (что очень желательно) именами. Система реализации защиты информации в данном случае достаточно сложна и предполагает определенный уровень доверия к администратору безопасности, так как он имеет право изменять структуру базы данных, а значит, и хранимые процедуры, представления.


Физически же администратор безопасности в данном случае не изолирован от управления секретными данными.

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

Рассмотрим мандатную защиту подробнее. В качестве примера возьмем мандатную защиту СУБД «Линтер», которая получила признание в весьма специфическом секторе — силовых структурах, как единственная СУБД, имеющая сертификат по второму классу защиты от несанкционированного доступа, что соответствует классу B3 по американскому национальному стандарту.

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

Во-вторых, все объекты выстроены в иерархию по уровням конфиденциальности и по уровням ценности или важности. Уровень конфиденциальности разбивает объекты по доступности на чтение (и даже на просмотр). Пользователь с более низким уровнем доступа не будет знать даже о существовании объектов с более высоким уровнем конфиденциальности. Уровень ценности, напротив, разбивает данные (объекты) по важности, ограничивая возможность их удаления и модификации.

В уже упоминавшихся «Критериях оценки надежных компьютерных систем» применительно к системам уровня безопасности B описан механизм меток безопасности, реализованный в рассматриваемых данной статьей СУБД.



Метка объекта включает следующее:

Группа субъекта, который внес данный объект. Уровень доступа на чтение — RAL (Read Access Level). Уровень доступа на запись — WAL (Write Access Level).

Метка субъекта выглядит аналогично:

Группа, к которой принадлежит субъект. RAL-уровень субъекта, который представляет собой максимальный RAL-уровень доступной субъекту информации. WAL-уровень субъекта, то есть минимальный RAL-уровень объекта, который может быть создан этим субъектом.

Все пользователи базы данных считаются разбитыми на непересекающиеся группы. Группа описывает область доступных пользователю данных. Для каждой группы существует администратор группы (уровень DBA для группы), созданный администратором системы. При этом пользователи одной группы не видят данных, принадлежащих пользователям другой группы. В этом плане у СУБД «Линтер» имеется особенность: в системе реализовано такое понятие, как «уровень доверия между группами». При этом уровни доверия не могут быть вложенными. Группа представляет собой числовое значение в диапазоне [1-250]. Группа 0 — группа администратора системы. Только администратор системы может создать пользователя в группе, отличной от своей. Все данные, созданные от имени пользователя, помечаются его группой.

Уровни доступа вводятся для проверки прав на осуществление чтения-записи информации. Вводятся следующие уровни доступа:

Для пользователя (субъекта):

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

Для информации:

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



Создать пользователя с произвольными уровнями может только администратор системы. Остальные администраторы (DBA) могут создавать пользователей (или изменять уровень пользователям) лишь в пределах отведенных им уровней. Пользователь может принудительно пометить вводимые данные, указав в списке атрибутов уровни доступа для соответствующих записей и полей (при выполнении операторов INSERT или UPDATE). По умолчанию вносимые данные наследуют уровни пользователя, вносящего/изменяющего данные. Защищаемые объекты: пользователи, таблицы, столбцы, записи (вносится при выполнении INSERT), поля записей (изменяются при выполнении UPDATE). Уровни, как и группы, нельзя использовать в случае, если они не созданы специальными запросами.

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

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

1Стандарт Правительства США «Trusted Computer System Evaluation Criteria, DOD standard 5200.28 - STD, December, 1985», описывающий защищенные архитектуры информационных систем и определяющий уровни защиты от A1 (наивысшего) до D (минимального). - Прим. ред.

Некоторые термины

Конфиденциальная информация (sensitive information) - информация, которая требует защиты.

Доступ к информации (access to information) - ознакомление с информацией, ее обработка (в частности, копирование), модификация, уничтожение.

Субъект доступа (access subject) - лицо или процесс, действия которого регламентируются правилами разграничения доступа.

Объект доступа (access object) - единица информации автоматизированной системы, доступ к которой регламентируется правилами разграничения доступа. Объектами доступа (контроля) в СУБД является практически все, что содержит конечную информацию: таблицы (базовые или виртуальные), представления, а также более мелкие элементы данных: столбцы и строки таблиц и даже поля строк (значения). Таблицы базы данных и представления имеют владельца или создателя. Их объединяет еще и то, что все они для конечного пользователя представляются как таблицы, то есть как нечто именованное, содержащее информацию в виде множества строк (записей) одинаковой структуры. Строки таблиц разбиты на поля именованными столбцами.

Правила разграничения доступа (security policy) - совокупность правил, регламентирующих права субъектов доступа к объектам доступа.

Санкционированный доступ (authorized access to information) - доступ к информации, который не нарушает правил разграничения доступа.

Несанкционированный доступ (unauthorized access to information) - доступ к информации, который нарушает правила разграничения доступа с использованием штатных средств, предоставляемых средствами вычислительной техники или автоматизированными системами.

Идентификатор доступа (access identifier) - уникальный признак объекта или субъекта доступа.

Идентификация (identification) - присвоение объектам и субъектам доступа идентификатора и (или) сравнение предъявляемого идентификатора с перечнем присвоенных идентификаторов.

Пароль (password) - идентификатор субъекта, который является его секретом.

Аутентификация (authentification) - проверка принадлежности субъекту доступа предъявленного им идентификатора, подтверждение подлинности.

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

Уровень полномочий субъекта доступа (subject privilege) - совокупность прав доступа субъекта доступа (для краткости в дальнейшем мы будем использовать термин «привилегия»).

Нарушитель правил разграничения доступа (security policy violator) - субъект доступа, который осуществляет несанкционированный доступ к информации.

Модель нарушителя правил разграничения доступа (security policy violator model) - абстрактное (формализованное или неформализованное) описание нарушителя правил разграничения доступа.

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

Метка конфиденциальности (sensitivity label) - элемент информации, характеризующий конфиденциальность объекта.

Многоуровневая защита (multilevel secure) - защита, обеспечивающая разграничение доступа субъектов с различными правами доступа к объектам различных уровней конфиденциальности.

Пользователи СУБД

Пользователей СУБД можно разделить на три группы: Прикладные программисты - отвечают за создание программ, использующих базу данных.

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

Анализ затрат

Если проанализировать данные по I-му и II-му периодам, приведенные в табл. 9, то можно обнаружить, что чрезвычайно велики внутренние потери на компенсацию нарушений политики безопасности для ресурса "В", а также внешние потери на НПБ для ресурса "С".

Руководитель отдела защиты информации предпринял шаги в данном направлении. Он увеличил после II-го периода объем предупредительных мероприятий для ресурса "В", и это дало значительный эффект по снижению внутренних потерь на НПБ к концу III-го периода.

Он также увеличил после II-го периода предупредительную деятельность для ресурса "С", и после III-го периода так же произошло снижение внешних затрат на НПБ. Хотя предупредительные действия для этого ресурса не дали столь же быстрого результата, как для ресурса "В", тем не менее затраты были снижены, а к концу IV-го периода - даже в еще большей степени.

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

Начальнику отдела защиты информации необходима значительно большая информация, чем представленная в суммирующей таблице. Он знает, что у него возникли проблемы, но не знает какими причинами они вызваны. Он нуждается в более детальном дроблении элементов затрат на безопасность. Итак, к концу II-го периода начальник отдела защиты информации получил следующую информацию, конкретизирующую внутренние затраты на НПБ по ресурсу "В" в зависимости от угроз безопасности ресурса (Таб. 10).

Таблица 10. Составляющие затрат на внутренние потери

Код	Источник затрат	Угроза случайного или умышленного изменения информации	Угроза временной недоступности информации	Сумма (усл.ед.)	Доля (%)
=	=	Сумма	Доля (%)	Сумма	Доля (%)	=	=
W1	Восстановление системы защиты ресурса до соответствия требованиям ПБ	1001	89,3	120	10,7	1121	57,9
W2	Восстановление ресурса	133	100	-	-	133	6,9
W3	Выявление причин нарушения ПБ	97	87,4	14	12,6	111	5,7
W4	Изменения	440	77,2	130	32,8	570	29,5
=	Итого:	1671	=	264	=	1935	100

<
Приведенные данные показывают, что наибольшие потери связаны с воздействием угрозы случайного или умышленного изменения информации и возникающей необходимостью восстановления системы защиты ресурса до соответствия требованиям политики безопасности. Более детальная информация показывает механизмы защиты, которые были использованы для усиления системы защиты ресурса (Таб. 11).

Таблица 11. Составляющие затрат на внутренние потери в следствие реализации угрозы целостности информации

Механизмы защиты	Сумма (усл.ед.)
Затраты на введение дополнительных мер, связанных с учетом подключений пользователей к ресурсу	133	13,29
Затраты на введение дополнительных мер, связанных c контролем прав доступа сотрудников и учетом изменений их состояния (увольнение, перевод, отпуск, продолжительная болезнь)	88	8,79
Затраты на установку системы передачи файлов отчетов на сервер протоколирования	280	27,97
Приобретение дополнительных модулей удаленных запросов и выборок администратором системы безопасности	500	49,95
ИТОГО:	1001	100

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

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



Недостаточные возможности по архивированию данных.

Бессистемность проведения мероприятий по архивированию данных.

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

"Слабость" нормативной базы.

Отсутствие практики проведения тестовых испытаний системы защиты ресурсов.

Недостаточность технических систем охлаждения и питания серверных комнат.

Отсутствие регламента программно-технических средств "типовой рабочей станции" и т.д.

Как оказалось, в нашем примере ни одна из перечисленных причин не составляет более чем 8% от общей величины потерь в рассматриваемый период. Однако затраты на минимизацию перечисленных потерь будут существенно различны в зависимости от решаемой проблемы: наименьшие в случае совершенствования нормативной базы и, возможно, весьма значительные при оборудовании серверных комнат техническими системами охлаждения и питания.

Анализ затрат на обеспечение ИБ

Отчет по затратам на безопасность

Результаты анализа затрат на безопасность и итоговый отчет должны показать объективную картину в отношении безопасности.

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

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

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

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

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

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

Сравнить текущий уровень защищенности с уровнем прошлого периода, то есть выявить тенденции.

Сравнить текущий уровень с поставленными целями.

Выявить наиболее значительные области затрат.

Выбрать области для улучшения.

Оценить эффективность программ по улучшению.

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

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

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

Позволяет определить первоочередные задачи и направления деятельности.

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

Таблица 9. Отчет по затратам на безопасность (пример)

Затраты	=	Периоды	=	=
	I	II	III	IV
РЕСУРС "А"	=	=	=	=
Предупредительные	227	198	209	251
На контроль	593	616	606	614
На внутренние потери	985	1016	758	744
На внешние потери	503	528	482	427
Общие затраты на безопасность	2308	2358	2065	2036
Общие затраты на безопасность, отнесенные к объему продаж	1.0 %	1,05 %	0,9 %	0,85 %
Общие затраты на безопасность, отнесенные к трудоемкости	1,9 %	2 %	1,5 %	1,4 %
РЕСУРС "В "	=	=	=	=
Предупредительные	206	229	340	397
На контроль	894	949	916	925
На внутренние потери	1903	1935	1034	948
На внешние потери	620	598	613	632
Общие затраты на безопасность	3623	3711	2903	2902
Общие затраты на безопасность, отнесенные к объему продаж	1,1 %	1,15 %	0,9 %	0,9 %
Общие затраты на безопасность, отнесенные к трудоемкости	2,5 %	2,55 %	1,4 %	1,3 %
РЕСУРС "С"	=	=	=	=
Предупредительные	184	242	299	347
На контроль	815	859	831	802
На внутренние потери	1187	1191	910	893
На внешние потери	1101	1066	72	568
Общие затраты на безопасность	3287	3358	2762	261
Общие затраты на безопасность, отнесенные к объему продаж	1,2 %	1,2 %	1,0 %	0,9 %
Общие затраты на безопасность, отнесенные к трудоемкости	1,9 %	1,9 %	1,5 %	1,4 %

Аудит ИБ компании

По результатам собеседования с TOP-менеджерами компании и проведения инструментальных проверок уровня защищенности организации проводится анализ следующих основных аспектов:

Политики безопасности.

Организационных вопросов управления подсистемой безопасности.

Классификации и управления информационными ресурсами.

Управления персоналом.

Физической безопасности.

Администрирования компьютерных систем и сетей.

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

Разработки и сопровождения систем.

Планирования бесперебойной работы организации.

Проверки системы на соответствие требованиям ИБ.

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

Сравнение текущего показателя ССВ проверяемой компании с модельным значением показателя ССВ позволяет провести анализ эффективности организации ИБ компании, результатом которого является определение "узких" мест в организации, причин их появления и выработка дальнейших шагов по реорганизации корпоративной системы защиты информации и обеспечения требуемого уровня защищенности КИС.

Аудит системы безопасности:

Затраты на контроль изменений состояния информационной среды предприятия.

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

База для сравнений

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

11 12 13 14

Эти данные, рассмотренные изолированно, приводят к выводу о том, что увеличение затрат на безопасность выходит из под контроля.

Тем не менее, если мы посмотрим объем производства за те же самые периоды времени, то обнаружим следующие величины:

100 120 140 160

Если теперь сравнить общие затраты на безопасность, отнесенные к объему производства за тот же период, то можно получить следующие данные:

12,5% 11% 10% 9,3%

Очевидно, что управление затратами на безопасность не ухудшалось по периодам, как это предполагалось первоначально, а скорее улучшалось. Хотя общие затраты на безопасность и увеличивались, объем производства увеличивался. Таким образом, необходимо соотносить затраты на безопасность с какой-либо другой характеристикой деятельности, которая чувствительна к изменению производства.

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

Что такое затраты на информационную безопасность?

Как правило, затраты на информационную безопасность подразделяются на следующие категории:

Затраты на формирование и поддержание звена управления системой защиты информации (организационные затраты).

Затраты на контроль, то есть на определение и подтверждение достигнутого уровня защищенности ресурсов предприятия.

Внутренние затраты на ликвидацию последствий нарушения политики информационной безопасности (НПБ) - затраты, понесенные организацией в результате того, что требуемый уровень защищенности не был достигнут.

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

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

При этом обычно выделяют единовременные и систематические затраты. К единовременным относятся затраты на формирование политики безопасности предприятия: организационные затраты и затраты на приобретение и установку средств защиты.

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

Другие базы измерений

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

Формирование целевой модели ССВ

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

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

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

Границы применимости методики

Постановка задачи анализа эффективности инвестиций в обеспечение ИБ зависит от уровня зрелости организации. В [3] рассмотрена возможная классификация организаций по уровням зрелости:

"Анархия".

"Фольклор".

"Стандарты".

"Измеримый".

"Оптимизируемый".

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

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

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

Осведомленность и вовлеченность руководства в вопросы развития ИТ.

Особенности стратегии организации.

Позиции руководства отделов ИТ и ИБ в компании.

Роль ИТ в производственном процессе.

Случившиеся инциденты в области ИБ с тяжелыми последствиями.

Эти и возможно другие факторы следует учитывать наряду с экономическими при составлении аналитических материалов.

I. Примерный перечень затрат организации на обеспечение ИБ

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

Информационная безопасность: экономические аспекты

Сергей Петренко, Сергей Симонов, Роман Кислов,
№10 2003

Источники сведений о затратах

При определении затрат на обеспечение ИБ необходимо помнить, что:

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

Выплаты персоналу могут быть взяты из ведомостей.

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

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

Как идентифицировать затраты на безопасность?

Первая задача - определить перечень затрат, которые относятся к деятельности предприятия и распределить их по категориям.

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

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

Для подразделения или какого-либо участка.

Для защищаемого ресурса (по всем типам ресурсов).

Для какого-либо рабочего места пользователя информационной среды предприятия.

Для рисков по каждой категории информации.

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

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

Как оценить долю затрат на ИБ в обороте компании?

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

Таблица 4. Типичное разделение затрат, связанных с ИБ

Затраты на потери (внешние и внутренние)	=	70 % от общих затрат на безопасность
Затраты на контроль	=	25 % от общих затрат на безопасность
Затраты на предупредительные мероприятия	=	5 % от общих затрат на безопасность

Предположим, что указанные затраты на безопасность составляют 10 % оборота. Далее предположим, что за счет увеличения объема предупредительных мероприятий и, следовательно, увеличения предупредительных затрат, удалось снизить общие затраты на безопасность до 6 % от оборота. Теперь распределение общих затрат на безопасность может быть следующее:

Таблица 5. Пример распределения общих затрат на безопасность

Затраты на потери (внешние и внутренние)	=	50 % от новой величины общих затрат на безопасность
Затраты на контроль	=	25 % от новой величины общих затрат на безопасность
Затраты на предупредительные мероприятия	=	25 % от новой величины общих затрат на безопасность

Однако общие затраты на обеспечение ИБ составили только 60% от их первоначальной величины. По отношению к первоначальным общим затратам на ИБ, новое их распределение выглядит следующим образом:

Таблица 6. Пример соотношения распределения общих затрат на ИБ

Затраты на потери (внешние и внутренние)	(50х60)/100 =	30 % от начальной величины общих затрат на безопасность
Затраты на контроль	(25х60)/100 =	25 % от начальной величины общих затрат на безопасность
Затраты на предупредительные мероприятия	(25х60)/100 =	25 % от начальной величины общих затрат на безопасность
Экономия	=	40 % от начальной величины общих затрат на безопасность

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

Как определить затраты на ИБ?

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

Какова зависимость между затратами на ИБ и уровнем защищенности КИС?

Сумма всех затрат на повышение уровня защищенности предприятия от угроз информационной безопасности составляет Общие затраты на безопасность.

Взаимосвязь между всеми затратами на безопасность, общими затратами на безопасность и уровнем защищенности информационной среды предприятия обычно имеет вид функции (Рис. 2).

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

Рисунок 2. Взаимосвязь между затратами на безопасность и достигаемым уровнем защищенности

Контроль за соблюдением политики ИБ:

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

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

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

Материально-техническое обеспечение системы контроля доступа к объектам и ресурсам предприятия.

Литература

R. Witty , J. Dubiel , J. Girard , J. Graff , A. Hallawell , B. Hildreth , N. MacDonald , W. Malik , J. Pescatore , M. Reynolds , K. Russell , A. Weintraub , V. Wheatman. -- The Price of Information Security. Gartner Research, Strategic Analysis Report, К-11-6534 -- Gartner Research, Strategic Analysis Report, К-11-6534, June 2001 R. Witty -- The Role of the Chief Information Security Officer. Research Note, Gartner Research, Strategic Planning, SPA-13-2933 -- Gartner Research, Strategic Analysis Report, К-11-6534, April 2001 С.В. Симонов -- Технологии и инструментарий для управления рисками -- Jet Info, N2, 2003 С.A. Петренко , С.В. Симонов -- Экономически оправданная безопасность -- Изд. ДМК, Москва, 2003

Неизбежны ли затраты на информационную безопасность?

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

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

На восстановление системы безопасности до соответствия требованиям политики безопасности.

На восстановление ресурсов информационной среды предприятия.

На переделки внутри системы безопасности.

На юридические споры и выплаты компенсаций.

На выявление причин нарушения политики безопасности.

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

Обслуживание технических средств защиты.

Конфиденциальное делопроизводство.

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

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

Обучение персонала методам информационной безопасности.

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

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

Затраты на доставку (обмен) конфиденциальной информации.

Удовлетворение субъективных требований пользователей: стиль, удобство интерфейсов и др.

Обеспечение требований стандартов:

Затраты на обеспечение соответствия принятым стандартам и требованиям, достоверности информации, действенности средств защиты.

Обучение персонала:

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

Развитие нормативной базы службы безопасности.

Оценка эффективности деятельности службы ИБ

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

Таблица 8. Пример оценки вероятности серьезного происшествия в течение года

Данные измерений	Вывод
0,0 - 0,1	Надежность защиты высокая
0,1 - 0,25	Появились проблемы в системе защиты
0,25 - 0,5	Необходимо усилить систему защиты информации
0,5 - 0,75	Необходимо менять политику безопасности

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

Целью использования всех рассмотренных соотношений является сравнение эффективности деятельности предприятия в различные периоды времени.

Оценка текущего уровня ССВ

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

Существующие компоненты КИС (включая систему защиты информации) и информационные активы компании (серверы, клиентские компьютеры, периферийные устройства, сетевые устройства).

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

Существующие расходы на организацию ИБ в компании (обслуживание СЗИ и СКЗИ, а также штатных средств защиты периферийных устройств, серверов, сетевых устройств, планирование и управление процессами защиты информации, разработку концепции и политики безопасности и пр.).

Существующие расходы на организационные меры защиты информации.

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

Опасность ошибочной интерпретации

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

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

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

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

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

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

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

Определение ценности информационных ресурсов предприятия

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

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

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

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

Основные положения методики

ИБ обеспечивается комплексом мер на всех этапах жизненного цикла ИС, совокупная стоимость владения для системы ИБ в общем случае складывается из стоимости:

Проектных работ.

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

Затрат на обеспечение физической безопасности.

Обучения персонала.

Управления и поддержки системы (администрирование безопасности).

Аудита ИБ.

Периодической модернизации системы ИБ.

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

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

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

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

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

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

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



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

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

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

По использованию методов, так называемой, "лучшей практики" (best practice) в области управления ИБ с учетом реального состояния дел по управлению изменениями, операциями, активами, сервисному обслуживанию, обучению, планированию и управлению процессами.

По уровню сложности используемой информационной технологии и ее интеграции в производственный процесс организации (процент влияния - до 40%).

В целом определение затрат компании на ИБ подразумевает решение следующих трех задач:



Оценка текущего уровня ССВ корпоративной системы защиты информации и КИС в целом.

Аудит ИБ компании на основе сравнения уровня защищенности компании и рекомендуемого (лучшая мировая практика) уровня ССВ.

Формирование целевой модели ССВ.

Рассмотрим каждую из перечисленных задач.

Ответственность за сбор и анализ информации

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

Распределение деятельности и ответственности за нее может быть следующее (Таб. 7).

Таблица 7. Пример распределения деятельности и ответственности по затратам на ИБ

Деятельность	Исполнитель
Определение категорий затрат	Экономический отдел и служба безопасности
Сбор данных о затратах	Экономический отдел
Распределение данных по категориям	Экономический отдел
Предоставление данных о затратах в службу безопасности	Экономический отдел
Анализ затрат	Служба безопасности
Исследование причин	Служба безопасности
Разработка рекомендаций по снижению затрат	Служба безопасности
Составление отчета по затратам на безопасность и его рассылка	Служба безопасности
Координация деятельности по управлению затратами внутри всего предприятия	Служба безопасности
Наблюдение за выполнением рекомендаций и корректирующих мероприятий	Cлужба безопасности

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

Пересмотр политики информационной безопасности предприятия (проводится периодически):

Затраты на идентификацию угроз безопасности.

Затраты на поиск уязвимостей системы защиты информации.

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

Потеря новаторства:

Затраты на проведение дополнительных исследований и разработки новой рыночной стратегии.

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

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

Пример оценки затрат на ИБ

В качестве примера использования методики ССВ для обоснования инвестиций в ИБ рассмотрим проект модернизации корпоративной системы антивирусной защиты и системы управления доступом на объекте информатизации (физическая защита).

Для этого сначала условно определим три возможных состояния системы защиты КИС от вирусов и вредоносного ПО, а именно: базовое, среднее и высокое.

Базовое: Стационарные и мобильные рабочие станции обладают локальной защитой от вирусов. Антивирусное программное обеспечение и базы сигнатур регулярно обновляются для успешного распознавания и парирования новых вирусов. Установлена программа автоматического уничтожения наиболее опасных вирусов. Основная цель уровня - организация минимальной защиты от вирусов и вредоносного ПО при небольших затратах.

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

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

Также условно выделим три состояния развития системы контроля и управления доступом в КИС (обеспечение физической безопасности): базовое, среднее, высокое.

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

Элемент системы ИБ	Задача	Исходный (базовый) уровень	Повышенный уровень
Антивирусная защита	Каким образом распространяются обновления механизма антивирусной защиты?	Ничего не делается или нет информации	Используется автоматическое обновление антивирусного обеспечения
Антивирусная защита	Какая степень защиты от вирусов является допустимой?	Нет механизма защиты от вирусов	Защита от вирусов устанавливается ИС службой и не доступна пользователям для изменений
Антивирусная защита	Какой процент клиентских мест поддерживается серверной антивирусной защитой?	Нет данных	100 %
Антивирусная защита	Как устраняются последствия вирусных атак (в процентном отношении к числу вирусных событий)?	Пользователь самостоятельно восстанавливает поврежденные файлы и систему, протокол событий не ведется	ИС персонал уведомляется об инциденте, проводятся исследования и предпринимаются нейтрализующие меры, на местах поддерживается БД вирусных событий
Управление ИБ	Что делается для гарантии безопасности критичных данных (информация, которая является критичной по отношению к миссии каждого отдельного предприятия)	Не регламентирован	Средства шифрования и резервного копирования на серверах
Управление ИБ	Что делается для гарантии физической безопасности помещений с целью предотвращения случаев воровства и преступного использования оборудования?	Применяются сигналы тревоги о нарушении безопасности	Дополнительное использование таких средств безопасности, как смарт-карты или биометрические устройства

<


Возможно несколько вариантов реализации этих требований, характеризующихся разными экономическими показателями. Рассмотрим типичную структуру расходов по выбранным элементам системы ИБ "среднего западного" предприятия на модернизацию ИС (Таб. 2) для обеспечении "среднего" уровня защиты.
Таблица 2. Статьи расходов среднего уровня защиты

Статья затрат	Антивирусная защита	Управление ИБ
Подготовительные процедуры и операции по инсталляции	=	=
Услуги по инсталляции ПО:	=	=
С учетом поддержки уровня 2	2,600 %	0,000 %
С учетом поддержки уровня 3	1,300 %	0,000 %
Администрирование пользователей	0,000 %	6,500 %
Установка аппаратного обеспечения	0,000 %	2,600 %
Резервное копирование, архивирование и восстановление	2,600 %	0,000 %
Планирование и управление процессами восстановления	=	=
Общие процедуры управления, планирование и изучение рынка продуктов	1,300 %	1,300 %
Закупка программно-технических средств	18,200 %	2,600 %
Процедуры по восстановлению	19,500 %	0,000 %
Сервисное обслуживание	=	=
Ежедневные процедуры поддержки пользователей	5,200 %	2,600 %
Административные расходы	=	=
Финансовые службы и администрация	1,268 %	0,618 %
Административная поддержка ИС	0,429 %	0,169 %
Закупка, снабжение	0,000 %	5,200 %
Аудит	0,000 %	1,300 %
Управление контрактами, работа с поставщиками	0,000 %	2,600 %
Затраты рабочего времени конечных пользователей на решение задач ИБ	=	=
Затраты времени на управление файлами, данными и резервным копированием	6,500 %	0,000 %
Затрата на взаимодействие со службами поддержки	6,500 %	0,000 %
Затрата на взаимопомощь пользователей	6,500 %	0,000 %
Затраты на самоподдержку (решение проблем своими силами)	6,500 %	2,600 %
Незапланированные простои по причинам, относящимся к данным средствам защиты	10,400 %	10,400 %

В Таб. 3 и на Рис. 1 показаны расчеты совокупной стоимости владения при различных вариантах проведения модернизации КИС.


Данные приводятся для " среднего западного" предприятия. Расчетная стоимость снижения ССВ для третьего варианта около 230 тыс. долл. в год позволяют обосновать инвестиции в размере около 600 тыс. долл. на рассматриваемые компоненты защиты. При этом расчетный период окупаемости составляет не более 3 лет.
Таблица 3. Совокупная стоимость владения при проведении модернизации

Расходы на ИТ	Базовый вариант защиты: Антивирусная защита - низкий уровень, Управление ИБ - низкий уровень	Вариант 1: Антивирусная защита - средний уровень, Управление ИБ - низкий уровень	Вариант 2: Антивирусная защита - низкий уровень, Управление ИБ - средний уровень	Вариант 3: Антивирусная защита - средний уровень, Управление ИБ - средний уровень
Совокупная стоимость владения (ССВ)	$14,905,090	$14,659,236	$14,796,746	$14,563,990
Расходы на СВТ и ПО	$9,183,334	$9,212,787	$9,211,699	$9,241,232
Расходы на операции ИС	$1,402,287	$1,376,061	$1,394,232	$1,368,450
Административные расходы	$426,758	$425,554	$423,952	$422,748
Расходы на операции конечных пользователей	$2,772,377	$2,636,870	$2,758,898	$2,624,287
Расходы, связанные с простоями	$1,120,334	$1,007,965	$1,007,965	$907,273

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


Расходы на операции конечных пользователей. Это затраты на самоподдержку конечных пользователей, а также на поддержку пользователями друг друга в противовес официальной поддержке ИТ. Затраты включают: самостоятельную поддержку, официальное обучение конечных пользователей, нерегулярное (неофициальное) обучение, самостоятельные прикладные разработки, поддержку локальной файловой системы.
Расходы на простои. Данная категория учитывает ежегодные потери производительности конечных пользователей от запланированных и незапланированных отключений сетевых ресурсов, включая клиентские компьютеры, совместно используемые серверы, принтеры, прикладные программы, коммуникационные ресурсы и ПО для связи. Для анализа фактической стоимости простоев, которые связаны с перебоями в работе сети и которые оказывают влияние на производительность, исходные данные получают из обзора по конечным пользователям. Рассматриваются только те простои, которые ведут к потерям в основной деятельности организации.
Рисунок 1. Изменение ССВ при различных вариантах проведения модернизации системы ИБ

Отметим, что для применения методики ССВ требуются данные о потерях, связанных с простоями и другими негативными последствиях реализации угроз ИБ. Получить экономические оценки потерь можно на этапе анализа информационных рисков. Более подробно эти вопросы рассмотрены в [3], [4].

Принятие решений

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

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

Без доступной детальной информации борьба за повышение уровня защищенности информационной среды предприятия будет равносильна борьбе с "огнем" вместо "предупреждения пожаров".

Итак, необходимо отметить следующее:

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

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

Прочие затраты:

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

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

Разработка методик оценки затрат на ИБ

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

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

Что такое затраты на информационную безопасность?

Неизбежны ли затраты на информационную безопасность?

Какова зависимость между затратами на информационную безопасность и достигаемым уровнем информационной безопасности?

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

Какую пользу можно извлечь из анализа затрат на информационную безопасность?

Рассмотрим возможные ответы на поставленные вопросы.

Регламентное обслуживание средств защиты информации:

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

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

Затраты на поддержание системы резервного копирования и ведение архива данных.

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

Снижение общих затрат

В примере (Рис. 2) показано, что достигаемый уровень защищенности измеряется в категориях "большой риск" и "риск отсутствует" ("совершенная защита"). Рассматривая левую сторону графика ("большой риск"), мы видим, что общие затраты на безопасность высоки в основном потому, что высоки потери на компенсацию при нарушениях политики безопасности. Затраты на обслуживание системы безопасности очень малы.

Если мы будем двигаться вправо по графику, то достигаемый уровень защищенности будет увеличиваться (снижение информационного риска). Это происходит за счет увеличения объема предупредительных мероприятий, связанных с обслуживанием системы защиты. Затраты на компенсацию НПБ уменьшаются в результате предупредительных действий. Как показано на графике, на этой стадии затраты на потери падают быстрее, нежели возрастают затраты на предупредительные мероприятия. Как результат - общие затраты на безопасность уменьшаются. Изменения объема затрат на контроль незначительны.

Типовые базы измерений

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

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

Трудоемкость

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

Улучшение технологии.

Автоматизация технологических процессов.

Смена обслуживающего персонала.

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

Важно помнить следующее:

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

Необходимо всегда сравнивать величины в их стоимостном выражении.

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

Управление системой защиты информации:

Затраты на планирование системы защиты информации предприятия.

Затраты на изучение возможностей информационной инфраструктуры предприятия по обеспечению безопасности информации ограниченного распространения.

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

Проверка сотрудников на лояльность, выявление угроз безопасности.

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

Увеличение общих затрат

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

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

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

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

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

Устаревание системы ИБ.

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

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

Внедрение системы учета затрат на ИБ

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

Руководители системы безопасности должны быть убеждены в полезности этого мероприятия.

Ниже предложены некоторые "секреты" успешного внедрения системы.

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

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

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

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

Если затраты определены с точностью +/-5%, то работа сделана с приемлемой точностью. Руководство предприятия получит более точную картину затрат на безопасность, а следовательно и оценку уровня риска

Внеплановые проверки и испытания:

Оплата работы испытательного персонала специализированных организаций.

Обеспечение испытательного персонала (внутреннего и внешнего) материально-техническими средствами.

Внешние затраты на компенсацию нарушений политики безопасности

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

Однако существуют и другие затраты, которые определить достаточно сложно. В их числе:

Затраты на проведение дополнительных исследований и разработку новой рыночной стратегии.

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

Затраты, связанные с ликвидацией "узких мест" в снабжении, производстве и сбыте продукции.

Потери от компрометации производимой предприятием продукции и снижения цен на нее.

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

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

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

Внешние затраты на ликвидацию последствий нарушения политики безопасности:

Обязательства перед государством и партнерами.

Затраты на юридические споры и выплаты компенсаций.

Потери в результате разрыва деловых отношений с партнерами.

Внутренние затраты на компенсацию нарушений политики безопасности

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

Установка патчей или приобретение последних версий программных средств защиты информации.

Приобретение технических средств взамен пришедших в негодность.

Затраты на восстановление баз данных и прочих информационных массивов.

Затраты на обновление планов обеспечения непрерывности деятельности службы безопасности.

Затраты на внедрение дополнительных средств защиты, требующих существенной перестройки системы безопасности.

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

По проведению дополнительных испытаний и проверок технологических информационных систем.

По утилизации скомпрометированных ресурсов.

По проведению повторных проверок и испытаний системы защиты информации.

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

По проведению расследований нарушений политики безопасности.

Выяснение затрат на эти виды деятельности связаны с различными отделами:

Отделом информационных технологий.

Контрольно-ревизионным и финансовым отделами.

Службой безопасности.

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

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

Затраты на восстановление баз данных и прочих информационных массивов.

Затраты на проведение мероприятий по контролю достоверности данных, подвергшихся атаке на целостность.

Возможности методики

Методика совокупной стоимости владения (ССВ) была изначально предложена аналитической компанией Gartner Group в конце 80-х годов (1986-1987) для оценки затрат на информационные технологии. Методика Gartner Group позволяет рассчитать всю расходную часть информационных активов компании, включая прямые и косвенные затраты на аппаратно-программные средства, организационные мероприятия, обучение и повышение квалификации сотрудников компании, реорганизацию, реструктуризацию бизнеса и т. д.

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

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

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

Оптимизировать инвестиции на ИБ компании с учетом реального значения показателя ССВ.

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

Сравнение определенного показателя ССВ с аналогичными показателями ССВ по отрасли (с аналогичными компаниями) и с "лучшими в группе" позволяет объективно и независимо обосновать затраты компании на ИБ. Ведь часто оказывается довольно трудно или даже практически невозможно оценить прямой экономический эффект от затрат на ИБ. Сравнение же "родственных" показателей ССВ позволяет убедиться в том, что проект создания или реорганизации корпоративной системы защиты информации компании является оптимальным по сравнению с некоторым среднестатистическим проектом в области защиты информации по отрасли. Указанные сравнения можно проводить, используя усредненные показатели ССВ по отрасли, рассчитанные экспертами Gartner Group или собственными экспертами компании с помощью методов математической статистики и обработки наблюдений.

Методика ССВ Gartner Group позволяет ответить на следующие вопросы:



Какие ресурсы и денежные средства расходуются на ИБ?

Оптимальны ли затраты на ИБ для бизнеса компании?

Насколько эффективна работа службы ИБ компании по сравнению с другими?

Как эффективно управлять инвестированием в защиту информации?

Какие выбрать направления развития корпоративной системы защиты информации?

Как обосновать бюджет компании на ИБ?

Как доказать эффективность существующей корпоративной системы защиты информации и службы ИБ компании в целом?

Какова оптимальная структура службы ИБ компании?

Как оценить эффективность нового проекта в области защиты информации?

в последние несколько лет динамично

Отечественный ИТ-рынок в последние несколько лет динамично развивается, по оценкам экспертов его рост превышает 10% в год. При этом сектор информационной безопасности (ИБ) развивается еще более быстрыми темпами - более чем на 25% в год. Такой рост определяется в основном двумя факторами: возросшим вниманием руководства к обеспечению ИБ и недостаточным уровнем ИБ в существующих информационных системах (ИС).
Понятно, что долго такие темпы роста сектора ИБ сохраняться не смогут, они замедлятся, и вопросы оценки эффективности затрат в области ИБ встанут весьма остро. Уже сейчас в отечественных ИС с повышенными требованиями в области ИБ (банковские системы, ответственные производства, и т.д.) затраты на обеспечение режима ИБ составляют до 30% всех затрат на ИС, и владельцы информационных ресурсов серьезно рассматривают экономические аспекты обеспечения ИБ. Даже в тех ИС, уровень ИБ которых явно не достаточен, у технических специалистов зачастую возникают проблемы обоснования перед руководством (владельцами информационных ресурсов) затрат на повышение этого уровня.
Начальники служб автоматизации, исполнительные директора, начальники служб информационной безопасности должны иметь понятные для бизнеса аргументы для обоснования инвестиций в ИБ, т.е., по сути, представлять обоснование стоимости системы ИБ для бизнеса.
В обосновании затрат на ИБ существует два основных подхода.
Первый подход, назовем его наукообразным, заключается в том, чтобы освоить, а затем и применить на практике необходимый инструментарий измерения уровня ИБ. Для этого необходимо привлечь руководство компании (как ее собственника) к оценке стоимости информационных ресурсов, определению оценки потенциального ущерба от нарушений в области ИБ. От результатов этих оценок будет во многом зависеть дальнейшая деятельность руководителей в области ИБ. Если информация ничего не стоит, существенных угроз для информационных активов компании нет, а потенциальный ущерб минимален (руководство это подтверждает (!)), проблемой обеспечения ИБ можно не заниматься.
Если информация обладает определенной стоимостью, угрозы и потенциальный ущерб ясны, тогда встает вопрос о внесении в бюджет расходов на подсистему ИБ. В этом случае становится необходимым заручиться поддержкой руководства компании в осознании проблем ИБ и построении корпоративной системы защиты информации.
Второй подход, назовем его практическим, состоит в следующем: можно попытаться найти инвариант разумной стоимости корпоративной системы защиты информации. Ведь существуют аналогичные инварианты в других областях, где значимые для бизнеса события носят вероятностный характер. Например, на рынке автострахования оценка стоимости этой услуги составляет - 5-15% от рыночной стоимости автомобиля в зависимости от локальных условий его эксплуатации, стажа водителя, интенсивности движения, состояния дорог и т.д.
По аналогии, ИБ в компании можно вообще не заниматься, и не исключен такой вариант, что принятый риск себя вполне оправдает. А можно потратить на создание корпоративной системы защиты информации немало денег, и при этом останется некоторая уязвимость, которая рано или поздно приведет к утечке или хищению конфиденциальной информации.
Эксперты-практики в области защиты информации нашли некое оптимальное решение, при котором можно чувствовать себя относительно уверенно - стоимость системы ИБ должна составлять примерно 10-20% от стоимости КИС, в зависимости от конкретных требований к режиму информационной безопасности. Это и есть та самая оценка на основе практического опыта (best practice), которой можно уверенно оперировать, если не производить детальные расчеты.
Этот подход, очевидно, не лишен недостатков. В данном случае, скорее всего, не удастся вовлечь руководство в глубокое осознание проблем ИБ. Но зато можно обосновать объем бюджета на ИБ путем ссылки на понятные большинству владельцев информационных ресурсов общепринятые требования к обеспечению режима информационной безопасности "best practice", формализованные в ряде стандартов, например ISO 17799.
Реализация этих подходов (конкретные методы оценки эффективности системы ИБ) на практике зависит от ряда факторов, среди которых основными являются степень зрелости организации и специфика ее деятельности.
В статье рассматривается одна из наиболее известных методик оценки совокупной стоимости владения (ССВ) компании Gartner Group применительно к системе ИБ [1], [2], особенности использования этой методики в отечественных условиях. Эта методика применима в случаях, когда используется первый подход к обоснованию затрат на ИБ.

с методикой ССВ можно использовать

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

Затраты на контроль

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

Итак, мы видим, что можно достаточно просто получить точную картину по затратам на контроль.

Плановые проверки и испытания.

Затраты на проверки и испытания программно-технических средств защиты информации.

Затраты на проверку навыков эксплуатации средств защиты персоналом предприятия.

Затраты на обеспечение работы лиц, ответственных за реализацию конкретных процедур безопасности по подразделениям.

Оплата работ по контролю правильности ввода данных в прикладные системы.

Оплата инспекторов по контролю требований, предъявляемых к защитным средствам при разработке любых систем (контроль выполняется на стадии проектирования и спецификации требований).

Затраты на ликвидацию последствий нарушения режима ИБ:

Восстановление системы безопасности до соответствия требованиям политики безопасности.

Установка патчей или приобретение последних версий программных средств защиты информации.

Приобретение технических средств взамен пришедших в негодность.

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

Затраты на утилизацию скомпрометированных ресурсов.

Затраты на переделки:

Затраты на внедрение дополнительных средств защиты, требующих существенной перестройки системы безопасности.

Затраты на повторные проверки и испытания системы защиты информации.

Затраты на предупредительные мероприятия

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

Планирования и организации.

Приобретения и ввода в действие.

Доставки и поддержки.

Мониторинга процессов, составляющих информационную технологию.

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

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

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

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

Доставку конфиденциальной информации.

Консультации.

Курсы обучения.

Затраты на внешний аудит:

Затраты на контрольно-проверочные мероприятия, связанные с лицензионно-разрешительной деятельностью в сфере защиты информации.

Затраты на выявление причин нарушения политики безопасности:

Затраты на проведение расследований нарушений политики безопасности (сбор данных о способах совершения, механизме и способах сокрытия неправомерного деяния. поиск следов, орудий и предметов посягательства; выявление мотивов неправомерных действий и т. д.).

Затраты на обновление планов обеспечения непрерывности деятельности службы безопасности.

---

---