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


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

15.04.2002 Искандер Конеев

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

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

Искандер Рустамович Конеев — начальник отдела безопасности компьютерных систем Национального банка Узбекистана. С ним можно связаться по электронной почте: [email protected]
Выбор автоматизированной информационной системы любого уровня — вспомогательной или основной для бизнес-деятельности — серьезный шаг для предприятия и обычно имеет статус отдельного проекта, оформляемого соответствующими документами. Одним из таких документов может быть техническое задание или технические требования к системе, где должны быть определены критерии оценки различных параметров системы: информационной архитектуры, бизнес-функций, интерфейсов и многого другого. В этом списке, видимо, окажутся и требования к информационной безопасности (подсистеме безопасности) системы. Весовые коэффициенты, то есть значимость того или иного параметра для данной системы и для организации в целом, должны быть расставлены в соответствии с потребностями предприятия.

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

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

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

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

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

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

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

Общие требования

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

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

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

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

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

2) любые перемещения данных из/в систему происходили под контролем подсистемы безопасности.

Специальные требования

Идентификация и аутентификация

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

Основным средством аутентификации пользователей в АС должна быть схема «имя пользователя/пароль», при этом система должна допускать возможность расширения процедур аутентификации на основе смарт-карты, touch memory, дискеты. При этом должна присутствовать возможность дифференцированного считывания информации с токена — пароля или ПИН-кода при аутентификации, ключа при шифровании или электронно-цифровой подписи.

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

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

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

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

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

  • к группе или нескольким группам объектов;
  • к объекту;
  • к набору частей объекта.

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

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

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

  • нет доступа к объекту;
  • доступ (к объекту/части объекта) только на чтение;
  • доступ (к объекту/части объекта) только на изменение - отдельно с чтением и без чтения;
  • удаление информационного объекта;
  • добавление информационного объекта;
  • нет доступа на чтение;
  • нет доступа на изменение;
  • нет доступа на добавление;
  • нет доступа на удаление.

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

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

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

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

Доступ к бюджетам пользователя

АС должна поддерживать возможность отдельного распределения доступа пользователя:

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

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

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

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

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

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

Дополнительные права

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

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

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

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

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

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

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

Целостность данных

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

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

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

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

  • без подписи;
  • одна подпись;
  • две подписи;
  • три подписи.

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

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

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

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

Доступность данных

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

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

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

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

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

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

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

Удаленная работа

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

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

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

Аудит и мониторинг

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

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

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

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

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

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

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

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

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

Каждое событие должно обладать как минимум следующими реквизитами:

  1. автор (пользователь, который породил это событие);
  2. время (календарная дата и время, когда событие произошло);
  3. категория события;
  4. события;
  5. объект события;
  6. описание события (конкретные подробности события и объекта);
  7. филиал организации, затронутый событием.

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

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

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

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

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

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

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

Разрешение на получение консолидированных (сводных) отчетов может определяться отдельно.

Интерфейсы

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

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

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

  • процедуры и обязанности по безопасности для пользователя;
  • процедуры и обязанности по безопасности для бизнес-администратора (прикладного администратора);
  • процедуры и обязанности по безопасности для системного администратора;
  • руководство для администратора безопасности системы.

Поставщик должен:

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

Расширение функциональности безопасности

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

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

Оценка системы

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

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

Требования к защите информации

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

Защита информациидолжна быть:

- централизованной;

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

- плановой;

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

- конкретной и целенаправленной;

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

- активной;

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

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

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

- нестандартной(по сравнению с другими организациями), разнообразной по используемым средствам;

- открытойдля изменения и дополнения мер обеспечения безопасности информации;

- экономически эффективной;

затраты на систему защиты не должны превышать размеры возможного ущерба.

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

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

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

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

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

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

Цель планирования:

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

  • наилучшее использование всех выделенных ресурсов;

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

Различают два вида планирования: стратегическое или перспективное и тактическое или текущее.

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

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

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

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

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

Планирование включает в себя определение, разработку или выбор:

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

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

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

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

  • порядка ввода в действие средств защиты;

  • ответственности персонала;

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

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

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

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

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

