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

Шеннон Макуильямс — руководитель глобальной дистрибуции в Orca Security. В его обязанности входит работа с партнерской экосистемой компании и инструментами, которые ее поддерживают. Ранее он основал компанию по разработке программного обеспечения и приобрел опыт преобразования бизнес-задач в приложения. Недавно он использовал инструменты разработки на базе ИИ, чтобы создать раннюю версию платформы Partner Success Platform компании Orca, и вместе с командой безопасности работал над тем, чтобы превратить прототип, созданный за выходные, в готовую к эксплуатации систему.

Orca Security предлагает платформу облачной безопасности, которая помогает организациям обнаруживать активы, выявлять риски и расставлять приоритеты, а также защищать облачные среды. Ее возможности охватывают такие области, как уязвимости, неправильные настройки, идентификация и разрешения, конфиденциальные данные и безопасность ИИ. В этом интервью Макуильямс рассказывает о том, как ИИ помогает бизнес-пользователям создавать программное обеспечение, почему работающие приложения все равно нуждаются в независимой проверке безопасности и как непрерывное обнаружение активов, принцип минимальных привилегий и контроль со стороны человека помогают компаниям управлять этой новой моделью разработки.

Вы пришли в Orca Security на должность руководителя глобальной дистрибуции и уже через несколько месяцев самостоятельно создали новую партнерскую платформу с помощью ИИ. Какую задачу вы изначально хотели решить и в какой момент проект перестал быть экспериментом и превратился в нечто, что Orca действительно могла запустить в эксплуатацию?

Когда я пришел в Orca, меня попросили, помимо прочего, оценить общий опыт взаимодействия с партнерами. Мы пользовались сторонней платформой, но я увидел возможность создать для партнеров более современное и удобное решение. У меня был некоторый опыт разработки приложений, хотя сам я разработчиком не был. Ранее тем летом я работал над потребительскими приложениями на сторонней платформе для генерации приложений, поэтому решил поэкспериментировать и посмотреть, что смогу создать самостоятельно с помощью ИИ.

За выходные мне удалось создать первую базовую версию того, что впоследствии стало нашей платформой Partner Success Platform. Ее функциональность выходила за рамки возможностей традиционных партнерских порталов: в нее вошли, в частности, функции на базе ИИ для подбора потенциальных клиентов и сопровождения сделок. Мы добавили на платформу множество других приложений — например, отслеживание сертификаций и тесты, созданные с помощью ИИ, — а также превратили весь процесс сертификации для партнеров в игру. Затем мы начали синхронизировать данные с нашей платформой Salesforce. Переломный момент наступил, когда генеральный директор увидел первую версию и оценил ее потенциал. Тогда же мы перешли от экспериментов к обсуждению того, что потребуется, чтобы сделать такое решение безопасным и готовым к эксплуатации. К работе подключилась наша команда безопасности, и я начал тесно сотрудничать с Дуди Перецем, чтобы защитить среду; в итоге независимую проверку этой работы провела внешняя компания.

Ранее вы основали компанию по разработке программного обеспечения, поэтому знаете, как приложения создавались традиционными методами. Чем разработка ПО с помощью ИИ, понимающего естественный язык, отличалась от управления командой разработчиков и в каких областях ваши знания предметной области по-прежнему были особенно важны?

Главное отличие — скорость. При традиционной разработке программного обеспечения между появлением идеи, ее переводом в технические требования, работой разработчиков и последующей доработкой результата обычно проходит несколько этапов. С ИИ я мог описать, что мне нужно, сразу увидеть, как это обретает форму, и продолжать дорабатывать результат. На итерации уходят минуты, а не дни встреч с разработчиками, на которых нужно определить желаемый интерфейс и все взаимосвязи с базой данных, необходимые для реализации функций. При разработке с помощью ИИ для этого достаточно запроса из двух предложений, а не двух дней встреч.

Но потребность в экспертных знаниях никуда не исчезает — меняется лишь то, где они нужны. ИИ может значительно снизить технический порог для создания приложения, но человек, который им руководит, по-прежнему должен понимать, какую задачу пытается решить, каким должен быть удобный пользовательский опыт и чего приложение в конечном счете должно достичь для бизнеса. Больше всего меня удивило, как быстро можно перейти от идеи к работающему решению. Задачи, например анализ данных, на которые раньше могли уйти недели, теперь потенциально можно выполнить за день.

В Orca рассказывали, что первую работающую версию партнерской платформы вы создали всего за одни выходные. Что ИИ позволил значительно ускорить, а какие этапы создания готового к эксплуатации приложения оказались сложнее, чем казалось поначалу?

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

