Зміст
- Просто Факти
- Ні помилок, ні стресу - покроковий посібник зі створення програмного забезпечення, що змінює життя, не руйнуючи ваше життя
- Облік впливу?
- Час змінити систему?
Джерело: BrianAJackson / iStockphoto
Винос:
Настав час розібратися з тим, як ми думаємо про оцінку ризику для компонентів з відкритим кодом.
Розробка системи для оцінки того, наскільки серйозно спільнота розробки програмного забезпечення повинна сприймати вразливості, є проблемою, і це легко сказати. Код написаний людьми, і завжди матиме вади. Тоді питання, якщо ми будемо вважати, що нічого ніколи не буде ідеальним, як ми найкраще класифікуємо компоненти відповідно до їх ризику таким чином, що дозволяє нам продовжувати продуктивно працювати?
Просто Факти
Хоча існує багато різних підходів, які можна застосувати при вирішенні цієї проблеми, кожен зі своїм власним обґрунтуванням, як видається, найбільш поширений метод базується на кількісній моделі.
З одного боку, використання кількісного підходу до оцінки суворості вразливості може бути корисним тим, що воно є більш об'єктивним та вимірюваним, виходячи виключно з факторів, пов'язаних із самою вразливістю.
Ця методологія розглядає, який збиток може статися в разі використання вразливості, враховуючи, наскільки широко використовується компонент, бібліотека чи проект у всій індустрії програмного забезпечення, а також такі фактори, як, який саме доступ може надати зловмиснику руйнувати хаос, якщо вони використовуватимуть це для порушення своєї мети. Такі фактори, як легка потенційна експлуатація, можуть зіграти тут велику роль у впливі на рахунок. (Щоб дізнатися більше про безпеку, ознайомтеся з кібербезпекою: як нові аванси приносять нові загрози - і віце-верса.)
Якщо ми хочемо подивитися на макрорівні, в кількісній перспективі розглядається, як вразливість може завдати шкоди стаду, зосереджуючись менше на збитках, які можуть нанести компанії, які насправді зазнали нападу.
Національна база даних про вразливість (NVD), можливо, найвідоміша база даних про вразливості, використовує такий підхід для обох версій 2 та 3, їхньої Загальної системи оцінювання вразливості (CVSS). На своїй сторінці, що пояснює свої показники для оцінки вразливості, вони пишуть про свій метод, який:
Його кількісна модель забезпечує повторне точне вимірювання, дозволяючи користувачам бачити основні характеристики вразливості, які використовувались для отримання балів. Таким чином, CVSS цілком підходить як стандартна система вимірювань для галузей, організацій та урядів, які потребують точних та послідовних показників впливу на вразливість.
Виходячи з кількісних факторів, які грають, NVD зможе придумати показник суворості, як число за їх шкалою - від 1 до 10, причому 10 є найбільш суворими - а також категорії НИЗКОГО, середнього та високого .
Ні помилок, ні стресу - покроковий посібник зі створення програмного забезпечення, що змінює життя, не руйнуючи ваше життя
Ви не можете покращити свої навички програмування, коли ніхто не піклується про якість програмного забезпечення.
Облік впливу?
Однак, схоже, NVD докладає зусиль, щоб уникнути того, що ми можемо назвати більш якісним показником вразливості, виходячи з того, наскільки певний подвиг спричинив шкоду. Для справедливості вони включають вплив, якщо вимірюють вплив вразливості на систему, дивлячись на фактори конфіденційності, цілісності та доступності. Це всі важливі елементи, на які слід звернути увагу - на зразок легшого вимірюваного вектора доступу, складності доступу та автентифікації - але вони не вирішують завдання пов'язати вплив реального світу, коли вразливість спричиняє організацію реальних втрат.
Візьмемо, наприклад, порушення Equifax, яке викрило особисту інформацію про 145 мільйонів людей, включаючи дані про їхні водійські номери, номери соціального страхування та інші біти, які можуть бути використані недобросовісними персонажами для проведення масових операцій з шахрайством.
Саме вразливість (CVE-2017-5638) була виявлена в проекті Apache Struts 2, який Equifax використовував у своєму веб-додатку, який дозволив зловмисникам ходити у вхідні двері та врешті-решт розібратися зі зброєю, наповненою соковитою особистою інформацією .
Незважаючи на те, що NVD справедливо дав їй оцінку суворості 10 та ВИСОКИЙ, їх рішення було обумовлене кількісною оцінкою його потенційного збитку і не вплинуло на великий збиток, який стався пізніше, коли порушення Equifax стало публічним.
Це не нагляд з боку NVD, а частина їх заявленої політики.
NVD забезпечує базові показники CVSS, які представляють вроджені характеристики кожної вразливості. Наразі ми не надаємо "тимчасових показників" (показники, які змінюються в часі через події, зовнішні для вразливості) або "екологічні показники" (бали, налаштовані так, щоб відображати вплив вразливості на вашу організацію).
Для осіб, які приймають рішення, кількісна система вимірювання повинна мати менше значення, оскільки вона розглядає шанси на те, що вона поширить шкоду в галузі. Якщо ви є ОГС банку, вам слід потурбуватися про якісний вплив, який може мати подвиг, якщо він використовується для заповнення даних клієнта або, що ще гірше, їх грошей. (Дізнайтеся про різні типи вразливостей у 5 найстрашніших загрозах техніці.)
Час змінити систему?
Тож якщо вразливість у Apache Strusts 2, яка була використана у випадку Equifax, отримає більш високий рейтинг у світлі того, наскільки обширним виявився збиток, або якщо зсув виявиться занадто суб'єктивним для такої системи, як NVD продовжувати?
Ми надаємо, що придумати необхідні дані, щоб створити "екологічну оцінку" або "тимчасову оцінку", як описано NVD, було б надзвичайно складно, відкриваючи керівників вільної команди CVSS до нескінченної критики та багато роботи для NVD та інших для оновлення своїх баз даних у міру появи нової інформації.
Звичайно, виникає питання про те, як складати такий рахунок, оскільки дуже мало організацій, можливо, нададуть необхідні дані про вплив порушення, якщо цього не вимагатиме закон про розкриття інформації. З випадку Uber ми бачили, що компанії готові швидко виплачувати, сподіваючись утримати інформацію, що стосується порушення, не потрапляти до преси, щоб вони не стикалися з публічними реакціями.
Можливо, потрібна нова система, яка могла б включати в себе всі зусилля з баз даних про вразливість і додавати власну додаткову оцінку, коли інформація стане доступною.
Навіщо наштовхувати цей додатковий рівень балів, коли, здається, попередній зробив свою роботу досить добре всі ці роки?
Чесно кажучи, справа зводиться до відповідальності організацій брати на себе відповідальність за свої заявки. В ідеальному світі кожен перевіряв би кількість компонентів, які використовує у своїх продуктах, перш ніж додавати їх у свій інвентар, отримуватиме повідомлення, коли виявляються нові вразливості в проектах, які раніше вважалися безпечними, та впроваджував необхідні виправлення самостійно .
Можливо, якби був список, який би показав, як руйнівні деякі з цих вразливих місць можуть бути для організації, то організації можуть відчути більший тиск, щоб не потрапити в небезпечні компоненти. Принаймні, вони можуть вжити заходів для реального опису бібліотек з відкритим кодом, які вони вже мають.
Після фіаско Equifax більше ніж один керівник рівня C, мабуть, намагався переконатися, що у них немає вразливої версії Struts у своїх продуктах. Прикро, що знадобився інцидент такого масштабу, який підштовхнув цю галузь до серйозного сприйняття безпеки з відкритим кодом.
Сподіваємось, урок про те, що вразливості компонентів з відкритим кодом ваших програм можуть мати дуже реальні наслідки, впливатимуть на те, як особи, які приймають рішення, надають пріоритет безпеці, вибираючи правильні інструменти для збереження даних своїх продуктів та клієнтів.