Сигурност накрая срещу сигурност от самото начало: решението, което определя риска при доставката

Два екипа. Една и съща цел. Много различни резултати.

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

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

Когато сигурността идва накрая

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

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

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

Когато сигурността оформя дизайна

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

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

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

Разликата е зрелостта на оперативния модел

Разликата между двата подхода не е въпрос на предпочитание към процес, а на зрелост на оперативния модел, при който Екип А третира Сигурността като последна контролна точка, която валидира вече изграденото, докато Екип Б третира Сигурността като партньор в дизайна, който оформя това, което се изгражда.

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

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

Свържете се с Libertas Software Research, за да видите как можем да ви помогнем да преминете към модел, който доставя сигурно, предвидимо и в мащаб.