Мениджър по продажбите изгражда работен процес с помощта на изкуствен интелект за насочване на потенциални клиенти. Той се свързва със клиентски записи, обобщава входящите запитвания и публикува актуализации в споделен канал. Този работен процес спестява време, намалява ръчната работа и скоро се превръща в част от ежедневната рутина на екипа. В същата организация служителите създават полезни приложения, агенти и автоматизации по-бързо, отколкото съществуващите процеси могат да ги поддържат.

Ако работите в сферата на сигурността, този успех поражда нов набор от въпроси. Чии идентификационни данни използва работният процес? До кои записи има достъп? Кой може да вижда генерираните от него резултати? Ако започне да разкрива информация, която не би трябвало, можете ли да проследите какво се е случило и да спрете по-нататъшния достъп?

„Дивият код“ (wild code) пуска корени, когато полезните разработки се разпространяват по-бързо от процесите по поемане на отговорност, осигуряване на защита и поддръжка. Това не е просто друго име за неодобрен софтуер. Служителите създават нови възможности, а не просто внедряват съществуващи продукти. Един малък експеримент може да се превърне в оперативна зависимост, преди екипът по сигурността изобщо да разбере за съществуването му.

Рискът надхвърля уязвимостите в генерирания код. Дори код, който работи по предназначение, може да оперира с прекомерен достъп или да разкрие данни пред неподходяща аудитория:

  • Прекомерни права за достъп. Даден работен процес се нуждае от малък набор от записи, но работи с идентификационни данни, които могат да четат или модифицират много повече.
  • Излагане на чувствителни данни. Служител свързва агент с информация, от която той не се нуждае, или прави изходните му данни твърде широко достъпни. Чувствителна информация може също така да попадне в заявките към моделите или в системните логове.
  • Непредвидени действия. Агент може да промени записи или права за достъп без граница на одобрение, съответстваща на извършваното действие.
  • Изоставен достъп (Orphaned access). Полезен работен процес продължава да функционира след като неговият създател смени позицията си или напусне организацията, без ясен отговорник, който да преразглежда правата му.
  • Пропуски при разследване. Когато нещо се обърка, екипът по сигурността не може лесно да установи коя самоличност е стартирала работния процес, до какво е имала достъп или какво е било променено.

Обучението на служителите, изолираните среди и управителните комитети по изкуствен интелект са добро начало, но сами по себе си не са достатъчни за овладяването на дивия код. По-устойчивият подход вгражда контролни механизми в самата среда: към какво могат да се свързват служителите, какво могат да правят техните приложения и агенти и как тази работа се наблюдава след нейното стартиране.

Защо обичайните решения се оказват недостатъчни

Обучението, изолираните среди и управителните комитети имат своята роля. Грешката е да се очаква от тях да управляват софтуер, с който може никога да не се сблъскат, или да контролират случващото се, след като той вече работи. Дадена политика описва какво би трябвало да се случи. Сигурността обаче се нуждае и от контролни механизми, които да ограничават това, което може да се случи, доказателства за това какво се е случило, както и начин за намеса.

1. Обучението разяснява добрите практики, но не може да ги наложи принудително

Една политика за изкуствен интелект може да поясни какво е позволено. Обучението може да представи добрите практики. Нито едно от двете обаче не гарантира, че човек, изграждащ работен процес за отчети, ще разпознае момента, в който прекрачва границата към обработка на чувствителни данни или управление на софтуер в производствена среда.

Тъй като изкуственият интелект привлича все повече служители към създаването на софтуер, организациите имат възможност да направят по-достъпни практики като минимални привилегии, управление на тайни и отделяне на тестовите среди от производствените. Политиките могат да задават очаквания, но служителите се нуждаят също от практически насоки и вградени защитни механизми, за да ги прилагат в ежедневната си работа.

Дори служителите, които разпознават риска, все пак са изправени пред крайни срокове и натиск да действат по-бързо. Ако одобреният път е бавен или объркващ, познаването на правилата не прави спазването им по-лесно.

Обучението помага на хората да вземат по-добри решения. То обаче не бива да бъде единственото нещо, което предотвратява несигурна връзка или неоторизирано действие.

2. Изолираните среди защитават експериментите, но не и цялото им бъдеще

Изолираната среда е полезна за тестване на промптове, модели и генериран код. Стойността на прототипа обаче често зависи от това в крайна сметка да достигне до реални бизнес системи и данни.

След като прототипът се свърже с реални бизнес системи, той се нуждае от контролни механизми, които се простират отвъд тестовата среда. Правата за достъп, мониторингът и прегледите на промените трябва да останат активни през целия му жизнен цикъл, а не само по време на експеримента. Успешният тест не определя до кои данни трябва да има достъп производственият работен процес или какви действия трябва да му бъде позволено да предприема.

Както се изразява Брад Ръмф, полеви технически директор (field CTO) в Tines: „Изолираните среди решават проблема с проектирането, но оставят проблема по време на изпълнение непокътнат.“

Успешният експеримент все пак се нуждае от регламентиран път към експлоатация. Без такъв път изолацията по-скоро отлага трудните въпроси, отколкото да ги решава.

3. Комитетите не могат да правят преглед на това, което не могат да видят

