Девід Міттон, генеральний директор Arcjet – Серія інтерв’ю

Девід Міттон, засновник і генеральний директор Arcjet, очолює розробницьку компанію з питань безпеки, яка допомагає командам впроваджувати потужні засоби захисту, такі як виявлення ботів, обмеження швидкості, перевірка електронної пошти, мінімізація атак і редагування даних, безпосередньо в коді програми, очолюючи компанію з червня 2023 року. Він також був співзасновником Console, популярного інформаційного бюлетеня і подкасту для розробників, обіймав посади радників, таких як експерт у Seedcamp, і раніше керував інженерною командою StackPath після придбання його компанії моніторингу хмарних технологій, зберігаючи сильний інтерес до сталої комп’ютерної техніки та активної діяльності на технічних темах.

Arcjet побудований навколо філософії “безпека через код”, яка дозволяє розробникам захищати програми за допомогою простих інтеграцій SDK, розміщуючи логіку безпеки поряд з бізнес-логікою для прийняття низьколатентних, контекстно-залежних рішень і ліквідації необхідності окремої інфраструктури; платформа підтримує засоби захисту, такі як блокування ботів, обмеження швидкості та фільтрація чутливих даних, і продовжує розвиватися з функціями, такими як локальна модель безпеки штучного інтелекту та розширена підтримка фреймворків, відображаючи свою місію зробити безпеку в коді стандартом для сучасних програм. (fly.io)

Ви заснували Server Density в час, коли виконання інфраструктури у великому масштабі було значно менше стандартизовано, ніж сьогодні, і в кінцевому підсумку виросли і продали компанію. Оглянувшись назад, які були найбільш важливі уроки, які ви вивчили про будівництво для розробників і експлуатацію систем виробництва, і як цей досвід сформував ваше мислення про програмне забезпечення сьогодні?

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

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

Продукт не є інтерфейсом користувача. Продукт – це поведінка часу виконання, крайні випадки, приклади та довідкові документи, яким розробники можуть довіряти.

Виходячи з цього досвіду, що спонукало вас створити Arcjet, і чому ви відчували, що наступний великий зсув у сфері безпеки програм потрібно було здійснити всередині коду самої програми, а не на рівні мережі чи інфраструктури?

Периметрова безпека оптимізує неправильну річ. Розробники будують і відправляють у виробництво код, а не панелі управління – і агенти штучного інтелекту не “клікнуть” у панелі безпеки, щоб захистити програму.

Якщо ваша охорона не може бути виражена у вигляді коду, перевірена у запиті на отримання, протестована у CI та розгорнута поряд з програмою, це не “безпека, орієнтована на розробника”.

Arcjet існує, оскільки безпека належить до шару програми: керований версіями, тестований, спостережуваний і близький до бізнес-логіки, де фактично живе намір.

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

Усередині обробника запитів у вас є ідентифікатор, стан сесії, історія покупок, вік облікового запису, прапори функцій, істина бази даних. Ви можете прийняти рішення, таке як: “Це виглядає дивно, але це лояльний клієнт – підвищте верифікацію замість блокування.” Проксі-сервер мережі не може цього зробити, оскільки він не знає, що таке “клієнт”.

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

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

Продуктивність штучного інтелекту допомагає атакувальникам також! Великий зсув полягає у об’ємі та швидкості ітерації: більше спроб входу, більше автоматизованого спаму при реєстрації, більше скрапінгу ботів, більше зондування API та швидша “зброя” нових уразливостей.

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

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

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

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

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

Ці дві категорії мають спільність, де кожен зловживальний запит має прямий кошт.

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

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

Створення програмного забезпечення безпеки супроводжується зовсім іншими компромісами, ніж спостереження чи моніторинг. Що вас найбільше здивувало про розробку продукту безпеки порівняно з вашим попереднім досвідом з інструментами інфраструктури?

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

Створення продукту безпеки означає керування компанією безпеки. Ми використовуємо рамки, такі як SOC 2, мінімізуємо наші залежності третіх сторін та ставимося до ноутбуків розробників та доступу до інструментів як до активів виробництва. Це означає багато моніторингу та швидкої реакції на потенційні проблеми.

Як програми все частіше залежать від агентів штучного інтелекту, які діють від імені користувачів, як розробники повинні переосмислити ідеї ідентичності, наміру та довіри на рівні програми?

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

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

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

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

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

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

Якщо безпека, впроваджена у код, стане стандартом, команди будуть тестувати зловживання так само, як вони тестують правильність: безпека уніт-тестів, симуляції атак та перевірки ризикованих кінцевих точок у CI.

Більший зсув полягає у тому, що агенти штучного інтелекту для кодування будуть реалізовувати безпеку у вигляді коду, а не конфігурації панелі управління. Агенти можуть надійно пропонувати, переглядати та затверджувати засоби захисту лише тоді, коли контролюються у репозиторії: політики, правила, тести та інструментування. Якщо “шар безпеки” є веб-інтерфейсом, агент не може протестувати зміни для безпечної доставки.

Це справжня причина, чому “безпека у коді” перемагає – вона відповідає тому, як сучасне програмне забезпечення (та розвиток штучного інтелекту) фактично будується.

Дякуємо за велике інтерв’ю, читачам, які бажають дізнатися більше, слід відвідати Arcjet.