В това видео на Help Net Security Мария Бахтина, изследовател в Масариковия университет, обяснява какво обещава и какво не обещава един сертификат по Common Criteria или FIPS-140. Според анализа на нейния екип около 6 от 10 уязвимости, съпоставени със сертифицирани продукти, с изключение на смарткартите, са били разкрити след датата на сертифициране. Тя описва също sec-certs и SCRUTINY – два инструмента с отворен код, разработвани от нейната лаборатория – както и единствения въпрос, който купувачите трябва да зададат на доставчика.
За щастие, документите за сертифициране (напр. Security Target при CC или Security Policy при FIPS-140) обикновено са до около 100 страници, а не 300. Но това все пак е много за един мениджър по обществени поръчки и снабдяване, който обикновено не е специалист по сигурността. През първия час мисля, че той би потърсил няколко неща: точното име на продукта и неговата версия, нивото на увереност (заедно с разглежданите заплахи, активи и покритите изисквания за сигурност), каква е оценяваната конфигурация и какво е обявено извън обхвата. Именно там се намират реалните граници на твърденията за сигурност. Покриването на всичко това може да отнеме повече от 1 час, ако мениджърът по снабдяването не е запознат с детайлите на схемата за сертифициране (напр. как са организирани документите).
И след това документът би спрял да помага поради причината, че представлява моментна снимка на продукта в миналото. Той ви казва какво е било оценено в един конкретен момент от времето. Не ви казва какво е било открито оттогава или какво е било променено. В нашия анализ от 2024 г. приблизително 6 от 10 от уязвимостите, съпоставени със сертифицирани продукти, с изключение на смарткартите, са били разкрити след датата на сертифициране. Освен това отделният предоставен документ за сертифициране не може да ви каже дали сертификатът все още е активен, или как продуктът се сравнява с останалите два в краткия ви списък за закупуване. Тези въпроси обхващат множество документи.
Да, напълно съм съгласна, че за средностатистическия човек „сертифициран“ звучи като „проверен е и отговаря на всички необходими критерии за този вид продукт“. Но в действителност не е точно така.
Нека първо разгледам Common Criteria, тъй като по-голямата част от нашите данни са за него. Сертификатът по CC казва, че акредитирана лаборатория е оценила определен продукт, в определена конфигурация, спрямо твърденията за сигурност, които доставчикът е описал в документ, наречен Security Target (Цел за сигурност). Много често тази цел се основава на Protection Profile (Профил на защита) за съответния тип продукт, като например смарткарти. Така че „отговаря на критериите“ всъщност означава „отговаря на критериите, за които доставчикът претендира, в рамките на дефинирания обхват“. Сертификатът също така казва, че оценката е следвала процеса при посочено ниво на увереност – EAL. Обещанието се отнася до твърденията и процеса, а не до това, че продуктът е сигурен като цяло.
FIPS 140 е нещо различно. Той валидира криптографски модул – тоест хардуера, софтуера или фърмуера, който извършва криптографията – спрямо изискванията на FIPS 140 на едно от четирите нива на сигурност. Обещанието се отнася за този модул в рамките на неговата дефинирана граница. То не казва нищо за приложението или системата около него.
Какво обикновено разчитат купувачите в това, най-вече по отношение на CC:
- „Няма уязвимости“: Не се казва това. ROCA, Minerva и TPM-Fail бяха открити в сертифицирани продукти, някои от които с високи нива на увереност.
- „Целият продукт е покрит“: Обхватът може да изключва определени функции. Попаднахме на сертифицирана по CC мрежова камера, при която мрежовият интерфейс се приемаше за доверен, така че вероятно никога не е бил тестван в тази част.
- „Версията, която купувам, е тази, която е била тествана, и все още е актуална.“ Сертификатът по CC се отнася за фиксирана конфигурация и има ограничена валидност. Обикновено тя е 5 години, след което той се архивира.
- „По-високо ниво означава, че е по-сигурен“: По-високото ниво не означава, че даден продукт е по-сигурен като цяло, а вместо това ви казва колко задълбочено е бил проверен продуктът. В нашите данни продуктите, оценени на по-високи нива, обикновено имаха по-малко сериозни уязвимости, но не и забележимо по-малък брой уязвимости. Така че това помага донякъде, но не е гаранция.
Документът за сертифициране е моментна снимка. Той не може да ви каже дали сертификатът все още е активен, дали има по-нова сертификация на същия продукт или върху какво е изграден продуктът. След като в документите може да се търси, можете да проверите всичко това бързо. Намирате сертификата, виждате дали все още е валиден или вече е архивиран, и проверявате дали съществува по-нова версия или повторна сертификация.
Можете също така да проследите към какво препраща документът, като например сертифицирания хардуер или библиотека, върху които е изграден продуктът, или профила на защита (Protection Profile), който той използва като базова линия. Това са отделни сертификати и документи. Преди трябваше да знаете, че те съществуват, и сами да ги изровите. Това има значение, защото онова, което стои в основата на продукта, е част от нещата, на които се доверявате. Търсенето ви отвежда бързо до правилните документи, но все пак трябва да прочетете какво пише в тях.
Sec-certs е инструмент с отворен код и уебсайт, който превръща публичните документи за сертифициране в свързан набор от данни с възможност за търсене. Това обхваща Common Criteria, FIPS 140 и EUCC. Всяка седмица той събира документите от официалните портали, извлича ключовите данни, свързва сертификатите с известни уязвимости и открива кои сертификати се позовават един на друг. Можете да го използвате на уебсайта или като библиотека за Python.
Създадохме го, защото всички тези доказателства са публични, но практически неизползваеми. Те се намират в хиляди дълги PDF файлове на множество национални портали, без общи идентификатори и без връзка с данните за уязвимости. Идеята дойде от изследователи в нашата лаборатория (Centre for Research on Cryptography and Security, CRoCS), които се нуждаеха точно от това по време на разкритията на ROCA и Minerva (ръководени от моя колега Петър Шведа).
Що се отнася до това кой го отваря пръв, всъщност не е само една група. От обратната връзка, която сме получили, всички те го използват, но по различни причини. Доставчиците проверяват собствените си записи. Те също така търсят продукти на други доставчици, които зависят от техните, тъй като сертификатите се позовават един на друг. И гледат какво сертифицират конкурентите им и как го правят. Купувачите идват, когато търсят продукти, използващи определена технология, и след това сравняват документите за сертифициране на тези продукти. Междувременно лабораториите за сигурност проверяват кои сертификати в категориите от тяхната компетентност ще изтекат скоро и по този начин намират потенциални клиенти за тестване като част от повторното сертифициране.
А що се отнася до това дали съвпада с това, което сте очаквали – бих казал, че като цяло да. Но в момента, тъй като не проследяваме систематично кои са потребителите и как използват инструмента, имаме само ограничен поглед от потребителите, които са се свързали с нас. Но благодарение на проекта CCAT, основният фокус за нашия екип е да получим повече обратна връзка от нашите потребители за това как да направим sec-certs още по-полезен и да предоставим повече данни, за да потвърдим или отхвърлим нашите по-нюансирани предположения за техните нужди.
Реакциите са смесени и мисля, че това е индикация, че инструментът изпълнява целта си за подобряване на прозрачността в екосистемата за сертифициране.
Някои доставчици гледат на това положително. Те могат да покажат на потенциални клиенти, че техният продукт има „страница“ в sec-certs, който е независим източник и изследователски проект с идеална цел. Така клиентите получават по-добър преглед на сертификацията на продукта, отколкото биха получили от собствените материали на доставчика, чиято достоверност на проверката отново изисква преминаване през различни портали за сертифициране.
От друга страна, ние не само правим сертификатите достъпни за търсене. Ние също така ги съпоставяме с уязвимости, които потенциално засягат сертифицираните продукти, а тези съвпадения са точни само с около 89% прецизност. Причината е, че обхватът на сертифициране често е дефиниран двусмислено и е трудно да се съпостави със CPE – структуриран, машинночетим стандарт за именуване за идентифициране на софтуер, операционни системи и хардуерни платформи. Ние подчертаваме, че откритите съвпадения са ориентировъчни и трябва да бъдат проверени. Въпреки това доставчиците не са доволни, когато техният продукт е показан с потенциални уязвимости.
Това, което си правя като извод от него, е, че доставчиците харесват видимостта, когато тя подкрепя сертификата като сигнал за доверие за клиентите, и я харесват по-малко, когато същата страница показва и потенциални уязвимости до него. Това също така показва до каква степен сертификатът се третира като статус, на който клиентите могат да разчитат.
SCRUTINY е инструментариум, който тества реалния продукт. Свързвате нещо с вградена криптография, като смарт карта, TPM чип, криптиран диск или криптографска библиотека, и той изпълнява набор от тестове. Кои криптографски функции наистина поддържа в сравнение с техническата спецификация? Как реагира на необичайни или злонамерени входни данни? Времето, необходимо за изчисляване на нещо, издава ли тайни? Наистина ли неговите случайни числа са случайни? Резултатите се превръщат в профил, който можете да сравните с еталон и да превърнете в четим доклад.
За купувача това има значение, защото сертификатът ви казва какво е било оценено на хартия. Криптографските недостатъци също са сериозни, но невидими отвън. Minerva е пример за това. Тя засегна сертифицирани карти, а слабостта беше във времето за подписване, което откривате чрез измерване.
Когато отчете статистическа аномалия, не бих казал „счупено“ или „шум“. Бих казал това, което знаем: „В данните, които събрахме, този тест откри отклонение и ето колко силни са доказателствата.“ След това бих казал дали се повтаря при нови данни и какво би означавало това за начина, по който планирате да използвате продукта. Бих използвал и прости нива: нищо не е открито, изисква се последваща проверка и възпроизводимо със силни доказателства.
SCRUTINY е инструмент, който ви помага да проверите дали продуктът, който купувате, се представя толкова добре, колкото този, който е бил тестван за сертифициране. И разбира се, ако купувачите нямат вътрешна експертиза за независима проверка на разликата между твърденията за сертифицираните и закупените продукти, би било в най-добрия интерес на доставчика да предостави базовите измервания като доказателство.
Единственото нещо, което трябва да се прочете, е обхватът на сертификацията: какво точно е сертифицирано, в коя версия и конфигурация и при какви предположения или изключения. Това е описано в Целта за сигурност (Security Target) или Политиката за сигурност (Security Policy), а докладът за сертифициране го обобщава. „Сертифициран“ ви казва твърде малко, докато не разберете това.
Единственият въпрос към доставчика: „Покажете ми къде в документите за сертифициране е обхваната функцията за сигурност, заради която купуваме това, за точната версия, която доставяте.“ Ако могат да го посочат, сте в добра позиция. Ако не могат или отговорът е „това е извън обхвата“, сте научили най-важното нещо преди подписването. Тогава си струва да се обмисли и независимо тестване, като това, което прави SCRUTINY.
- сертифициране
- съответствие
- киберсигурност
- Европа
- отворен код
- изследвания