Зменшення ризиків третіх сторін вимагає спільного, ретельного підходу

Зменшення ризиків третіх сторін вимагає спільного, ретельного підходу

Зменшення ризиків третіх сторін вимагає спільного, ретельного підходу PlatoBlockchain Data Intelligence. Вертикальний пошук. Ai.

КОМЕНТАР

Зменшення ризику третіх сторін може здатися складним, якщо взяти до уваги низку законодавчих актів у поєднанні з дедалі прогресивнішою тактикою кіберзлочинців. Однак більшість організацій мають більше свободи волі та гнучкості, ніж вони думають. Управління ризиками третіх сторін може базуватися на існуючих методах управління ризиками та засобах безпеки, які наразі впроваджені в компанії. Що заспокоює в цій моделі, так це те, що вона означає, що організаціям не потрібно повністю відмовлятися від існуючого захисту, щоб успішно пом’якшити ризики третіх сторін — і це заохочує культуру поступового, постійного вдосконалення. 

Ризик третіх сторін є унікальним викликом для організацій. На перший погляд третя сторона може здаватися заслуговує довіри. Але без повної прозорості внутрішньої роботи цього стороннього постачальника, як організація може гарантувати безпеку довірених їй даних?

Часто організації применшують це актуальне питання через давні відносини, які вони мають зі своїми сторонніми постачальниками. Оскільки вони працювали зі сторонніми постачальниками протягом 15 років, вони не бачать причин ставить під загрозу свої відносини, просячи «заглянути під капот». Однак така думка небезпечна — кіберінцидент може статися тоді або там, де його найменше очікують.

Змінний пейзаж

У разі порушення даних організація може бути оштрафована не тільки як організація, але й особисті наслідки. Минулого року, FDIC посилила свої вказівки щодо ризику третіх сторін, готуючи основу для того, щоб інші галузі наслідували цей приклад. З появою нових технологій, таких як штучний інтелект, наслідки неправильного керування даними третьою стороною можуть бути жахливими. Поступові нормативні акти відображатимуть ці серйозні наслідки, запроваджуючи суворі покарання для тих, хто не розробив жорсткого контролю.

Окрім нових правил, поява четвертих і навіть п’ятих постачальників має стимулювати організації до захисту своїх зовнішніх даних. Програмне забезпечення — це не така проста внутрішня практика, як це було 10 років тому — сьогодні дані проходять через багато рук, і з кожною доданою ланкою в ланцюжку даних загрози безпеці зростають, а нагляд ускладнюється. Наприклад, проведення належної перевірки стороннього постачальника мало користі, якщо перевірена третя сторона передає приватні дані клієнта недбалій четвертій стороні, а організація не знає про це.

П’ять простих стандартних кроків

З правильною дорожньою картою, організації може успішно зменшити ризики третіх сторін. Більше того, не завжди потрібні дорогі та проривні технологічні інвестиції. Почнемо з того, що організації потребують під час проведення належної перевірки – це розумний план, здатний персонал, готовий погодитися, і посилений зв’язок між ІТ-командами, відділами безпеки та бізнес-командами.

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

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

Сортування постачальників за їх критичністю може пролити світло на надмірну залежність організацій від своїх сторонніх постачальників. Ці організації повинні запитати себе: якщо ці відносини раптово припиниться, чи є у нас запасний план? Як би ми замінили цю функцію, продовжуючи безперебійно виконувати повсякденні операції?

Третій крок — це розробка плану управління. Щоб ефективно виконувати належну перевірку та керувати ризиками, має існувати взаємодія між трьома основними підрозділами організації: команда безпеки висвітлює прогалини в програмі безпеки постачальника, юридична команда визначає юридичний ризик, а бізнес-команда прогнозує негативні каскади. вплив на операції, якщо дані або операції скомпрометовані. Ключем до створення надійного управління є адаптація плану відповідно до унікальних потреб організації. Це особливо стосується організацій у менш регульованих галузях.

Етап управління включає складання контрактних зобов’язань. Наприклад, часто в хмарних обчисленнях бізнес-лідери помилково поспішають підписувати контракт, не розуміючи, що певні заходи безпеки можуть або не можуть бути включені в базовий пакет. Договірні зобов’язання часто залежать від галузі, але також слід розробити стандартизоване положення про безпеку. Наприклад, якщо ми оцінюємо компанію-постачальника, ми можемо приділяти менше уваги процесу життєвого циклу розробки програмного забезпечення (SDLC) постачальника, а більше — його показникам стійкості. Однак, якщо ми оцінюємо компанію, що займається програмним забезпеченням, ми захочемо зосередитися на процесах SDLC постачальника, наприклад, як перевіряється код і як виглядають запобіжні заходи для запуску у виробництво. 

Нарешті, організації повинні розробити стратегію виходу. Як організація чітко відокремлюється від третьої сторони, забезпечуючи при цьому очищення даних своїх клієнтів? Були випадки, коли компанія розривала зв’язки з постачальником лише для того, щоб через роки отримати дзвінок із повідомленням про те, що їхній колишній партнер зазнав компрометації даних і що дані їхніх клієнтів були розкриті — незважаючи на припущення, що ці дані було стерто. Мораль історії: не припускайте. Крім випадкового порушення даних, існує ймовірність того, що сторонні постачальники використовуватимуть дані колишнього партнера для внутрішнього розвитку, наприклад, використання цих даних для створення моделей машинного навчання. Організації повинні запобігти цьому, вказавши чіткі, конкретні та юридично зобов’язуючі умови, як постачальники видалятимуть дані у разі припинення партнерства та які наслідки будуть, якщо вони цього не зроблять.

Створіть культуру спільної відповідальності та постійного вдосконалення 

Застосування командного підходу до проведення належної обачності означає, що керівник відділу інформаційної безпеки (CISO) не повинен повністю брати на себе відповідальність за зниження ризиків стороннього постачальника. The Звинувачення SEC проти SolarWinds створити занепокоєний прецедент — CISO може потерпіти падіння, навіть якщо проблема виникає через дисфункцію всієї організації. Якщо ІТ-підрозділи та бізнес-команди підтримують CISO у перевірці сторонніх постачальників, це закладає основу для майбутньої співпраці між командами, підвищує зацікавленість організації та дає кращі результати, коли йдеться про безпеку.

Часова мітка:

Більше від Темне читання