Нужно уметь четко ответить на следующие вопросы:

  • Сколько компьютеров (вспомогательного оборудования) установлено в организации? Сколько их на рабочих местах, сколько в ремонте, сколько в резерве.

  • Можно ли узнать каждый компьютер «в лицо»?

  • Можно ли обнаружить «маскарад» оборудования, когда какой-нибудь компьютер или его часть, или программное обеспечение подменены?

  • Какие задачи и с какой целью решаются на каждом компьютере?

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

  • Каков порядок ремонта и технической профилактики компьютеров?

  • Как проверяется оборудование, возвращаемое из ремонта, перед установкой на рабочее место?

  • Как производится изъятие и передача компьютеров в подразделения и каков порядок приема в работу нового оборудования?

Список вопросов можно продолжить. Аналогичные вопросы можно задать и относительно программного обеспечения и персонала.

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

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

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

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

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

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

  • использование только дополнительных технических средств защиты информации.

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

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

41. Оценка информационной безопасности ис: стандарты и классы иб, требования к иб.

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

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

В ней выделены основные классы защищенности - D, C, B, A.

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

Класс C1: ИС должна управлять доступом именованных пользователей к именованным объектам; пользователи должны идентифицировать себя до выполнения каких-либо контролируемых ИС действий; ИС должна быть защищена от внешних воздействий и от попыток слежения за ходом работы.

Класс C2 (в дополнение к C1): все объекты должны подвергаться контролю доступа; каждый пользователь системы должен уникальным образом идентифицироваться; каждое регистрируемое действие должно ассоциироваться с конкретным пользователем; ликвидация всех следов внутреннего использования объектов ИС.

Класс B1 (в дополнение к C2): каждый хранимый объект ИС должен иметь отдельную идентификационную метку; ИС должна обеспечить реализацию принудительного управления доступом к хранимым объектам.

Класс B2 (в дополнение к B1): должна быть предусмотрена возможность регистрации событий, связанных с организацией тайных каналов обмена информацией; ИС должна быть внутренне структурирована и демонстрировать устойчивость к попыткам проникновения.

Класс B3 (в дополнение к B2): для управления доступом должны использоваться списки управления доступом с указанием разрешенных режимов; должна быть предусмотрена возможность регистрации появления или накопления событий, несущих угрозу политике ИБ.

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

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

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

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

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

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

  2. Описание позиции организации - описаны ресурсы ИС, перечень допущенных к ресурсам лиц и процессов.

  3. Применимость - порядок доступа к данным ИС.

  4. Роли и обязанности - определяются ответственные должностные лица и их обязанности.

  5. Соблюдение политики - описываются права и обязанности пользователей ИС.

Исходные положения правового обеспечения процессов информатизации в Беларуси определены Концепцией государственной политики в области информатизации, одобренной Указом Президента Республики Беларусь от 6 апреля 1999 г. № 195. В Концепции национальной безопасности, утвержденной Указом Президента Республики Беларусь от 17 июля 2001 г. № 390 определены приоритетные направления и основные принципы обеспечения безопасности Республики Беларусь в информационной сфере.

Закон Республики Беларусь «Об информации, информатизации и защите информации» от 10 ноября 2008 г. регулирует правоотношения, возникающие в процессе формирования и использования документированной информации и информационных ресурсов.

2.1 Требования к обеспечению информационной безопасности

Центральный Банк РФ в положении 382-П установил конкретные требования к защите информации при осуществлении переводов денежных средств. Эти требования связаны с организацией и контролем обеспечения защиты информации в платёжных системах. В положении представлены следующие группы требований:

· защита информации при назначении и распределении ролей;

· защита информации на стадиях жизненного цикла объектов ИТ-инфраструктуры;

· защита информации при осуществлении доступа к объектам ИТ-инфраструктуры;

· защита информации от воздействия вредоносного кода;

· защита информации при использовании сети Интернет;

· защита информации с использованием СКЗИ;

· защита информации с использованием технологических мер защиты информации;

· организация и функционирование службы ИБ;

· повышение осведомленности в области обеспечения защиты информации;

· выявление и реагирование на инциденты;

· определение и реализация порядка обеспечения защиты информации;

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

Рассмотрим требования, изложенные в 382-П и ISO 27xxx, к техническим и организационным аспектам управления ИБ: служба ИБ, управление логическим доступом пользователей к активам организации, управление защищенной передачей данных (доступ к средствам обработки информации, защита от вредоносного ПО, система криптографической защиты информации).

Служба информационной безопасности создается руководством с целью реализации, эксплуатации, контроля и поддержания на должном уровне СОИБ. В таблице 3 представлены требования [2] и [3-6] к службе ИБ.

