Д. КОСТРОВ, начальник отдела ИБ ОАО «МТТ»
Приятно сознавать, что сегодня уже есть прецеденты внедрения и проработки проектов специализированных информационных систем OSS/BSS многими российскими операторами связи для управления производственной деятельностью, эффективного хранения и использования различной информации (перечень оборудования, данные о работоспособности элементов системы, наборы конфигураций, реестры клиентов, услуг, тарифов и т.п.). Это означает, что компании выходят на более высокий уровень управления своими ИС.
Угрозы, риски, рекомендации
С немалой долей вероятности можно сказать, что наибольшую опасность для системы OSS/BSS будут представлять внутренние злоумышленники (инсайдеры). Внешние злоумышленники без поддержки внутренних вряд ли смогут нарушить работу бизнес-процессов, выполняемых в рамках OSS/BSS. Поэтому к наиболее опасным источникам угроз на уровне бизнес-процессов относятся внутренние, которые реализуются как в рамках полномочий служащих, так и за их пределами (авторизованные пользователи и операторы, представители менеджмента организации и пр.). Далее по рангу - комбинированные источники, которые подразделяются на внешние (например, конкуренты) и внутренние, действующие «в сговоре» с первыми.
Главная цель злоумышленника - получить контроль над активами на уровне бизнес-процессов. Прямое нападение на этом уровне (например, путем раскрытия конфиденциальной информации) более эффективно для нападающего и опаснее для собственника, чем атака на нижних уровнях -физическом (линии связи, аппаратные средства и пр.), сетевом (сетевые аппаратные средства: маршрутизаторы, коммутаторы, концентраторы и т.п.); приложений и сервисов (ОС, СУБД, технологических процессов и приложений). Причина - атаки на нижних уровнях требуют специфического опыта, знаний и ресурсов (в том числе и временных), а потому менее эффективны по соотношению затраты/результат. Чаще всего потенциальный злоумышленник стремится либо получить доступ к информации базы данных, циркулирующей (хранящейся) в системе OSS/BSS, либо нарушить ход штатного (строго описанного) бизнес-процесса. На стадии эксплуатации должна быть обеспечена также защита от умышленного несанкционированного раскрытия, модификации или уничтожения информации, неумышленной модификации или уничтожения информации, недоставки или ошибочной доставки информации, ухудшения обслуживания или отказа в нем. Кроме того, на сетях связи весьма актуальна угроза отказа от авторства сообщения. Для этого сейчас служит ЭЦП под сообщениями или их массивами.
С точки зрения архитектуры система OSS/BSS всегда наложена на существующую офисную компьютерную сеть, и поэтому, как правило, представляет собой выделенную подсеть с повышенным уровнем защиты (например, на базе технологии VLAN с контролируемым доступом на 3-м уровне и с применением списков доступа), где достаточно просто реализовать контроль несанкционированных действий. Поэтому при оценке рисков необходимо точно определить, какую именно информацию обрабатывают подсистемы, входящие в OSS/BSS.
Часто для систем OSS/BSS предусматриваются дополнительные меры безопасности, например добавочный уровень аутентификации пользователя. То есть для доступа к ПЭВМ работник компании использует общий USB-токен, а для вызова программы (клиента) системы OSS/BSS он должен предъявить дополнительный ключ.
Обычно во внутренней сети вся информация относится к уровню «для внутреннего использования», однако владельцы (не пользователи и не хранители) информации могут отнести ее и к уровню «коммерческая тайна» с дополнительным уровнем обеспечения защищенности (например, введя дополнительную аутентификацию при доступе). Поэтому следует выделить и определить соответствующие роли персонала организации и установить степень ответственности за исполнение этих ролей. Формирование ролей, как правило, должно осуществляться на основании бизнес-процессов, а ответственность зафиксирована в должностных инструкциях.
Не рекомендуется применять ролевой механизм, где одна персональная роль включает все правила, необходимые для выполнения полного бизнес-процесса в рамках системы OSS/BSS. Совокупность правил, составляющих роли, не должна быть критичной для компании с точки зрения последствий успешного нападения на исполнителя данной роли. Не следует совмещать в одном лице (в любой комбинации) роли разработки, сопровождения, исполнения, администрирования или контроля (например, оператора и администратора, администратора и аудитора). Обязанности персонала по выполнению требований ИБ в соответствии с положениями ISO TR13569 и БО/1ЕС IS 17799-2000 следует включать в трудовые контракты (соглашения, договоры).
Хотя в большинстве случаев встроенные механизмы защиты специалисты считают «несерьезными», пренебрегать ими не стоит. Иногда такой дополнительный пароль становится той соломинкой, которая создаст последний, «непроходимый» рубеж безопасности.
При распределении прав доступа персонала к системе следует руководствоваться тремя принципами, суть которых изложена в ISO TR 13569:
«знание своих служащих» (Know your Employee) -предполагать возможные проблемы сотрудников, которые могут привести к злоупотреблениям ресурсами фирмы, аферам или махинациям;
«необходимые знания» (Need to Know) - соблюдать правила безопасности для ограничения доступа к информации и ресурсам тех лиц, кому требуется выполнять определенные обязанности;
«двойное управление» (Dual Control) - использовать в системе независимое управление для сохранения целостности процесса и борьбы с искажением функций системы, которое отражено в требовании ИБ выполнять некое действие до завершения определенных транзакций двумя лицами независимо друг от друга.
Важное условие обеспечения защищенности как системы OSS/BSS, так и в целом ИС компании - выделение отдельного подразделения с соответствующими функциями. Главная задача этого подразделения - создание определенных гарантий того, что уровень организации ИБ достаточен по отношению к целям бизнеса организации.
И еще одно замечание. Безопасность систем OSS/BSS должна обеспечиваться на всех стадиях жизненного цикла (ЖЦ) с учетом всех сторон, вовлеченных в процессы ЖЦ (разработчиков, заказчиков, поставщиков продуктов и услуг, эксплуатирующих и надзорных подразделений организации). При этом модель ЖЦ (стадии ЖЦ, этапы работ и процессы ЖЦ, выполняемые на этих стадиях) рекомендуется определять в соответствии с ГОСТ 34.601 и документом ISO/IEC IS 15288, а разработку технических заданий, проектирование, создание, тестирование и приемку средств и систем защиты OSS/BSS следует обязательно согласовывать с отделом ИБ (ОИБ). Ввод в действие, эксплуатация, снятие с эксплуатации систем OSS/BSS - все должно проходить при обязательном участии ОИБ.
Диалектика политики
Необходимо отметить, что при разработке политики обеспечения ИБ компании требования в общем случае должны быть взаимоувязаны в непрерывный по задачам, подсистемам, уровням и стадиям жизненного цикла процесс. Перечень минимально необходимых средств включает защиту от несанкционированных действий, управления доступом и регистрацией в системах (в том числе и OSS/BSS), в телекоммуникационном оборудовании, АТС и т.д., а также антивирусную защиту, средства контроля использования ресурсов Интернета, криптографической защиты информации и защиты информационных технологических процессов (в том числе и системы OSS/BSS). Кроме того, необходимы и организационные меры для определения назначения и распределения ролей и уровней доверия для персонала.
В политике информационной безопасности компании могут присутствовать и другие требования, например обеспечение непрерывности бизнес-процессов, физическая защита ресурсов и активов и т.д. Соблюдение политики в значительной мере есть элемент корпоративной этики, поэтому на уровень ИБ в организации оказывают серьезное влияние отношения как в коллективе, так и между коллективом и собственником или менеджментом организации, представляющим интересы собственника. Вместе с тем назначение/лишение полномочий доступа сотрудников к ресурсам сети и системы санкционируется руководителем функционального подразделения организации, несущего персональную ответственность за обеспечение ИБ в данном подразделении.
Увы, но любые защитные меры по ряду объективных причин имеют тенденцию к ослаблению своей эффективности, в результате чего снижается общий уровень ИБ, что неминуемо ведет к возрастанию рисков ИБ. Чтобы не допустить этого, нужно проводить регулярный мониторинг и аудит системы ИБ и своевременно принимать меры по поддержанию системы управления ИБ на необходимом уровне. В идеале должна действовать циклическая модель: планирование-реализация-проверка-совершенствование-планирование.
В целом требования ИБ к OSS/BSS не отличаются от требований для сети предприятия, которые включают идентификацию, аутентификацию, авторизацию; управление доступом; контроль целостности и регистрацию пользователей. При этом рекомендуется организовать службу централизованной парольной защиты для генерации, распространения, смены, удаления паролей, разработки необходимых инструкций, контроля за действиями персонала по работе с паролями (хорошей практикой является использование e-Tokens с сертификатами открытых ключей).
Не следует забывать и о регистрации действий персонала и пользователей в специальном электронном журнале, который должен быть доступен для чтения, просмотра, анализа, хранения и резервного копирования только администратору ИБ. Для контроля реализации положений нормативных актов по обеспечению ИБ, выявления нештатных (или злоумышленных) действий и потенциальных нарушений ИБ сотрудники ОИБ выполняют мониторинг ИБ.
Несколько слов об аудите ИБ. Его необходимо проводить периодически, при этом он может быть внутренним или внешним. Порядок и периодичность проведения внутреннего аудита ИБ организации в целом (или ее отдельных структурных подразделений) или системы OSS/BSS определяется руководством организации. Внешний аудит проводится независимыми аудиторами и не реже одного раза в год. Цель аудита ИБ организации - проверка и оценка ее соответствия требованиям (возможен выбор требований международного стандарта) и других принятых в организации нормативов.