Чого ви навчитеся
Розкрийте десять найпоширеніших прогалин у доступі до ERP та фінансових додатків, зрозумійте, як кожна з них дозволяє шахрайству прослизати крізь ваш внутрішній контроль, і отримайте практичні рішення для кожної з них.
Багато організацій інвестують значні кошти в брандмауери, захист кінцевих точок та виявлення загроз. Це правильний інстинкт. Але поки периметр блокується, двері залишаються широко відчиненими для ризику шахрайства у ваших власних бізнес-додатках.
Enterprise Resource Planning (ERP) і фінансові додатки знаходяться в центрі операцій: вони зберігають ваші найконфіденційніші дані, контролюють фінансові транзакції та визначають, хто може створювати, затверджувати або змінювати критично важливі записи. І все ж безпеці в цих критично важливих бізнес-системах постійно приділяють недостатньо уваги, її неправильно розуміють або некоректно налаштовують.
Це не теоретичні ризики. Association of Certified Fraud Examiners (ACFE) оцінює, що організації щороку втрачають 5% доходу через шахрайство, а понад половина випадків професійного шахрайства пов’язана з відсутніми або обійденими засобами внутрішнього контролю. Шкода не завжди є зловмисною; іноді це натискання неправильної кнопки кимось, хто мав більше доступу, ніж мав би. У будь-якому випадку втрати відчутні.
Усунення цього ризику вимагає надійного Application Access Governance (AAG): фреймворку та IT General Controls (ITGCs), які гарантують, що потрібні люди мають правильний доступ до цих бізнес-додатків у потрібний час, а їхній доступ постійно перевіряється та контролюється.
Нижче наведено десять поширених «підводних каменів» безпеки бізнес-додатків та способи їх уникнути.
Помилка 1. Ви надаєте надмірний доступ користувачам
Одна з найпоширеніших помилок — це надання користувачам бізнес-додатків більшого доступу, ніж їм потрібно. Зазвичай все починається зі спрощеного шляху: комусь з бізнес-сторони потрібно швидко вирішити проблему, ІТ-відділ надає широкий доступ, а роль адміністратора ніколи не видаляється. Помножте це на всю організацію, і ви отримаєте роздуті дозволи, підвищений ризик і систему, яку майже неможливо перевірити.
Рішення — принцип найменших привілеїв. Надавайте користувачам лише мінімальний доступ, необхідний для виконання їхніх щоденних функцій, і нічого більше. Так, для правильного впровадження потрібно більше часу та співпраця з власниками бізнес-додатків, але є помітна ROI. Зменшення доступу знижує ризик шахрайства, ризик розділення обов’язків (SoD) та заощаджує витрати на ліцензування в багатьох ERP-середовищах.
Помилка 2. У вас «тунельний зір» безпеки
Легко зосередитися на тому, чи має користувач доступ до потрібних екранів, і забути перевірити, що насправді дає або скільки коштує цей доступ. У багатьох ERP-системах призначення повноважень щодо безпеки безпосередньо пов’язане з вимогами до ліцензування. Надмірне призначення ролі користувачеві може означати переплату за ліцензію цього користувача. Організації несли шести- та навіть семизначні витрати на ліцензування, оскільки безпека була налаштована без урахування впливу подальшого ліцензування.
Порада — оцінювати кожне рішення або зміну в системі безпеки з двох точок зору: ризику порушення принципу поділу повноважень (SoD) та впливу на ліцензування. Якщо ваша система ERP надає доступ до телеметричних даних, використовуйте їх, щоб порівняти фактичні дії користувачів з тим, що їм доручено, та визначити, де можна зменшити доступ та ліцензії.
Для Microsoft D365 Finance & Supply Chain (F&SC) та D365 Business Central (BC) Delinea Fastpath Telemetry Data reporting показує саме це. Ми також знаємо, що жоден співробітник ніколи не просив видалити доступ зі свого облікового запису. Правильно підібраний доступ за принципом найменших привілеїв також може зменшити витрати на ліцензування.
Помилка 3. Ви не дотримуєтеся процесу application lifecycle management
До безпеки слід ставитися як до коду. Вона має проходити через середовища розробки, тестування та виробництва з належним переглядом та затвердженням на кожному етапі. Натомість, як безпека налаштовується безпосередньо у виробництві або застосовується непослідовно в різних середовищах, тому що комусь потрібно було швидко втрутитися, з обмеженим або взагалі без тестування змін у безпеці.
Результатом є середовища, які не відповідають одне одному, ролі, які існують в одному місці, але не в іншому, та розбіжності в налаштуваннях, які із часом посилюються. Якщо ви не дозволяєте розробнику вносити зміни коду безпосередньо у продакшн, не дозволяйте змінам безпеки обходити ті самі контролі.
Помилка 4. Ви не проводите періодичні перевірки доступу користувачів
Безпека не є статичною, як і ваші користувачі. Люди змінюють відділи, співробітники залишають компанію, а на роботу залучаються тимчасові підрядники. Без планових перевірок доступу користувачів тимчасовий доступ стає постійним, користувачі накопичують ролі, які їм більше не потрібні, а дизайн безпеки, створений під час запуску, поступово руйнується.
Рішення — вибудувати регулярний графік для перевірки прав користувачів (UARs), незалежно від того, чи це щоквартальні, піврічні чи щорічні перевірки. Ці перевірки повинні відповісти на три питання:
- Хто має доступ?
- Який у них доступ?
- Чи такий доступ все ще доречний?
Ці перевірки не повинні проводитися виключно ІТ-фахівцями. Власники та менеджери бізнес-додатків мають бути присутніми, оскільки саме вони можуть визначити, чи потрібен ще дозвіл на доступ. Вони також повинні були схвалити початкові запити на доступ для цих додатків.
Помилка 5. Ваша безпека ізольована в IT домені
ІТ-відділ знає, як налаштувати безпеку. Часто ІТ-відділи не знають, що саме повинен вміти робити певний користувач у сфері бухгалтерського обліку, операцій чи закупівель у своїй повсякденній роботі. Коли проектування безпеки розглядається як суто технічна вправа, власники бізнес-додатків залишаються осторонь, і в результаті виникають ролі, які технічно обґрунтовані, але функціонально неправильні.
Application access governance за своєю суттю є кросфункціональним. Provisioning безпеки та проєктування доступу потребують зворотного зв’язку між ІТ-відділом і бізнесом. Бізнес визначає, який доступ потрібен, а ІТ-відділ його впроваджує та забезпечує. Коли цей зв’язок порушується, результатом є надмірно provisioned користувачі, доступ, який не відображає реальні посадові функції, та система безпеки, якою ніхто повністю не володіє. Будь-що з цього може призвести до слабких місць у контролі та підвищеного ризику інсайдерського шахрайства.
Помилка 6. Ви ставитеся до безпеки як до другорядної думки
Часто питання безпеки відкладають наприкінці впровадження або оновлення ERP, оскільки команди не хочуть уповільнювати функціональне тестування. Така затримка призводить до дорогих коригувальних заходів пізніше: переробки ролей, переробки архітектури безпеки і навіть переналаштування бізнес-процесів.
Починайте роботу з безпеки якомога раніше і вбудовуйте її в кожен sprint cycle. Це має бути обов’язковою частиною плану проєкту впровадження, а не чимось, що «приємно мати». Вигодою є більш узгоджена модель безпеки, менше несподіванок в останню хвилину та команда, яка має досвід у цьому процесі до того, як тиск go-live буде найвищим. Суворі контролі безпеки ваших бізнес-додатків знижують ризик шахрайства, що є позитивним результатом.
Помилка 7. Ви неправильно тестуєте безпеку
Якщо ваша QA-команда запускає тестові скрипти, увійшовши в систему як системний адміністратор, ви не тестуєте безпеку. Ви тестуєте функціональність із пов’язкою на очах. Якщо безпека не перевірена належним чином, проблеми з доступом з’являються лише у продакшні.
Під час тестування програми використовуйте фактичні ролі безпеки, які матимуть користувачі. Тестуйте безпеку поетапно:
- Розробіть security role
- Призначте її тестовому користувачеві окремо, без інших ролей
- Перевірте функціональність, а потім перевірте SoD та вплив ліцензування
- Призначити додаткові ролі та повторно перевірити
Крім того, картина ризиків SoD часто змінюється, коли ролі об’єднуються, і вам потрібно врахувати це, перш ніж це потрапить у виробництво. Перегляд впливу запропонованих змін доступу на SoD перед їх розгортанням у виробництво є ще одним потужним контролем для зниження ризику шахрайства.
Помилка 8. Ви не перевіряєте оновлення ISV на предмет впливу на безпеку
Ваша команда не єдина, хто вносить зміни до моделі безпеки вашої системи. ERP-вендори та сторонні ISV випускають оновлення, які додають нові функції, змінюють існуючі дозволи та вводять нові об’єкти безпеки. Я бачив ISV-компоненти, для функціонування яких потрібен підвищений або навіть адміністративний доступ. Ніхто не ставив це під сумнів, оскільки передбачалося, що постачальник відповідально ставиться до безпеки.
Насправді зазвичай цим ISV не потрібен був підвищений або адміністративний доступ для внесення змін до коду, але було простіше запустити систему з надто широкими правами. Це також створює новий рівень ризику для середовищ ваших бізнес-додатків.
Не робіть припущень. Будь-яке оновлення, незалежно від того, чи від вашого постачальника ERP, чи від сторонньої інтеграції, слід оцінювати на предмет впливу на безпеку. Це включає ризик SoD та зміни в ліцензуванні. Принцип «Довіряй, але перевіряй» застосовується тут так само, як і будь-де.
Помилка 9. Ваші вбудовані функції безпеки використовуються недостатньо
Більшість корпоративних бізнес-додатків пропонують можливості безпеки, що виходять далеко за рамки базових ролей та дозволів. Існують засоби керування безпекою на рівні даних, дозволи на сутності та структури на рівні таблиць, щоб надати адміністраторам детальніший контроль над тим, хто може що бачити та робити. Ці функції часто використовуються недостатньо, або тому, що організації не знають про їхнє існування, або тому, що їхній партнер з впровадження не повідомив про них під час налаштування.
Перш ніж вдаватися до індивідуального обхідного рішення або погоджуватися на непотрібне викриття доступу, перегляньте, що вже пропонує ваша ERP-система. Часто існують вбудовані інструменти, які можуть вирішити проблему без додаткових витрат чи складнощів.
Однак це не означає, що вам слід довіряти нативним ролям, що постачаються з бізнес-додатками. Ці ролі не були розроблені з урахуванням розподілу обов’язків. Більшість компаній беруть нативні ролі та клонують їх, модифікуючи відповідно до своїх потреб контролю, включаючи SoD.
Помилка 10. Ви потрапляєте в «пончик безпеки»
Уявіть собі пончик. Уявіть зовнішнє кільце як периметр кібербезпеки: брандмауери, endpoint detection, identity threat protection. Організації інвестують значні кошти в ці зони, і це справедливо, щоб зменшити ці зовнішні загрози. Але діра посередині? Це ваші бізнес-додатки та внутрішні ризики шахрайства. Занадто часто ця діра в сліпій зоні безпеки залишається на розсуд бізнес-підрозділів, відірваною від ширшої стратегії безпеки, якою володіє CISO.
CISO та CIO, які керують корпоративною безпекою, також повинні відповідати за безпеку бізнес-додатків.
Внутрішня загроза така ж реальна, як і зовнішня
Жоден брандмауер не зупинить працівника, який випадково ініціює замовлення на купівлю на кількість, вдесятеро більшу за заплановану, або того, хто навмисно використовує надмірно наданий доступ у складний період. Справжня безпека підприємства означає закриття діри в бублику, а не просто зміцнення периметра.
Спільна риса? Відсутність послідовності
Ймовірно, жодна з цих помилок не стане великою несподіванкою, але я бачу їх у різних галузях, різних бізнес-додатках та організаціях будь-якого розміру. Спільною рисою є відсутність послідовного підходу до application access governance та внутрішніх контролів, необхідних для зменшення ризиків шахрайства.
Гарна новина полягає в тому, що жодне з цих виправлень не вимагає складних інструментів чи необмеженого бюджету. Вони вимагають дисципліни процесу, кросфункціональної комунікації та ставлення до безпеки як до першочергового питання, а не до останнього пункту контрольного списку. Рішення Delinea Fastpath додають прості у використанні application access governance controls, які забезпечують прозорість та автоматизацію для оптимізації внутрішніх контролів із метою зменшення операційних ризиків. Вони також виявляють ризикові інсайти, що допомагають приймати обґрунтовані рішення щодо доступу.