Управителните комитети могат да задават посока, да установяват отчетност и да вземат решения относно случаи на употреба с висок риск. Техните цикли на преглед обаче невинаги съответстват на скоростта, с която служителите могат да създават и внедряват софтуер.

Комитетът може да забрани една рискова практика, докато служителите откриват друг начин за постигане на същия резултат. Надзорът също така може да се концентрира върху инженерните екипи, където вече съществуват установени контролни механизми, като същевременно пренебрегва разработките във финансовия отдел, човешките ресурси или оперативната дейност.

Ограничението не се корени в качеството на комитета. То е в модела, който разчита на това всяка разработка да стане видима, преди да стане полезна. Процесът на одобрение не може да бъде единственият начин, по който сигурността открива нови пътища към чувствителни данни и привилегировани действия.

Поставете контролите за сигурност там, където се извършва работата

Алтернативата е контролните механизми да се вградят в средата, която служителите използват за създаване, изпълнение и поддръжка на своята работа.

Вместо да се изисква от всеки независимо да сглобява сигурен оперативен модел, екипите по сигурност дефинират споделени граници с ИТ отдела и собствениците на системи, прилагат ги последователно през целия жизнен цикъл и ги актуализират според промяната на бизнес нуждите и рисковете.

Три принципа правят това приложимо на практика.

1. Управлявайте преди внедряване и продължавайте да управлявате след това

Определете разрешените източници на данни, действия и нива на достъп, преди служителите да свържат бизнес системите. Запазете тези контролни механизми активни, когато работният процес премине в реална експлоатация.

Правата за достъп трябва да отразяват това, което работният процес трябва да извърши, а не всичко, до което неговият създател има достъп. Действията с важни последици следва да изискват човешко одобрение, където е уместно. Промпт, който казва на даден агент какво да не прави, не представлява контрол на достъпа.

Поддържайте създаването, изпълнението и мониторинга свързани помежду си. Одобрената разработка не бива да се превръща в оперативно сляпо петно в момента, в който някой започне да я използва.

2. Направете одобрения маршрут най-лесния маршрут

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

Това означава достъпни работни процеси за създаване, полезни връзки към одобрени системи и ясен път от идеята до въвеждането в експлоатация. Административните контроли на ниво организация могат да ограничат рисковите алтернативи, но официално одобрената опция също така трябва да отговаря на нуждите на служителите.

Ако управлението създава пречки на всяка стъпка, потребителите ще изберат заобиколни решения, за да свършат работата си. Споделените защитни мерки трябва да покриват рутинните изисквания, така че екипите по сигурност да могат да съсредоточат по-задълбочения си анализ върху чувствителния достъп и действията с критични последствия.

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

3. Превърнете разследването и намесата в част от архитектурата

Сигурността трябва да разбира какво всъщност е извършил даден работен процес, а не само какво е било предвидено да направи.

Поддържайте проследими собствеността, идентификационните данни за изпълнение, съответните действия и промените. Защитете тези записи, без излишно да улавяте чувствителна информация в журналните файлове (logs).

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

Как изглежда това на практика

Една управлявана среда трябва да позволява на важните въпроси относно сигурността да се отговори без отделно разследване:

  • Отговорна собственост. Кой притежава работния процес и с каква самоличност се изпълнява той?
  • Контролиран достъп. Какво може да чете, променя и изпраща другаде? Кои действия изискват одобрение и къде се прилага това изискване?
  • Защитено изпълнение. Изолирани ли са стъпките на работния процес и въвеждат ли се идентификационните данни по време на изпълнение, вместо да бъдат изложени в кода? Тези защити трябва да допълват, а не да заместват правилно определения обхват на правата за достъп.
  • Проследима активност. Може ли екипът по сигурност да установи какво е работило, до какво е имало достъп и какво е било променено?
  • Ясна намеса. Как екипите по сигурност спират изпълнението и отнемат достъпа, ако нещо се обърка?

Тези контроли не премахват всеки риск. Те намаляват зависимостта от това служителите да помнят всяко правило, а екипът по сигурност да открива всеки проблем постфактум.

Запазете контрола, докато все повече хора разработват

Служителите ще продължат да намират ценни начини да създават решения с помощта на изкуствен интелект. Целта е тези подобрения да станат видими, поддържани и сигурни още от самото начало.

Като специалист по сигурност не е необходимо да се превръщате в поддръжник на всяко създадено от служителите приложение. Нужно е обаче да сте уверени, че работните процеси, които засягат чувствителни системи, имат подходящ достъп, отговорни собственици и активност, която можете да разследвате.

Вграденото управление превръща тези защити в част от ежедневната разработка, а не в упражнение по разчистване след внедряването. То дава на служителите възможност да решават проблеми, като същевременно предоставя на екипа по сигурност ясни граници за налагане на правилата и начин за реакция, ако нещо се обърка.

Това е идеята, залегнала в Tines: да се даде възможност на екипите да създават приложения, агенти и автоматизации с помощта на изкуствен интелект, като същевременно сигурността запазва контрола върху начина, по който протича тази работа. За по-подробен поглед върху рамката и контролен списък за готовност изтеглете Taming wild code: The IT leader’s guide to AI code sprawl.