Бяспека напрыканцы супраць бяспекі з самага пачатку: рашэнне, якое вызначае рызыку пастаўкі

Дзве каманды. Адна мэта. Вельмі розныя вынікі.

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

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

Калі бяспека прыходзіць толькі напрыканцы

Каманда A звычайна паказвае высокі пачатковы тэмп, таму што рашэнні прымаюцца без абмежаванняў, архітэктура вызначаецца хутка, а функцыі рэалізуюцца без неабходнасці ўлічваць знешнюю валідацыю; аднак гэтая ўяўная хуткасць часовая, бо як толькі сістэма трапляе пад фармальны агляд бяспекі, пачынаюць выяўляцца праблемы, якія не з'яўляюцца павярхоўнымі, а структурна ўкараніліся ў сам спосаб праектавання сістэмы.

Мадэлі аўтэнтыфікацыі могуць не адпавядаць неабходным стандартам, падыходы да апрацоўкі даных могуць уводзіць рызыкі адпаведнасці, механізмы кантролю доступу могуць быць недастатковымі, і ў многіх выпадках гэта не асобныя дэфекты, а праблемы ўзроўню праектавання, якія патрабуюць перапрацоўкі ў некалькіх кампанентах сістэмы, а не простых выпраўленняў.

На гэтым этапе бяспека часта ўспрымаецца як перашкода, але насамрэч яна дзейнічае як карэкціруючая сіла, выяўляючы прабелы, закладзеныя раней, калі рашэнні прымаліся без поўнага кантэксту; вынік прадказальны: затрымкі, большыя выдаткі, дубляванне намаганняў і ўзрастаючае трэнне паміж камандамі распрацоўкі і бяспекі па меры ўзмацнення ціску на пастаўку.

Калі бяспека фарміруе праектаванне

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

Гэта не зніжае хуткасць распрацоўкі ў істотным сэнсе, але змяняе саму прыроду распрацоўкі, таму што рашэнні прымаюцца пры поўным разуменні абмежаванняў, кампрамісы становяцца выразнымі, а не выпадковымі, а архітэктурныя выбары з самага пачатку ўзгадняюцца як з аперацыйнымі, так і з бяспечнаснымі патрабаваннямі.

У выніку пастаўка становіцца больш прадказальнай, перапрацоўка значна скарачаецца, а сістэма, якая трапляе ў вытворчае асяроддзе, не толькі функцыянальная, але і ўстойлівая, аўдытуемая і здольная працаваць у рэальных умовах без увядзення непатрэбнай арганізацыйнай рызыкі.

Розніца ў сталасці аперацыйнай мадэлі

Розніца паміж гэтымі двума падыходамі не ў перавазе працэсу, а ў сталасці аперацыйнай мадэлі, у якой Каманда A разглядае Бяспеку як фінальную кантрольную кропку, што пацвярджае ўжо пабудаванае, у той час як Каманда B разглядае Бяспеку як партнёра па праектаванні, які фарміруе тое, што будуецца.

Толькі адна з гэтых мадэляў эфектыўна маштабуецца па меры росту складанасці сістэм і ўсё большай залежнасці арганізацый ад надзейнасці і цэласнасці свайго праграмнага забеспячэння.

Калі ваша арганізацыя ўсё яшчэ працуе як Каманда A, пытанне не ў тым, ці паўплывае гэта на пастаўку, а калі.

Звяжыцеся з Libertas Software Research, каб даведацца, як мы можам дапамагчы вам перайсці да мадэлі, якая пастаўляе бяспечна, прадказальна і ў маштабе.