заглушки Преодоление главных проблем безопасности при разработке с использованием искусственного интеллекта с низким кодом или без него - Unite.AI
Свяжитесь с нами:

Лидеры мысли

Преодоление основных проблем безопасности при разработке с использованием искусственного интеллекта с низким кодом или без него

mm

опубликованный

 on

Платформы разработки с низким кодом изменили способы создания индивидуальных бизнес-решений, включая приложения, рабочие процессы и дополнительные пилотные программы. Эти инструменты расширяют возможности гражданских разработчиков и создают более гибкую среду для разработки приложений. Добавление ИИ в эту смесь только усилило эту возможность. Тот факт, что в организации недостаточно людей, обладающих навыками (и временем) для создания такого количества приложений, средств автоматизации и т. д., необходимых для продвижения инноваций, привел к появлению концепции low-code/no-code. парадигма. Теперь, не нуждаясь в формальном техническом обучении, гражданские разработчики могут использовать удобные для пользователя платформы и генеративный искусственный интеллект для создания, внедрения инноваций и развертывания решений на основе искусственного интеллекта.

Но насколько безопасна эта практика? Реальность такова, что это создает множество новых рисков. Вот хорошие новости: вам не придется выбирать между безопасностью и эффективностью, которую обеспечивают инновации, основанные на бизнесе.

Выход за рамки традиционного подхода

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

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

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

Множество новых рисков

 Некоторые из потенциальных проблем безопасности, связанных с разработкой с минимальным использованием кода или без него, включают:

  1. Не в компетенции ИТ-специалистов – как только что упоминалось, гражданские разработчики работают вне сферы ИТ-специалистов, что приводит к недостаточной прозрачности и теневой разработке приложений. Кроме того, эти инструменты позволяют бесконечному количеству людей быстро создавать приложения и средства автоматизации всего за несколько кликов. Это означает, что бесчисленное количество приложений создается с головокружительной скоростью неисчислимым количеством людей, и при этом ИТ-специалисты не имеют полной картины.
  2. Нет Жизненный цикл разработки программного обеспечения (SDLC) – Разработка программного обеспечения таким способом означает отсутствие SDLC, что помимо риска может привести к несогласованности, путанице и отсутствию подотчетности.
  3. Начинающие разработчики. Эти приложения часто создаются людьми с меньшими техническими навыками и опытом, что открывает двери для ошибок и угроз безопасности. Они не обязательно думают о последствиях безопасности или разработки так, как это сделал бы профессиональный разработчик или кто-то с большим техническим опытом. А если уязвимость обнаружена в определенном компоненте, встроенном в большое количество приложений, существует вероятность того, что ее можно будет использовать в нескольких экземплярах.
  4. Неправильная практика идентификации. Управление идентификацией также может быть проблемой. Если вы хотите предоставить бизнес-пользователю возможность создавать приложение, первое, что может его остановить, — это отсутствие разрешений. Часто это можно обойти, и в результате пользователь может использовать чужую личность. В этом случае нет возможности выяснить, сделали ли они что-то не так. Если вы получили доступ к чему-то, к чему вам не разрешено, или попытались сделать что-то вредоносное, служба безопасности будет искать личность заимствованного пользователя, поскольку нет возможности отличить их друг от друга.
  5. Отсутствие кода для сканирования. Это приводит к отсутствию прозрачности, что может затруднить устранение неполадок, отладку и анализ безопасности, а также возможные проблемы с соблюдением нормативных требований.

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

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

Возвращение видимости

Как уже упоминалось, один из большие проблемы с низким кодом или его отсутствием заключаются в том, что он не входит в компетенцию ИТ/безопасности., что означает, что данные проходят через приложения. Не всегда есть четкое понимание того, кто на самом деле создает эти приложения, и в целом отсутствует понимание того, что происходит на самом деле. И не каждая организация даже полностью осознает, что происходит. Или они думают, что в их организации не происходит развития граждан, но это почти наверняка происходит.

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

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

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

На пути к более безопасному использованию low-code/no-code

Традиционный процесс ручного кодирования препятствует инновациям, особенно в конкурентных сценариях вывода продукции на рынок. Благодаря современным платформам с низким кодом и без кода даже люди без опыта разработки могут создавать решения на основе искусственного интеллекта. Хотя это упростило разработку приложений, это также может поставить под угрозу безопасность и защищенность организаций. Однако это не обязательно должен быть выбор между развитием граждан и безопасностью; Руководители службы безопасности могут сотрудничать с бизнес-пользователями, чтобы найти баланс для обоих.

Майкл — сооснователь и технический директор компании Зенити. Он является отраслевым экспертом в области кибербезопасности, интересуется облачными технологиями, SaaS и AppSec. До прихода в Zenity Майкл был старшим архитектором в офисе технического директора Microsoft Cloud Security, где он основал и возглавил разработку продуктов безопасности для Интернета вещей, API, IaC и конфиденциальных вычислений. Майкл возглавляет усилия сообщества OWASP по обеспечению безопасности с низким кодом и без него.