Съдържание
- Само фактите
- Без грешки, без стрес - Вашето стъпка по стъпка ръководство за създаване на софтуер, променящ живота, без да разрушава живота ви
- Счетоводство за въздействие?
- Време е да промените системата?
Източник: BrianAJackson / iStockphoto
За вкъщи:
Време е да разтърсим нещата с това как мислим за оценка на риска за компоненти с отворен код.
Проблемът е да се създаде система за оценка на това колко сериозно общността за разработка на софтуер трябва да приема уязвимостите. Кодът е написан от хората и винаги ще има недостатъци. Въпросът тогава, ако приемем, че никога нищо няма да бъде перфектно, е как най-добре да категоризираме компонентите според техния риск по начин, който ни позволява да продължим да работим продуктивно?
Само фактите
Въпреки че има много различни подходи, които може да се предприеме при решаването на този проблем, всеки със собствена валидна обосновка, изглежда, че най-често срещаният метод се основава на количествен модел.
От една страна, използването на количествен подход за преценка на тежестта на уязвимостта може да бъде полезно, тъй като е по-обективно и измеримо, основаващо се само на факторите, свързани със самата уязвимост.
Тази методология разглежда какъв вид щета може да възникне, ако уязвимостта се използва, като се има предвид колко широко използваният компонент, библиотека или проект се използва в цялата софтуерна индустрия, както и фактори като например какъв достъп може да даде на атакуващия унищожи хаос, ако го използват, за да нарушат целта си. Фактори като лесна потенциална експлоатация могат да играят голяма роля в това да повлияят на резултата. (За повече информация за сигурността, вижте Киберсигурност: Как новите аванси носят нови заплахи - и Vice Versa.)
Ако искаме да разгледаме макро ниво, количествената перспектива разглежда как уязвимостта може да навреди на стадото, като се съсредоточи по-малко върху щетите, които могат да нанесат на компаниите, които действително са засегнати от атаката.
Националната база данни за уязвимостта (NVD), може би най-известната база данни за уязвимости, използва този подход за двете версии 2 и 3 от тяхната Обща система за оценка на уязвимостта (CVSS). На страницата си, обясняваща своите показатели за оценка на уязвимости, те пишат за техния метод, който:
Нейният количествен модел гарантира повтарящо се точно измерване, като същевременно дава възможност на потребителите да видят основните характеристики на уязвимостта, използвани за генериране на резултатите. По този начин CVSS е подходящ като стандартна система за измерване за индустрии, организации и правителства, които се нуждаят от точни и последователни оценки на въздействието на уязвимостта.
Въз основа на количествените фактори, които играят, NVD може да излезе с оценка на тежестта, както с число в скалата им - 1 до 10, като 10 са най-тежките - както и категории НИСКИ, СРЕДНИ и ВИСОКИ ,
Без грешки, без стрес - Вашето стъпка по стъпка ръководство за създаване на софтуер, променящ живота, без да разрушава живота ви
Не можете да подобрите уменията си за програмиране, когато никой не се интересува от качеството на софтуера.
Счетоводство за въздействие?
Изглежда обаче, NVD полага усилия да се избягва от това, което можем да наречем като по-качествена мярка за уязвимост, основаваща се на това колко въздействащ определен експлоататор е причинил щети. За да бъдем справедливи, те включват въздействие, доколкото измерват въздействието на уязвимостта върху системата, като гледат факторите за конфиденциалност, цялостност и достъпност. Това са важни елементи, които трябва да се разгледат - например с по-лесно измеримия вектор на достъп, сложността на достъпа и удостоверяването - но те не се справят със задачата да свържат въздействието в реалния свят, когато уязвимостта причинява на организацията реални загуби.
Вземете например нарушението на Equifax, което разкри личната информация за около 145 милиона души, включително данни за техните шофьорски книжки, номера на социалното осигуряване и други битове, които биха могли да бъдат използвани от недобросъвестни персонажи за извършване на масивни измами.
Именно уязвимостта (CVE-2017-5638) беше открита в проекта Apache Struts 2, който Equifax използва в своето уеб приложение, което позволява на нападателите да се разхождат през входната врата и в крайна сметка да я разберат с ръце, пълни със сочна лична информация ,
Въпреки че NVD правилно му даде оценка за тежест 10 и HIGH, решението им се дължи на количествената им оценка на потенциалните му щети и не беше засегната от големи щети, настъпили по-късно, когато нарушението на Equifax стана публично достояние.
Това не е надзор от NVD, а част от тяхната заявена политика.
NVD предоставя CVSS "базови резултати", които представляват вродените характеристики на всяка уязвимост. Понастоящем не предоставяме „времеви оценки“ (показатели, които се променят с течение на времето поради събития, външни за уязвимостта) или „екологични оценки“ (оценки, персонализирани така, че да отразяват влиянието на уязвимостта върху вашата организация).
За лицата, вземащи решения, количествената измервателна система би трябвало да има по-малко значение, тъй като разглежда шансовете, че ще разпространи вреда в цялата индустрия. Ако сте организацията на гражданското общество на банката, трябва да сте загрижени за качественото въздействие, което може да има експлоатацията, ако се използва за компенсиране с данните на клиента ви или по-лошо - с парите им. (Научете за различните видове уязвимости в 5-те най-страшни заплахи в техниката.)
Време е да промените системата?
Така че трябва ли уязвимостта в Apache Strusts 2, която беше използвана в случая на Equifax, да получи по-висока класация в светлината на това колко големи щети се оказаха, или ще накара смяната да се окаже твърде субективна за система като NVD за продължавате?
Предоставяме, че извличането на необходимите данни за създаване на „екологичен резултат“ или „времева оценка“, както е описано от NVD, би било изключително трудно, отваряйки мениджърите на безплатния екип на CVSS до безкрайна критика и много работа за NVD и други за актуализиране на техните бази данни с излизането на нова информация.
Разбира се, съществува въпросът как би бил съставен такъв резултат, тъй като много малко организации вероятно ще предоставят необходимите данни за въздействието на нарушение, освен ако не се изисква от закона за оповестяване. От случая с Uber видяхме, че компаниите са готови да изплащат бързо с надеждата да запазят информацията около дадено нарушение да стигне до пресата, за да не се сблъскат с обществена реакция.
Може би това, което е необходимо, е нова система, която би могла да включи добрите усилия от базите данни за уязвимостта и да добави свой собствен допълнителен резултат, когато информацията стане достъпна.
Защо да подбуждате този допълнителен слой за оценка, когато предишният изглежда е свършил достатъчно добре своята работа през всичките тези години?
Честно казано, свежда се до отчетността на организациите да поемат отговорност за своите приложения. В идеален свят всеки би проверил десетките компоненти, които използва в своите продукти, преди да ги добави в инвентара си, да получава сигнали, когато бъдат открити нови уязвимости в проекти, за които преди това се е смятало, че са безопасни, и да прилага необходимите пачове всички сами. ,
Може би, ако има списък, който показва колко опустошителни могат да бъдат някои от тези уязвимости за една организация, тогава организациите може да почувстват по-голям натиск да не бъдат хванати с рискови компоненти. Най-малкото, те могат да предприемат стъпки, за да направят истински опис кои библиотеки с отворен код вече имат.
След фиаско на Equifax, повече от един изпълнителен директор на ниво C вероятно се надраска, за да се увери, че не разполагат с уязвимата версия на Struts в своите продукти. Жалко е, че беше необходим инцидент с такъв мащаб, за да накара индустрията да вземе сериозно сигурността си с отворен код.
Надяваме се, че урокът, че уязвимостите в компонентите с отворен код на вашите приложения могат да имат много реални последици, ще се отрази върху това как лицата, вземащи решения, дават приоритет на сигурността, избирането на правилните инструменти, за да запазят данните на своите продукти и данните на клиентите си.