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

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

Сотрудники НПЦ «Модуль» имеют практический опыт создания и внедрения программных средств защиты информации (СЗИ) «Страж NT».

Федеральным законом от 27 июля 2006 г. № 152-ФЗ «О персональных данных» и постановлением Правительства РФ от 17 ноября 2007 г. № 781 установлены правила в отношении порядка обработки и обеспечения конфиденциальности персональных данных, как собственных работников, так и сторонних физических лиц, персональные данные которых обрабатываются в организации.

Персональные данные — любая информация, относящаяся к определенному или определяемому на основании такой информации физическому лицу (субъекту персональных данных), в том числе его фамилия, имя, отчество, год, месяц, дата и место рождения, адрес, семейное, социальное, имущественное положение, образование, профессия, доходы, другая информация. Обработка персональных данных — действия (операции) с персональными данными, включая сбор, систематизацию, накопление, хранение, уточнение (обновление, изменение), использование, распространение (в том числе передачу), обезличивание, блокирование, уничтожение персональных данных. Согласно статье 19 ФЗ-№ 152, «оператор при обработке персональных данных обязан принимать необходимые организационные и технические меры, в том числе использовать шифровальные (криптографические) средства, для защиты персональных данных от неправомерного или случайного доступа к ним, уничтожения, изменения, блокирования, копирования, распространения персональных данных, а также от иных неправомерных действий».

Согласно статье 25 ФЗ-№ 152, информационные системы предприятий и организаций должны быть приведены в соответствие с его требованиями не позднее 1 января 2010 г. Невыполнение требований указанных правовых актов, а также нормативных документов ФСБ и ФСТЭК по вопросам обработки персональных данных может привести к конфликту с государственными органами, осуществляющими контроль и надзор в данной сфере деятельности (Россвязькомнадзор, ФСБ России, ФСТЭК России).

Согласно статье 24 ФЗ-№ 152, «Лица, виновные в нарушении требований настоящего Федерального закона, несут гражданскую, уголовную, административную, дисциплинарную и иную предусмотренную законодательством Российской Федерации ответственность.»

НПЦ «Модуль» предлагает комплекс услуг по разработке Базового комплекта проектной организационно-распорядительной документации по обеспечению информационной безопасности персональных данных медицинской автоматизированной информационной системы лечебно-профилактического учреждения.

Базовый комплект включает:
1. Методические материалы по обеспечению информационной безопасности медицинской автоматизированной информационной системы лечебно-профилактического учреждения.
2. Проект Политики информационной безопасности.
3. Проект Концепции обеспечения безопасности информации.
4. Проект Акта проведения внутренней проверки информационной безопасности.
5. Проект Перечня сведений конфиденциального характера ЛПУ, подлежащих защите.
6. Проект Акта классификации информационной системы персональных данных АИС ЛПУ.
7. Проект Положения об отделении по защите информации.
8. Проект Должностной инструкции начальника отделения по защите информации.
9. Проект Должностной инструкции инженера по защите информации.
10. Проект Инструкции пользователя по защите информации при использовании ресурсов АИС ЛПУ.
11. Проект Общего регламента допуска к использованию ресурсов АИС ЛПУ.
12. Проект Технических требований по проведению научно-исследовательской работы.
13. Проект Тактико-технического задания на разработку системы обеспечения безопасности информации АИС ЛПУ.
14. Методика разработки Модели нарушителя информационной системы персональных данных.
15. Материалы Эскизного проекта на создание системы обеспечения безопасности информации АИС ЛПУ. Проект Модели угроз. Проект Модели нарушителя.

Для выполнения требований ФЗ № 152 в части использования сертифицированных средств защиты информации от несанкционированного доступа НПЦ «Модуль» предлагает ЛПУ, осуществляющим обработку персональных данных, разработанное и широко используемое в России программное СЗИ «Страж NT».

Средства защиты информации «Страж NT» успешно применяются в Министерстве обороны, Федеральной службе безопасности, Министерстве внутренних дел, ФСИН России, ФСНК и др.

ГОСТ Р 56546-2015

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Защита информации

УЯЗВИМОСТИ ИНФОРМАЦИОННЫХ СИСТЕМ

Классификация уязвимостей информационных систем

ОКС 35.020

Дата введения 2016-04-01

Предисловие

Предисловие

1 РАЗРАБОТАН Обществом с ограниченной ответственностью «Центр безопасности информации» (ООО «ЦБИ»)

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 362 «Защита информации»

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 19 августа 2015 г. N 1181-ст

4 ВВЕДЕН ВПЕРВЫЕ

5 ПЕРЕИЗДАНИЕ. Ноябрь 2018 г.
Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. N 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

Введение

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

1 Область применения

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

