Шеннон Маквільямс, керівник глобальної дистрибуції в Orca Security — серія інтерв’ю

Шеннон Маквільямс — керівник глобальної дистрибуції в Orca Security, де його робота охоплює партнерську екосистему компанії та інструменти для її підтримки. Раніше він заснував компанію з розробки програмного забезпечення, тож має досвід перетворення бізнес-потреб на застосунки. Нещодавно він скористався інструментами розробки на основі ШІ, щоб створити ранню версію Partner Success Platform від Orca, і разом із командою безпеки перетворив прототип, створений за вихідні, на систему, готову до впровадження у виробниче середовище.

Orca Security пропонує платформу хмарної безпеки, яка допомагає організаціям виявляти ресурси, визначати ризики, встановлювати їхню пріоритетність і захищати хмарні середовища. Її функції охоплюють, зокрема, вразливості, неправильні налаштування, ідентичності та дозволи, конфіденційні дані й безпеку ШІ. У цьому інтерв’ю Маквільямс розповідає, як ШІ дає змогу бізнес-користувачам створювати програмне забезпечення, чому навіть функціональні застосунки потребують незалежної перевірки безпеки та як безперервне виявлення, принцип мінімальних привілеїв і людський контроль допомагають підприємствам керувати цією новою моделлю розробки.

Ви прийшли в Orca Security на посаду керівника глобальної дистрибуції, а за кілька місяців самостійно створили нову партнерську платформу за допомогою ШІ. Яку проблему ви спочатку намагалися розв’язати і коли проєкт із експерименту перетворився на щось, що Orca справді могла запустити у виробниче середовище?

Коли я прийшов в Orca, одним із завдань, які мені доручили, було оцінити загальний досвід партнерів. Ми користувалися сторонньою платформою, але я побачив можливість створити для партнерів щось сучасніше й зручніше. Я мав певний досвід розробки застосунків, але сам розробником не був. На початку того літа я працював над споживчими застосунками на сторонній платформі для генерування застосунків, тож вирішив поекспериментувати й подивитися, що зможу створити сам за допомогою ШІ.

За одні вихідні мені вдалося створити базову першу версію того, що згодом стало нашою Partner Success Platform. Її функціональність перевершувала можливості традиційних партнерських порталів, які я бачив, і включала функції на основі ШІ, як-от підбір ідеальних клієнтів і рекомендації щодо роботи з угодами. Ми додали до платформи ще багато застосунків, зокрема відстеження сертифікацій, вікторини, створені за допомогою ШІ, та ігрові елементи в усьому процесі сертифікації партнерів, а потім почали синхронізувати дані з нашою платформою Salesforce. Переломним моментом стало те, що наш генеральний директор побачив початкову версію і розгледів її потенціал. Тоді ж ми перейшли від експериментів до питання, що насправді потрібно, аби зробити щось подібне безпечним і готовим до виробничого використання. До роботи долучилася наша команда безпеки, а я почав тісно співпрацювати з Дуді Перецем, щоб захистити середовище; зрештою незалежну перевірку цієї роботи провела зовнішня компанія.

Раніше ви заснували компанію з розробки програмного забезпечення, тож знаєте, як традиційно створювали застосунки. Чим розробка програмного забезпечення за допомогою ШІ та природної мови відрізнялася від керування роботою розробників і де ваші власні знання предметної галузі були найважливішими?

Найбільша різниця — швидкість. У традиційній розробці програмного забезпечення зазвичай є кілька етапів: від задуму до перетворення його на технічні вимоги, розробки й подальшого вдосконалення результату. З ШІ я міг описати, чого хочу, одразу побачити, як задум набуває форми, і далі його доопрацьовувати. Ітерації займають хвилини замість днів зустрічей із розробниками, на яких визначають бажаний інтерфейс користувача та всі зв’язки з базою даних, потрібні для реалізації функцій. Для розробки за допомогою ШІ достатньо запиту з 2 речень, а не 2 днів зустрічей.

Але це не усуває потреби в експертних знаннях — змінюється лише те, де вони потрібні. ШІ може суттєво знизити технічний поріг входження в розробку застосунків, але людина, яка керує цим процесом, усе одно має розуміти, яку проблему намагається розв’язати, яким має бути зручний досвід користування та чого застосунок зрештою повинен досягти для бізнесу. Найбільше мене здивувало, як швидко можна перейти від ідеї до чогось функціонального. Завдання на кшталт аналізу даних, які раніше могли тривати тижнями, тепер потенційно можна виконати за день.

В Orca розповідали, що першу робочу версію партнерської платформи ви створили лише за одні вихідні. Що ШІ може значно пришвидшити, а які етапи створення готового до виробничого використання застосунку виявилися складнішими, ніж здавалося спочатку?

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

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

Власні засоби безпеки платформи для розробки за допомогою ШІ показали, що застосунок захищений, однак подальша перевірка Orca виявила проблеми з дозволами та доступом до даних. Чого цей досвід навчив вас щодо того, наскільки бізнес-користувачам варто довіряти запевненням платформ для розробки за допомогою ШІ про безпеку?

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

