Средства контроля (анализа) исходных текстов программного обеспечения - Форум по вопросам информационной безопасности

Добрый день!

Вопрос в связи с грядущими изменениями в законодательство о лицензировании.

По новым требованиям, предъявляемым, например, к лицензии ТЗКИ, необходимо:

_______________
наличие принадлежащего соискателю лицензии на праве собственности или ином законном основании оборудования, необходимого для выполнения работ и (или) оказания услуг, предусмотренных пунктом 4 настоящего Положения, в соответствии с определяемым Федеральной службой по техническому и экспортному контролю перечнем, в том числе:

измерительных приборов, прошедших в установленном законодательством Российской Федерации порядке метрологическую поверку (калибровку);

программных (программно-технических) средств, включая средства контроля эффективности защиты информации, сертифицированных по требованиям безопасности информации, а также средств контроля (анализа) исходных текстов программного обеспечения;
_______________

Касательно последнего, а именно средств контроля (анализа) исходных текстов программного обеспечения.

1) Правильно ли я понимаю, что необходимо иметь сертифицированные ФСТЭК средства контроля (анализа) исходных текстов программного обеспечения?

2) На текущий момент в продаже только 3 (три) сертифицированных средства:
- АИСТ-С
- АК-ВС 1.0
- АК-ВС 2.0
Т.к. это ПО предназначено в основном для исходных кодов написанных на языках программирования C, C++, Java, то вопрос такой: если в рамках лицензионной деятельности необходимо анализировать исходные тексты, написанные на языках программирования, отличных от C, C++, Java, то как быть?

3) Будет ли регулятор (ФСТЭК) при проверках обращать внимание не только на наличие средства контроля (анализа) исходных текстов ПО, но и на то, как это ПО используется?
Особенно этот вопрос актуален в отношении лицензии на деятельность по созданию/разработке СЗИ. Например, если в рамках лицензионной деятельности разрабатывается на Pascal (например) программное СЗИ и использовать сертифицированное средство контроля (анализа) исходных текстов ПО не представляется возможным.

1. Да

2. Для веб-интерфейсов к СЗИ есть еще PT Application Inspector (заканчивается процесс сертификации)

3. Все намного интереснее :) Лицензию вы получите с любым набором сертифицированных средств контроля. Проблемы начнутся при сертификации разработанных вами СЗИ.

Есть ГОСТ Р 56939-2016, который описывает, что вы должны делать в части контролч исходников. При сертификации СЗИ вы должны будете показать, как именно вы обеспечиваете такой контроль сертифицированными средствами контроля. Если окажется, что ваше СЗИ написано на Паскале и вы не можете обеспечить контроль исходных текстов, сертификат вы не получите.

У регулятора очень простая позиция: если разработчик не может проконтролировать (или доказать, что контролирует) отсутствие уязвимостей, которые его собственные программисты вносят в его собственный продукт, то такому продукту нечего делать на рынке СЗИ.

"Если окажется, что ваше СЗИ написано на Паскале и вы не можете обеспечить контроль исходных текстов, сертификат вы не получите."

Как же выходить из этой потенциально возможной ситуации? Передавать свою разработку самой ФСТЭК для последующего контроля исходных текстов, если такое вообще допустимо/возможно?

> Как же выходить из этой потенциально возможной ситуации? Передавать свою разработку самой ФСТЭК для последующего контроля исходных текстов, если такое вообще допустимо/возможно?

Вы, наверное, не поняли. Вариантов ровно два. Или разработчик использует средства разработки, для которых он может продемонстрировать контроль качества кода доверенными средствами, или он не работает на рынке, в котором требуется сертификация СЗИ. Никаких других вариантов не предлагается. Это - проблема разработчика СЗИ, а не регулятора.

Переход к такой жесткой схеме произойдет не завтра и не через год, но работа в этом направлении ведется.

Вывод: писать only for *nix и на C, C++. Вестимо, к этому все и идет. Как же Астра и Роса много шумихи наделали (бедные-бедные Debian и Mandriva)...

> Вывод: писать only for *nix и на C, C++
+ С#, Java, PHP, Python, ABAP и т. п. Платформа как раз не принципиальна, например, динамический анализ софта для тех же андроидов делается в режиме эмуляции платформы.

Нормальная разработка методов только статического анализа одного языка - это серьезная научно-исследовательская работа на несколько десятков человеколет (т.е. делается за год-два, но это работа для пары десятков специалистов разного профиля). Плюс динамический анализ - тоже нетривиальная задача. Поэтому прежде, чем вложиться в анализ определенного языка, вендор внимательно смотрит, а много ли потребителей на анализ этого языка. Ну вот конкретно с Паскалем особого ажиотажа не наблюдается.

to malotavr
Тут была насмешка над ограничениями существующих анализаторов, приведенных топикстартером. А тот же GNU/Linux (и на его базе отечественные дистрибутивы-форки) нативно как раз gcc и g++ поддерживает. С Java, вроде, не так, ибо Oracle. Про остальные ЯП вообще молчу, ибо "недопустимы" на текущий момент, как выяснилось...
Ждем СЗИ НСД на bash/sh! +100500 скриптов гарантии защищенности, ага :)

> Тут была насмешка над ограничениями существующих анализаторов, приведенных топикстартером.

Это понятно :) Но новые разрабатываются, под какие языки - я перечислил :)
В первую очередь - самые популярные языки для опенсорсных проектов и для фронтендов,

Как я понял речь то идет о контроле (анализе) исходных текстов программного обеспечения. Именно что программного обеспечения, а не СЗИ.
Вот только не понятно, как же запросить исходники ПО или еще лучше исходники ОС, для анализа?
И что же делать, ведь изменения вступят в силу уже через полтора месяца! Все кто не хочет потерять лицензию необходимо закупать, заведомо бесполезные анализаторы?
Может кто уже запрашивал или уточнял у ФСТЭКа?

Да, речь идет о постановлении правительства от 15.06.2016г. № 541 «О внесении изменений в некоторые акты правительства Российской Федерации по вопросам лицензирования отдельных видов деятельности».