2 Нормативные ссылки

В настоящем стандарте использована нормативная ссылка на следующий стандарт:
ГОСТ Р 50922 Защита информации. Основные термины и определения
Примечание — При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов в информационной системе общего пользования — на официальном сайте национального органа Российской Федерации по стандартизации в сети Интернет или по ежегодному информационному указателю «Национальные стандарты», который опубликован по состоянию на 1 января текущего года, и по выпускам ежемесячного информационного указателя «Национальные стандарты» за текущий год. Если заменен ссылочный стандарт, на который дана недатированная ссылка, то рекомендуется использовать действующую версию этого документа с учетом всех внесенных в данную версию изменений. Если заменен ссылочный стандарт, на который дана датированная ссылка, то рекомендуется использовать версию этого документа с указанным выше годом утверждения (принятия). Если после утверждения настоящего стандарта в ссылочный стандарт, на который дана датированная ссылка, внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение рекомендуется применять без учета данного изменения. Если ссылочный стандарт отменен без замены, то положение, в котором дана ссылка на него, рекомендуется применять в части, не затрагивающей эту ссылку.

3 Термины и определения

В настоящем стандарте применены термины по ГОСТ Р 50922, а также следующие термины с соответствующими определениями:

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

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

3.3 признак классификации уязвимостей: Свойство или характеристика уязвимостей, по которым производится классификация.

3.4 информационная технология : Процесс, метод поиска, сбора, хранения, обработки, предоставления, распространения информации и способ осуществления таких процессов и методов.

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

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

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

3.8 уязвимость кода: Уязвимость, появившаяся в процессе разработки программного обеспечения.

3.9 уязвимость конфигурации: Уязвимость, появившаяся в процессе задания конфигурации (применения параметров настройки) программного обеспечения и технических средств информационной системы.

3.10 уязвимость архитектуры: Уязвимость, появившаяся в процессе проектирования информационной системы.

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

3.12 многофакторная уязвимость: Уязвимость, появившаяся в результате наличия нескольких недостатков различных типов.

3.13 язык программирования: Язык, предназначенный для разработки (представления) программного обеспечения.

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

4 Основные положения

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

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

4.3 К основным поисковым признакам уязвимостей ИС относятся следующие:
— наименование операционной системы (ОС) и тип аппаратной платформы;
— наименование ПО и его версия;
— степень опасности уязвимости.

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

5 Классификация

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

5.2 Уязвимости ИС по типам недостатков ИС подразделяются на следующие:
— недостатки, связанные с неправильной настройкой параметров ПО.
Примечание — Неправильная настройка параметров ПО заключается в отсутствии необходимого параметра, присвоении параметру неправильных значений, наличии избыточного числа параметров или неопределенных параметров ПО;
— недостатки, связанные с неполнотой проверки вводимых (входных) данных.
Примечание — Недостаточность проверки вводимых (входных) данных заключается в отсутствии проверки значений, избыточном количестве значений, неопределенности значений вводимых (входных) данных;
— недостатки, связанные с возможностью прослеживания пути доступа к каталогам.
Примечание — Прослеживание пути доступа к каталогам заключается в отслеживании пути доступа к каталогу (по адресной строке/составному имени) и получении доступа к предыдущему/корневому месту хранения данных;
— недостатки, связанные с возможностью перехода по ссылкам.
Примечание — Переход по ссылкам связан с возможностью внедрения нарушителем ссылки на сторонние ресурсы, которые могут содержать вредоносный код. Для файловых систем недостатками являются символьные ссылки и возможности прослеживания по ним нахождения ресурса, доступ к которому ограничен;
— недостатки, связанные с возможностью внедрения команд ОС.
Примечание — Внедрение команд ОС заключается в возможности выполнения пользователем команд ОС (например, просмотра структуры каталогов, копирование, удаление файлов и другие команды);