Це особливо важливо, адже багато людей, які тепер можуть створювати застосунки за допомогою ШІ, не є фахівцями з безпеки. Вони можуть не знати, які запитання поставити, які дозволи є надто широкими або які налаштування можуть відкрити доступ до даних. Запевнення платформи розробки, що застосунок захищений, не може бути останнім етапом процесу. Перш ніж опублікувати застосунок або під’єднати його до конфіденційних корпоративних систем, потрібно провести всебічну перевірку безпеки, яка виходить за межі простого підтвердження того, що застосунок пройшов власні перевірки платформи.

Коли команда безпеки виявляла вразливості, ви часто могли передати ці результати назад у середовище розробки на основі ШІ й за лічені хвилини згенерувати виправлення. Чи може ШІ докорінно змінити усунення проблем безпеки — перетворити його з тривалого циклу розробки на безперервну взаємодію між розробниками та командами безпеки?

Це одна з найцікавіших можливостей. Коли Дуді та команда безпеки виявляли проблеми, я міг узяти їхні зауваження, безпосередньо передати їх у середовище розробки на основі ШІ та дуже швидко згенерувати виправлення. Завдяки цьому взаємодія між людиною, яка створює застосунок, і командою, відповідальною за його захист, може стати значно тіснішою та оперативнішою.

Раніше розробка та випуск програмного забезпечення могли тривати значно довше. Тепер зміни можна вносити й публікувати щодня. Безпека має працювати в такому самому темпі. Можливість полягає в тому, щоб зробити безперервну оцінку безпеки частиною процесу розробки: виявляти проблему, повідомляти про неї розробника, усувати її та повторно оцінювати застосунок значно швидше.

Однак швидше усунення проблем не означає, що можна знизити вимоги до перевірки. ШІ може швидко згенерувати виправлення, але командам безпеки все одно потрібен спосіб перевірити, чи справді воно усунуло ризик і чи не створило нового.

Створена в результаті Partner Success Platform охоплює ШІ-асистентів, аналітику щодо воронки продажів, створення кампаній і наставництво з укладання угод. Як ви визначали, які завдання має виконувати безпосередньо ШІ, а які рішення слід залишити за партнером або продавцем?

Для мене метою не було усунути людину з партнерського процесу чи процесу продажу. Я хотів за допомогою ШІ допомогти людям працювати швидше й ефективніше використовувати вже доступну їм інформацію. Наставництво з укладання угод — гарний приклад: ШІ може допомогти визначити, як просунути можливість, що вже певний час залишається у воронці продажів, а також надати додатковий контекст або запропонувати наступний крок.

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

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

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

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

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

Основна проблема полягає в тому, що темп змінився. Традиційно програмне забезпечення створювали й випускали з часом, дотримуючись відносно усталених процесів. Завдяки інструментам розробки на основі ШІ хтось може створювати й публікувати щось нове фактично щодня. У таких умовах процесів безпеки й управління, побудованих на періодичних контрольних точках, буде недостатньо.

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

Ви порівнювали появу застосунків, створених за допомогою ШІ, з іще складнішою формою «тіньового ІТ». Чим це нове покоління тіньового програмного забезпечення може бути складнішим і як організаціям виявляти застосунки, про існування яких можуть не знати навіть фахівці з безпеки чи ІТ-команди?

Раніше тіньове ІТ часто означало, що працівники починали користуватися SaaS-застосунком, який ІТ-відділ не схвалив. Тепер усе інакше: працівники можуть самі створювати застосунки, причому неймовірно швидко. Хтось може створити застосунок через особистий обліковий запис, інтегрувати його зі сторонніми системами й навіть під’єднати до корпоративних даних, перш ніж служба безпеки дізнається про його існування.

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

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

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

Ми рухаємося до світу, де поняття «розробник програмного забезпечення» охоплюватиме значно ширше коло людей. ШІ дає змогу тим, хто розуміє бізнес-проблему, але не є традиційним розробником, неймовірно швидко перетворити ідею на робочий застосунок. Я переконалася в цьому на власному досвіді.

Не думаю, що через це професійні розробники чи команди з безпеки стають менш важливими. Просто їхня експертиза потрібна в інших сферах. Бізнес-користувачі дедалі частіше можуть самостійно створювати рішення, тоді як розробники зосереджуються на складніших технічних завданнях, а команди з безпеки мають забезпечити видимість і створити запобіжники, які дадуть змогу новому поколінню розробників безпечно впроваджувати інновації. Підтримка й обслуговування застосунків також набувають нового значення. «Розробники» не завжди є найкращими «супроводжувачами». Вони мають бачення та розуміють потреби бізнесу, але довгострокова підтримка застосунку й надалі найкраще підходить ІТ-відділам і підрозділам, що відповідають за застосунки. Для бізнес-керівників це відкриває величезні можливості, але водночас створює нову відповідальність. Якщо ваші команди можуть створювати програмне забезпечення, потрібно враховувати пов’язані з ним ризики як частину бізнесу, а не вважати їх проблемою лише інженерного відділу.

Дякую за чудове інтерв’ю! Читачам, які хочуть дізнатися більше про безпеку хмарних середовищ, застосунки, створені за допомогою ШІ, та захист корпоративних середовищ, варто відвідати Orca Security.