Час змінювати підходи до нейтралізації загрози ПДВ

Нещодавно я писав про недекларовані можливості. Нотатка була пов'язана із складнощами у проведенні оцінки відсутності недекларованих можливостей для продукції американського походження. До цього були ще записи (тут, тут і тут). На мій погляд, зараз назріла необхідність перегляду цього застарілого підходу до пошуку недокументованих можливостей як єдиного методу перевірки не тільки функціональності засобу захисту, а й захищеності його самого. Частково цей крок вже зроблено ФСТЕК у 21-му наказі, в якому для актуальних загроз 1-го та 2-го типів (ПДВ на системному та прикладному рівні відповідно) передбачена не лише оцінка відсутності НДВ, як одного зі способів нейтралізації загроз. -го та 2-го типів, але й також:

  • впровадження розробниками методів захищеного програмування (SDLC)
  • застосування тестів для проникнення.

Тут відразу ж виникає питання - а як довести реалізацію одного із зазначених заходів? Ну з пентестом більш менш зрозуміло - я можу показати або договір із зовнішньою фірмою на надання відповідних послуг, або власний регламент проведення пентестів з журналом їх здійснення. А як бути з SDLC? Декларативно від виробника. Але пошук НДВ і покликаний захиститися від випадкових уразливостей або навмисних закладок. Як ми тоді можемо довіряти декларації виробника? Незалежну оцінку вимагати? Поки що відповідей немає, але сам факт розширення такого списку та вихід за межі одних лише НДВ вражає.

Поки "тільки НДВ" у нас залишається для галузі держтаємниці та засобів захисту інформації при певних класах та рівнях захищеності за 21-м та 17-м наказами ФСТЕК. Та й по лінії ФСБ це обов'язкова річ. Але як було показано раніше, надання вихідних джерел, без якихпровести сертифікацію на відсутність НДВ навіть для 4-го класу, завдання малореальне для багатьох розробників. Глухий кут? Поки так.

З іншого боку, пошук недекларованих можливостей не скрізь потрібен. Ну держтаємниця добре. А ПДн? А конфіденціалка у держорганах? Там навіщо витрачати колосальні кошти на перевірку вихідних програм або заліза, якщо загроза явно неактуальна або непорівнянна з витратами на пошук НДВ?

Може час переглянути підхід? Я запропонував би спочатку чітко окреслити коло організацій, на яких поширюється вимога пошуку НДВ і, зокрема, прибрав би звідти тему перданних зовсім. Ну, не є пошук НДВ (навіть у засобах захисту) актуальним заходом нейтралізації загроз для даного виду інформації обмеженого доступу. І для банківської таємниці також. І для податкової, аудиторської та шести десятків інших таємниць теж. Існують дешевші і не менш ефективні для даної задачі варіанти. І ось тут я згадав би документи американського Міноборони і NIST, про які вже писав . Вони прописано, що з підвищення якості коду (з погляду його захищеності, надійності, живучості тощо.), необхідно використовувати різні (на вибір замовника) механізми:

  • Інструментальні засоби аналізу коду (як вихідного, а й виконуваного). Саме сюди потрапляють різноманітні продукти класу SAST/DAST/фаззери тощо.
  • Аналіз уразливостей та загроз. Тут все зрозуміло – сканери захищеності, що працюють у режимі black box, grey box або white box.
  • "Ручний" аналіз коду.
  • Пентести.
  • Моделювання загроз. Тут приклад може бути таким. Власна розробка та з розробниками ведеться організаційна робота, що знижує ймовірність внесення ПДВ у код ПЗ. Або ПЗ написано такою старою мовою, що ніхто і не пам'ятає, як ним користуватисяі як внести закладки (згадайте історію з шифрувальниками з індіанців навахо під час Другої світової війни).
  • Перевірка області тестування/аналізу.
  • Симуляція/емуляція.

Напевно, можна вигадати і щось інше для заміни не завжди потрібної оцінки відповідності на відсутність НДВ. Головне, не стояти дома і рушити вперед, запропонувавши споживачеві кілька альтернатив і підготувавши відповідну методологічну базу кожному за запропонованих вище варіантів. Тоді і завдання оцінки якості ПЗ буде вирішено і витрати будуть більш адекватними ризикам і претензій з боку ринку до регуляторів буде менше.