— недостатки, связанные с межсайтовым скриптингом (выполнением сценариев).
Примечание — Межсайтовый скриптинг обычно распространен в веб-приложениях и позволяет внедрять код в веб-страницы, которые могут просматривать нелегитимные пользователи. Примерами такого кода являются скрипты, выполняющиеся на стороне пользователя;
— недостатки, связанные с внедрением интерпретируемых операторов языков программирования или разметки.
Примечание — Недостатки связаны с внедрением интерпретируемых операторов языков программирования (например, операции выбора, добавления, удаления и другие) или разметки в исходный код веб-приложения;
— недостатки, связанные с внедрением произвольного кода.
Примечание — Недостатки связаны с внедрением произвольного кода и части кода, которые могут приводить к нарушению процесса выполнения операций;
— недостатки, связанные с переполнением буфера памяти.
Примечание — Переполнение буфера возникает в случае, когда ПО осуществляет запись данных за пределами выделенного в памяти буфера. Переполнение буфера обычно возникает из-за неправильной работы с данными, полученными извне, и памятью, при отсутствии защиты со стороны среды программирования и ОС. В результате переполнения буфера могут быть испорчены данные, расположенные следом за буфером или перед ним. Переполнение буфера может вызывать аварийное завершение или зависание ПО. Отдельные виды переполнений буфера (например, переполнение в стековом кадре) позволяют нарушителю выполнить произвольный код от имени ПО и с правами учетной записи, от которой она выполняется;
— недостатки, связанные с неконтролируемой форматной строкой.
Примечание — Форматная строка в языках C/C++ является специальным аргументом функции с динамически изменяемым числом параметров. Ее значение в момент вызова функции определяет фактическое количество и типы параметров функции. Ошибки форматной строки потенциально позволяют нарушителю динамически изменять путь исполнения программы, в ряде случаев — внедрять произвольный код;

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

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

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

Библиография

	Федеральный закон Российской Федерации «Об информации, информационных технологиях и о защите информации» от 27 июля 2006 г. N 149-ФЗ

УДК 004: 006.354	ОКС 35.020
Ключевые слова: информационная система, программное обеспечение, защита информации, уязвимость, недостаток, классификация, угроза безопасности

Электронный текст документа
подготовлен АО «Кодекс» и сверен по:
официальное издание
М.: Стандартинформ, 2018

• Авторы
• Резюме
• Файлы
• Ключевые слова
• Литература

Ковалева К.А. 1 Глущенко Р.В. 2 1 1ФГБОУ ВПО «Ростовский государственный экономический университет» в г. Черкесске 2 ФГБОУ ВПО «Ростовский государственный экономический университет» в г. Черкесске Рассмотрены вопросы построения системы информационной безопасности в соответствии со стандартами, предъявляемыми регуляторами по вопросам информационной безопасности в Российской Федерации (ФСБ, ФСТЭК, Роскомнадзор). Для многих компаний, прежде всего, финансовых организаций, производственных холдингов, крупных дистрибьюторов бесперебойная работа ИС, поддерживающих основной бизнес, и доступность данных становятся критичным вопросом.Для проведения качественного аудита информационной безопасности фирме- аудитору должна быть предоставлена исчерпывающая информация об информационной инфраструктуре предприятия и методах ее защиты. Аудит информационной безопасности позволяет объективно и всесторонне оценить текущее состояние системы обеспечения информационной безопасности компании.Необходимым элементом организации работ по обеспечению безопасности информации, ее носителей и процессов обработки в автоматизированной системе организации является определение требуемых степеней защищенности ресурсов. 118 KB защита информации аудит информационной безопасности модели угроз 1. Защита персональных данных: 2010 // Искусство управления информационной безопасностью: – Москва.: 2003. / под ред. Слепова Олега. 2. Комплексная защита конфиденциальной информации: Учебно-методическое пособие. – Москва: 11- формат, 2013. – 174. / под ред. А.О. Чефранова, А.Г. Масленникова, Ю.Ф. Алабина. 3. Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных». 4. http://ru.wikipedia.org/wiki/Информационная_безопасность 5. http://infoguard.ru/legislation?ID=1&show_id=4&chaper=3 Введение

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

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

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

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

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

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

Рисунок 1 – Общая структура обследования.

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

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

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

3. Информация о системном программном обеспечении: данные об операционных системах серверов и рабочих станций.

4. Информация о прикладном программном обеспечении: данные о СУБД, прикладных программах и т.д.

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

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

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

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

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

3. На третьем этапе представители фирмы-аудитора выезжают на территорию фирмы-заказчика и обследуют ИС, а так же проводят опрос сотрудников, которые работают с ИС, обеспечивают ее работоспособность.

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

5. На пятом этапе сотрудники фирмы-аудитора обрабатывают полученную информацию и пишут отчет о проведенном обследовании.

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

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

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

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

2. выявить слабые и потенциально уязвимые места, возможные риски;

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

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

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

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

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

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

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

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

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

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

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

Любые изменения состава и полномочий пользователей подсистем АС должны производиться установленным порядком согласно специальной «Инструкции по внесению изменений в списки пользователей АС и наделению их полномочиями доступа к ресурсам системы».

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

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

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

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

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

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

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

Библиографическая ссылка

