Методические основы защиты систем поддержки бизнеса

Д. КОСТРОВ, начальник отдела ИБ ОАО «МТТ»

Приятно сознавать, что сегодня уже есть прецеденты внедрения и проработки проектов специализированных информационных систем 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 определяется руководством организации. Внешний аудит проводится независимыми аудиторами и не реже одного раза в год. Цель аудита ИБ организации - проверка и оценка ее соответствия требованиям (возможен выбор требований международного стандарта) и других принятых в организации нормативов.

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

Особенности жанра

Применение систем OSS/BSS в телекоммуникационной отрасли имеет свои особенности. Например, задача контроля арендованных каналов наложенных сетей сегментного типа, построенных на арендованном ресурсе каналов ВСС РФ, должна включать в себя несколько составляющих. Так, общий контроль надежности предоставляемого в аренду ресурса обеспечивается мониторингом сигналов о неисправностях. 6 терминах OSS — это подгруппа функций управления неисправностями (Fault Management). В то же время контроль качества предоставляемых в аренду каналов (в соответствии с нормами национальных стандартов или заключенных SLA-соглашений) должен включать в себя не только регистрацию данных сигналов, но и измерение параметров ошибок различного типа. В терминах OSS -подгруппа функций управления SLA (SLA Monitoring). Другой пример - коммутация. Основная функция этой системы — пропуск трафика операторов через сеть оператора международной/междугородной связи. Здесь OSS должна выполнять контроль работоспособности оборудования системы коммутации (подгруппа управления неисправностями - Fault Management), контроль неисправностей в данной системе и фиксирование любых неисправностей в системе передачи трафика (подгруппа та же). Контроль качества передачи трафика в настоящее время регламентируется отдельными договорами о качестве предоставления услуг (подгруппа SIA Monitoring). Однако, поскольку эффективность работы сети зависит не только от качества предоставляемых услуг, но и от эффективности загрузки системы коммутации, в перечень функций OSS входит и контроль эффективности работы последней (подгруппа управления рабочими характеристиками - Performance Management). Особая задача OSS - контроль восстановления работы сети при возникновении сбоев в системе коммутации (подгруппа та же). OSS, интегрированная в сеть оператора, представляет собой взаимосвязанную административно-техническую систему для эксплуатации сети связи, разделенную на отдельные функциональные подсистемы, но управляемую централизованно. Классический подход к построению автоматизированной системы эксплуатации (АСОТЭ) -дробление ее на две основные подсистемы: автоматизированного управления (АСОТУ) и автоматизированного обслуживания (АСОТО). В современную трактовку классической схемы добавляется важный компонент — подсистема учета и контроля качества (СКК).

Случай из жизни

Одна из известных телекоммуникационных компаний российского рынка намерена одновременно внедрить пять (1) подсистем OSS/BSS, интегрированных между собой и с информационными системами предприятия, среди которых ERP Axapta (Microsoft Navision), а также АСР. Цель проекта - автоматизация процессов подключения, эксплуатации и поддержки пользователей. Перечень внедряемых подсистем включает учет сетевых ресурсов, документирование и планирование сети (Network Resource Inventory, Documentation and Planning), управление профилем клиента и каталог услуг (центральная БД клиентов - CRM), управление заказами (Order Management), решение возникающих проблем клиентов/создание проблемных билетов (Problem Management, Trouble Tickets, Help Desk), предбиллинг и сбор статистики (Billing Mediation).

***

Несколько лет назад одна крупная телекоммуникационная компания едва не стала жертвой экономического шпионажа со стороны конкурирующей фирмы, пытавшейся завладеть сразу тремя базами данных: всех документов (форм), информационной системы контроля качества и системы Trouble Ticketing. Отдел экономической разведки конкурента (официально он назывался, конечно, иначе) хотел «малой кровью» заполучить сертификат ISO 9001. Ресурс с нужными данными в сети потенциальной жертвы носил гриф доступа secret, а всего насчитывалось четыре уровня безопасности данных: open, not for all, secret, top Secret. Для сотрудников компании этот 3-й уровень был открыт и размещался во внутренней офисной сети, доступ извне к которой считался практически невозможным, поскольку специалисты отдела ИБ достаточно серьезно защитили периметр (межсетевые экраны, системы IDS и т.п.) и любая внешняя активность была бы сразу замечена. Но нашелся недовольный сотрудник, который за смешные деньги взялся скопировать все данные на диск. Только система host IDS, развернутая на критических серверах, да еще глупость инсайдера решили дело: он начал копировать все подряд, что и обнаружила система, поскольку такой профиль доступа к информации не был предусмотрен.

Список литературы

Журнал ИнформКУРЬЕРсвязь №9, 2005 г.