ИИ не избавил нас от всего, что необходимо, чтобы безопасно запустить приложение в эксплуатацию. Когда мы решили, что из этого может получиться полноценное решение, нашей команде безопасности нужно было оценить среду, устранить проблемы безопасности и убедиться, что приложение защищено должным образом. В итоге мы также привлекли внешнюю компанию, чтобы получить дополнительную независимую оценку. Итак, ИИ невероятно ускорил разработку, но «оно работает» и «оно готово к безопасной эксплуатации в крупной компании» — это по-прежнему совершенно разные уровни готовности.

Собственные средства безопасности платформы для разработки ИИ показывали, что приложение защищено, однако последующая проверка со стороны Orca выявила проблемы с разрешениями и доступом к данным. Как этот опыт повлиял на ваше представление о том, насколько бизнес-пользователи должны доверять заверениям платформ для разработки ИИ в области безопасности?

Наверное, это был один из главных уроков, которые я извлёк из этого опыта. У платформы были собственные средства сканирования безопасности, которые помогали оценивать ситуацию по мере разработки. Но проверка нашей командой по безопасности показала мне, насколько важно добавить ещё один уровень контроля, особенно в таких областях, как разрешения и доступ к данным. Этот опыт подтвердил, что встроенные средства безопасности — важная часть процесса разработки, но лучше всего они работают в сочетании с более глубоким пониманием ситуации и опытом, которыми располагает специализированная команда по безопасности.

Это особенно важно, поскольку многие из тех, кто теперь может создавать приложения с помощью ИИ, не являются специалистами по безопасности. Они могут не знать, какие вопросы задавать, какие разрешения слишком широки и какие настройки могут открыть доступ к данным. Одних заверений платформы разработки в том, что приложение защищено, недостаточно. Прежде чем публиковать приложение или подключать его к критически важным корпоративным системам, необходимо провести всестороннюю проверку безопасности, выходящую за рамки простой оценки того, проходит ли приложение встроенные проверки платформы.

Когда команда по безопасности выявляла уязвимости, вам часто удавалось передать результаты этой проверки обратно в среду разработки на базе ИИ и сгенерировать исправления за считаные минуты. Может ли ИИ коренным образом изменить устранение уязвимостей — превратить его из длительного цикла разработки в непрерывный диалог между разработчиками и командами по безопасности?

Это одна из самых многообещающих возможностей. Когда Дуди и команда по безопасности выявляли проблемы, я мог взять их замечания, напрямую передать их в среду разработки на базе ИИ и очень быстро получить сгенерированные исправления. Это открывает возможность наладить гораздо более тесную обратную связь между человеком, который создаёт приложение, и командой, отвечающей за его защиту.

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

Но быстрое устранение проблемы не означает, что можно снизить требования к проверке. ИИ способен быстро сгенерировать исправление, однако командам по безопасности всё равно нужен способ убедиться, что оно действительно устранило риск и не создало новый.

Партнёрская платформа Partner Success Platform объединяет ИИ-ассистентов, аналитику воронки продаж, создание кампаний и помощь в работе со сделками. Как вы определяли, какие задачи должен выполнять непосредственно ИИ, а какие решения должны оставаться за партнёром или продавцом?

Для меня цель состояла не в том, чтобы исключить человека из взаимодействия с партнёрами или из процесса продаж. ИИ должен помогать людям работать быстрее и эффективнее использовать уже доступную им информацию. Хороший пример — помощь в работе со сделками: ИИ может подсказать, как продвинуть возможность, которая долго остаётся в воронке продаж, а также предоставить дополнительный контекст или предложить следующий шаг.

На мой взгляд, важное различие заключается в том, что ИИ может быстро извлекать информацию из разрозненных систем, анализировать её релевантность и представлять её в форме, которая позволяет пользователю действовать. Платформа должна повышать эффективность партнёра или продавца, а человек должен сохранять ответственность за решения, требующие деловой оценки. Цель — сократить благодаря использованию платформы время от выявления сделки до её закрытия.

ИИ позволяет сотрудникам отделов продаж, маркетинга, финансов и других подразделений создавать собственные приложения без участия инженерной команды. Какие минимальные меры контроля безопасности и управления должны быть внедрены, прежде чем таким приложениям разрешат подключаться к данным клиентов, внутренним системам или облачной инфраструктуре?

Первое необходимое условие — прозрачность. Политика организации должна поощрять подобные эксперименты и инновации, но невозможно защитить приложение, о существовании которого не знаешь. Поэтому поощрение инноваций скорее побудит сотрудников открыто рассказывать о своих проектах, а не держать их в тени. Затем организациям необходимо выяснить, какие учётные записи и разрешения есть у приложения, к каким данным оно может обращаться, с какими сторонними системами взаимодействует и действительно ли ему нужны все эти привилегии. Нужно создавать условия для развития инноваций, одновременно обеспечивая поддержку новаторов и соблюдение требований безопасности.