Ковалева К.А., Глущенко Р.В. ПОСТРОЕНИЕ СИСТЕМЫ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ // Международный студенческий научный вестник. – 2014. – № 1.;
URL: http://www.eduherald.ru/ru/article/view?id=11803 (дата обращения: 26.10.2020).Предлагаем вашему вниманию журналы, издающиеся в издательстве «Академия Естествознания» (Высокий импакт-фактор РИНЦ, тематика журналов охватывает все научные направления) «Современные проблемы науки и образования» список ВАК ИФ РИНЦ = 0.791 «Фундаментальные исследования» список ВАК ИФ РИНЦ = 1.074 «Современные наукоемкие технологии» список ВАК ИФ РИНЦ = 0.909 «Успехи современного естествознания» список ВАК ИФ РИНЦ = 0.736 «Международный журнал прикладных и фундаментальных исследований» ИФ РИНЦ = 0.570 «Международный журнал экспериментального образования» ИФ РИНЦ = 0.431 «Научное Обозрение. Биологические Науки» ИФ РИНЦ = 0.303 «Научное Обозрение. Медицинские Науки» ИФ РИНЦ = 0.380 «Научное Обозрение. Экономические Науки» ИФ РИНЦ = 0.600 «Научное Обозрение. Педагогические Науки» ИФ РИНЦ = 0.308 «European journal of natural history» ИФ РИНЦ = 1.369 Издание научной и учебно-методической литературы ISBN РИНЦ DOI

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

• Оценка на соответствие эталону (бывает текущая и «эталонная», в идеале проводятся обе);
• Риск-менеджмент;
• Экономическая целесообразность.

Разберем эти понятия подробнее.

Оценка состояния информационной безопасности на соответствие эталону

В качестве «эталона» обычно принимаются (в совокупности и отдельно):

• требования национальных или международных стандартов в области ИБ (ГОСТ, NIST);
• требования законодательства Российской Федерации в области ИБ;
• отраслевые требования по обеспечению ИБ, отдельные для разных сфер деятельности;
• а также требования нормативных, методических и организационно-распорядительных документов по обеспечению ИБ внутри компании.

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

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

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

Риск-менеджмент

Эта оценка рассматривает риски ИБ, возникающие в сфере конкретной организации и что было сделано для минимизации возможности возникновения, обработки/управления в целом. Для этого сначала определяют риски и их ключевые индикаторы, формируют на их основе критерии оценки, собирают свидетельства процессов по подготовке к встрече с рисками или результаты непосредственного инцидента, и, после измерения риск-факторов, формируется финальная оценка. Обычно риски измеряют по тяжести возможных последствий (ущербу) и по вероятности реализации угрозы. Соответственно, процессы контроля и реагирования заключаются в снижении либо эффекта, либо вероятности реализации риска. Большинство стен можно проломить тем или иным способом, но если затраты времени, усилий и прочих ресурсов значительно превышают возможную выгоду, то вероятность что кто-то будет этим заниматься, да еще и успеет сделать до подключения команды реагирования, крайне мала. Еще меньше вероятность того, что хакер сочтет это стоящим постоянного риска разоблачения и, во многих странах, уголовной ответственности. Одна из основных проблем такой оценки — это сложность понимания какие именно вещи могут привести к тяжким и дорогостоящим последствиям, а какие нет. В документации NIST приводится возможное прогнозирование ежегодных потерь с помощью определения информационного актива, фактора подверженности воздействию и ежегодной частоте появления, но даже данные этого уравнения достаточно размыты и могут предложить скорее некие рамки, чем реальные точные цифры. К тому же, как верно указано в ГОСТ Р ИСО/МЭК ТО 18044-2007, «незначительный инцидент ИБ может перейти в категорию «существенный» или в «кризисную ситуацию» в случае его неправильной обработки, или незначительный инцидент ИБ, не обработанный в течение недели, может стать «значительным» инцидентом ИБ.» Как раз потому, что собственные процессы компании могут стать разрушительными, а еще потому, что реагирование и контроль рисков можно проверить экспериментальным путем, в основном риск-ориентированная оценка направлена на анализ того, как менеджмент предприятия действует в отношении рисков — как оценивает, какими способами контролирует и реагирует, в отличие от простого перечня и классификации возможных рисков в вакууме. Такая проверка в меньшей степени тестирует «стены», это скорее прогнозирование потенциальных угроз и анализ действий защитников.

Экономическая целесообразность

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

Самостоятельное или независимое оценивание?

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

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

Я провожу независимое оценивание ИБ любого типа и сложности, возможны пентесты и приведение в соответствие по положениям 683-П, 684-П и ГОСТ 57580.1, ГОСТ 57580.2. Если вам нужна консультация по вопросам информационной безопасности, проведение независимой оценки вашей защиты, досудебные и судебные экспертизы по вопросам IT, а также экспертиза документации в этой области или разработка организационно распорядительной документации «с ноля» — оставляйте заявку в этой форме, они принимаются круглосуточно.

Автор статьи: Царев Евгений