Методичні основи захисту систем підтримки бізнесу
Д. Костров, начальник відділу ІБ ВАТ «МТТ»
Приємно
усвідомлювати, що сьогодні вже є прецеденти впровадження та опрацювання проектів спеціалізованих
інформаційних систем 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 р.