Особенно важен принцип минимальных привилегий. Один из рисков, с которым мы сталкиваемся, — приложения получают более широкий доступ, чем им действительно необходим. Кроме того, проверка безопасности не должна быть разовым мероприятием перед запуском. Если приложения могут непрерывно меняться, организациям необходимо так же непрерывно переоценивать их безопасность.

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

Главная проблема в том, что изменился темп работы. Раньше программное обеспечение создавали и выпускали по относительно устоявшимся процессам. С инструментами разработки на основе ИИ кто-то потенциально может каждый день создавать и публиковать что-то новое. В таких условиях процессов безопасности и управления, основанных на периодических проверках, будет недостаточно.

Нам нужно перейти к непрерывной защите, которая сможет поспевать за циклом разработки. Это означает, что необходимо выявлять создаваемые приложения, понимать, как они настроены и с чем связаны, проверять их по мере изменений и давать разработчикам практические рекомендации, которые они смогут быстро учесть. Нельзя просто запретить сотрудникам пользоваться этими инструментами: потенциал роста производительности слишком велик. Задача — установить правила и ограничения, которые позволят безопасно внедрять инновации.

Вы сравнивали распространение приложений, созданных с помощью ИИ, с еще более сложной разновидностью «теневых ИТ». Почему новое поколение теневого программного обеспечения может создавать больше проблем и как организациям обнаруживать приложения, о существовании которых службы безопасности или ИТ могут даже не знать?

Раньше под теневыми ИТ чаще всего подразумевалось, что сотрудники начинали пользоваться SaaS-приложением, не одобренным ИТ-службой. Теперь же сотрудники могут сами создавать приложения, причем невероятно быстро. Кто-то может разработать приложение в личной учетной записи, интегрировать его со сторонними системами и даже подключить к корпоративным данным — прежде чем служба безопасности узнает о его существовании.

Именно поэтому эта проблема особенно сложна: создавать приложения стало так просто, что их количество и скорость изменений могут быстро опередить традиционные механизмы управления. Перед руководителями служб информационной безопасности (CISO) встает тот же главный вопрос: как защитить то, о чем вы, возможно, даже не знаете, — что именно создано и как оно настроено?

Поэтому обнаружение приложений должно стать неотъемлемой частью стратегии безопасности. Отличный способ добиться этого — поддерживать новаторов и поощрять их к экспериментам, одновременно требуя регистрировать свои проекты. Организациям необходимо видеть не только код, но и приложения, работающие в их среде, связанные с ними учетные записи и разрешения, данные, к которым они обращаются, а также внешние системы, с которыми они взаимодействуют.

Если заглянуть на несколько лет вперед, считаете ли вы, что большинство офисных специалистов благодаря ИИ в той или иной мере станут разработчиками программного обеспечения? Если да, как это изменит роли профессиональных разработчиков, команд безопасности и руководителей бизнеса в компаниях?

Мы движемся к миру, в котором понятие «разработчик программного обеспечения» будет охватывать гораздо больше людей. ИИ позволяет тем, кто понимает бизнес-задачу, но не является разработчиком в традиционном смысле, невероятно быстро превращать идею в работающее приложение. Я сам убедился в этом на практике.

Не думаю, что из-за этого профессиональные разработчики или команды безопасности станут менее важными. Просто их экспертиза будет нужнее в других областях. Бизнес-пользователи все чаще смогут самостоятельно создавать решения, а разработчики — сосредоточиться на более сложных технических задачах. Командам безопасности предстоит обеспечить видимость и установить правила и ограничения, которые позволят новому поколению разработчиков безопасно внедрять инновации. Поддержка и обслуживание приложений тоже приобретают новое значение. «Создатели» не всегда лучше всех подходят для «сопровождения» приложений. Они предлагают идею и понимают потребности бизнеса, но долгосрочная поддержка приложения по-прежнему лучше всего подходит ИТ-службам и подразделениям, отвечающим за приложения. Для руководителей бизнеса это открывает огромные возможности, но влечет за собой и новую ответственность. Если ваши команды могут создавать программное обеспечение, необходимо учитывать связанные с ним риски как часть бизнес-рисков, а не считать их проблемой исключительно инженерных подразделений.

Спасибо за прекрасное интервью! Читателям, которые хотят больше узнать о безопасности облачных сред, приложениях, созданных с помощью ИИ, и защите корпоративных сред, стоит посетить сайт Orca Security.