Управление доступом - комплекс мероприятий, направленных на предотвращение несанкционированного доступа (НСД) [12]. Под НСД понимают доступ к информации, нарушающий правила разграничения доступа с использованием штатных средств, предоставляемых средствами вычислительной техники или автоматизированными системами (СВТ/АС). Управление доступом возможно на различных уровнях операционной системы, баз данных и приложений. В таблице 4 представлены требования [2] и [3-6] к системе управления доступом пользователей к информационным активам.

Табл.3. Сравнение требований к службе ИБ

ISO 27xxx

382-П

Служба ИБ

1. Обеспечить формирование службы ИБ

(определить цели и задачи службы и довести до сотрудников)

2. Все ответственности по ИБ должны быть строго определены и закреплены

1. Должна поддерживаться связь с органами по ИБ, а также специалистами

2. ИБ должна осуществляться при управлении проектами, независимо от типа проекта

1. Обеспечить формирование службы ИБ в филиалах

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

Табл.4 . Сравнение требований к системе управления доступом

ISO 27xxx

382-П

Управление доступом пользователей

1. Права выдаются в соответствии с политикой ИБ

2. Журнал регистрации пользователей

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

1. Механизмы аутентификации и идентификации;

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

1. Реализация запрета совмещения одним лицом следующих ролей:

· связанных с созданием (модернизацией) объекта информационной инфраструктуры и эксплуатацией объекта информационной инфраструктуры;

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

СТО 1.0 - СЗИ от НСД

Управление сетевым

Доступом

1. Устанавливаются интерфейсы (МЭ) и фильтры, проверяющие полномочия потока данных, входящих и исходящих из сети

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

3. Производится управление доступом пользователей к сервисам и сетям

1. Устанавливаются интерфейсы (МЭ) и фильтры, проверяющие полномочия потока данных, входящих и исходящих из сети

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

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

Организации, входящие в платёжную систему, часто проводят платежи электронным способом, поэтому организация заинтересована в эффективных комплексных СОИБ, защищающих сети от атак злоумышленников и возможных случайных неправильных действий, а также обеспечивающие конфиденциальность, целостность и доступность информации. Требования к управлению защищенной передачи данных [2] и [3-6] представлены в таблице 5:

Табл.5 Сравнение требований 382-П и ISO 27xxx

ISO 27xxx

382-П

Доступ к средствам обработки

Информации

1. Доступ к объектам осуществляется на основе политики управления доступом

2. Осуществляется учёт объектов информатизации

3. Применение некриптографических средств защиты информации от НСД

4. Механизмы идентификации, аутентификации, авторизации работников

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

6. Реализация запрета несанкционированного расширения прав доступа к защищаемой информации

7. Использования ТСЗИ

8. Контроль объектов информатизации на наличие средств несанкционированного съема информации

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

Защита от

вредоносного ПО

1. Использование антивирусного ПО

2. Регулярное обновление

3. Формирование для клиентов рекомендаций по защите информации от вредоносного ПО

4. Детальная проверка системы на наличие вредоносного ПО

5. Обеспечивать оповещение в случае обнаружения вредоносного ПО

6. Меры по восстановлению системы после атак

1. Политика использование лицензионных программ на объектах информатизации.

Криптографическая защита

1. Разработать политику использования СКЗИ

2. Политика управление криптографическими ключами

1. Внедрение политики по использованию СКЗИ в ЖЦ

2. Допускает встраивание СКЗИ в процессы осуществления переводов денежных средств

Вывод к разделу 2

СОИБ в организациях банковской сферы представляет собой совокупность организационных и технических мер по защите информационных активов. Модель построения СМИБ основывается на циклической модели Деминга. Различие подходов, изложенных в стандарте ЦБ РФ и международном стандарте ISO 27xxx, состоит в подходе к построению СМИБ. В таблице 3 представлено сравнение требований, изложенных в 382-п и ISO/IEC 27001-2013 к системам:

· служба ИБ;

· управления доступом;

· управление защищенной передачей данных.

Требования, изложенные в этих двух нормативных документах, призваны построить эффективную СОИБ. Возможно построение СОИБ на соответствие требованиям, как российским, так и международным стандартам. Требования 382-П более приспособлены к сфере платёжных систем.


Смотрите также