Методические основи захисту систем підтримки бізнесу

Методические основи захисту систем підтримки бизнеса

Д. БАГАТЬ, начальник відділу ВБ ВАТ «МТТ».

Приятно усвідомлювати, що сьогодні вже є прецеденти вживлення і проробки проектів спеціалізованих інформаційних систем 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 17 799−2000 слід залучити в трудові контракти (угоди, договоры).

Хотя здебільшого вбудовані механізми захисту однак фахівці вважають «несерйозними», нехтувати ними годі. Іноді такий додатковий пароль стає тієї соломинкою, що створить останній, «непрохідний» кордон безопасности.

При розподілі прав доступу персоналу до системи слід керуватися трьома принципами, доцільність яких викладена у ISO TR 13 569:

«знание своїх службовців» (Know your Employee) -припускати можливі проблеми співробітників, які можуть призвести до зловживань ресурсами фірми, аферам чи махинациям;

«необходимые знання» (Need to Know) — дотримуватися правил безпеки обмеження доступу до інформації та ресурсів осіб, кому потрібно виконувати певні обязанности;

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

Важное умова забезпечення захищеності як системи OSS/BSS, і у цілому ІВ компанії - виділення окремого підрозділи з відповідними функціями. Головна завдання цього підрозділу — створення певних гарантій те, що рівень організації ВБ достатній стосовно цілям бізнесу организации.

И ще одне зауваження. Безпека систем OSS/BSS повинна забезпечуватися усім стадіях життєвого циклу (ЖЦ) з урахуванням інтересів усіх сторін, утягнутих у процеси ЖЦ (розробників, замовників, постачальників продуктів і постачальники послуг, експлуатують і наглядових підрозділів організації). У цьому модель ЖЦ (стадії ЖЦ, етапи робіт і процеси ЖЦ, що їх цих стадіях) рекомендується визначати в відповідність до ГОСТ 34.601 і документом ISO/IEC IS 15 288, а розробку технічних завдань, проектування, створення, тестування і прийомку засобів і систем захисту 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 г.