Pull to refresh

Размышления о государственной сертификации антивирусов

Reading time 5 min
Views 13K
С каждым годом от IT-специалистов наши доблестные регуляторы (ФСБ и ФСТЭК в первую очередь) требуют все больше различного рода лицензий, разрешений, сертификатов и тому подобных бумажек. ФСБ навязывает использования своих «фирменных» алгоритмов шифрования, взамен малопонятных им общемировых. ФСТЭК норовит сунуть нос поглубже в код программных продуктов, в своих поисках недекларированных возможностей, «заботясь» о безопасности нашей с вами информации.
А есть ли вообще смысл в подобных исследованиях применительно к современным антивирусам?

Для дома можно использовать любые антивирусы, а вот для госструктур или для защиты персональных данных в информационных системах персональных данных (ИСПДн) придется выбирать продукт, прошедший соответствующую сертификацию.

Законодательство


Так, согласно постановлению Правительства РФ №781 от 17.11.2007, средства защиты информации, применяемые в ИСПДн, в установленном порядке обязаны пройти процедуру оценки соответствия (установленным требованиям, которые прописаны в руководящих документах ФСТЭК). В частности, использование только сертифицированных решений для госучреждений прописано в таких документах, как Указы Президента РФ от 17 марта 2008г. №351 «О мерах по обеспечению информационной безопасности РФ при использовании информационно-телекоммуникационных сетей международного информационного обмена» и от 12 мая 2004г. №611 «О мерах по обеспечению информационной безопасности Российской Федерации в сфере международного информационного обмена».

Программное обеспечение проверяется на соответствие требованиям руководящего документа «Защита от несанкционированного доступа к информации. Часть 1. Программное обеспечение средств защиты информации. Классификация по уровню контроля отсутствия недекларированных возможностей».

Ключевым моментом данного РД является вот такая табличка:

Требования к уровню контроля. Перечень требований.

Наименование требования Уровень
контроля
4 3 2 1
Требования к документации
1 Контроль состава и содержания документации
1.1. Спецификация (ГОСТ 19.202-78) + = = =
1.2. Описание программы (ГОСТ 19.402-78) + = = =
1.3. Описание применения (ГОСТ 19.502-78) + = = =
1.4. Пояснительная записка (ГОСТ 19.404-79) - + = =
1.5. Тексты программ, входящих в состав ПО (ГОСТ 19.401-78) + = = =
Требования к содержанию испытаний
2. Контроль исходного состояния ПО + = = =
3. Статический анализ исходных текстов программ
3.1. Контроль полноты и отсутствия избыточности исходных текстов + + + =
3.2. Контроль соответствия исходных текстов ПО его объектному (загрузочному) коду + = = +
3.3. Контроль связей функциональных объектов по управлению - + = =
3.4. Контроль связей функциональных объектов по информации - + = =
3.5. Контроль информационных объектов - + = =
3.6. Контроль наличия заданных конструкций в исходных текстах - - + +
3.7. Формирование перечня маршрутов выполнения функциональных объектов - + + =
3.8. Анализ критических маршрутов выполнения функциональных объектов - - + =
3.9. Анализ алгоритма работы функциональных объектов на основе блок-схем, диаграмм и т. п., построенных по исходным текстам контролируемого ПО - - + =
4. Динамический анализ исходных текстов программ
4.1. Контроль выполнения функциональных объектов - + + =
4.2. Сопоставление фактических маршрутов выполнения функциональных объектов и маршрутов, построенных в процессе проведения статического анализа - + + =
5. Отчетность + + + +
Обозначения
"-" — нет требований к данному уровню;
"+" — новые или дополнительные требования;
"=" — требования совпадают с требованиями предыдущего уровня.

Согласно п.3 «Контроль исходного состояния ПО» перечня требований
  • Контроль заключается в фиксации исходного состояния ПО и сравнении полученных результатов с приведенными в документации.
  • Результатами контроля исходного состояния ПО должны быть рассчитанные уникальные значения контрольных сумм загрузочных модулей и исходных текстов программ, входящих в состав ПО.
  • Контрольные суммы должны рассчитываться для каждого файла, входящего в состав ПО.
Ага, отлично, контрольные суммы всех файлов программы должны зафиксированы в документации. Такое бы прокатило для прошивки криптомаршрутизатора (в общем там так и делается), но уж никак не для антивируса! Даже если не будем брать во внимание непосредственно программные модули, то базы сигнатур (между прочим, «входящие в состав ПО») обновляются фактически ежечасно. О каком контроле состояния ПО может идти речь?

На данный момент, ФСТЭК сертифицированы продукты нескольких антивирусных компаний:
  • ESET (4 уровень отсутствия НДВ);
  • Dr.Web (2 и 3 уровень);
  • Лаборатория Касперского (3 уровень);
  • VBA32 (4 уровень).

Например


Для примера возьмем Антивирус Касперского (просто пример), они очень гордятся своими сертификатами ФСТЭК, не упуская случая козырнуть ими перед клиентами.

Сертификат соответствия (№1384) на «программное изделие „Антивирус Касперского 6.0 для Windows Workstations“ выдан еще в 2007 году, потом продлен до 2013, за это время ЛК выпустила 4(!) больших обновления (MP) для него, а сертификат тот же! Это значит, что никто не проверял продукт, только потому, что не сменилась циферка мажорной версии… И это уже не говоря о ежедневном обновлении баз сигнатур.



В сертификате нет контрольных сумм. Логично, а зачем они? При первом же обновлении большая часть файлов просто изменится. Конечно, данная бумаженция отлично прикрывает пятые точки начальников IT-отделов, но неужели те, кто выдает такие вещи не понимают всей бредовости ситуации..?



А вот тут, в сертификате соответствия от ФСБ, они есть, но какой же в них смысл? Лишь проверить дистрибутив перед установкой.

И что же в итоге?


У Вас есть куча бумажек на средство защиты, но:

 1. Вам никто не гарантирует отсутствие случайных (якобы) ошибок в коде, в том числе и критических, которые могут быть использованы для полной компрометации системы. По опыту использования того же Антивируса Касперского 6.0, могу сказать, что ошибок оставшихся после всех сертификаций просто громадное количество (ну, у других продуктов по-меньше:). А реально ли доказать, например, умышленность оставленной дыры типа „Buffer Overflow“? Едва ли…

 2. Благодаря продвинутым системам обновления и лечения новых угроз, практический любой современный антивирус может выполнять произвольные действия (т.н. скрипты лечения) по комманде из центра обновления. Что мешает отдать комманду найти на компьютере определенные файлы, закарантинить их, и потом, в полном соответствии со всеми пользовательскими соглашиями, передать их „на исследование аналитикам вирусной лаборатории“? А что такого? Ну бывает, мы посчитали эти файлы вредоносными и, заботясь о Вашей безопастности, провели их анализ. Исключительно ради Вашего блага! Спите спокойно, в Ваших секретных документах вредоносных макросов не обнаружено, а тому аналитику мы выкололи глаза и отрезали язык ;)

Выводы


Существующие методики контроля отсутствия недекларированных возможностей в таких программных продуктах как средства защиты информации от динамичных угроз безнадежно устарели и не могут гарантировать вообще ничего. Да и вообще, возможность надежно держать в узде такого рода системы представляется сомнительной.
Сертификат спасет вас только от проверки регуляторов, но никак не от каких-либо угроз. Ну, это вполне логично для нашей страны, к сожалению...p class=
Tags:
Hubs:
+36
Comments 64
Comments Comments 64

Articles