Типичные ошибки при проведении ОКР

Обобщая многолетний опыт сертификации изделий по требованиям безопасности информации, сотрудниками испытательной лаборатории описывается перечень типичных ошибок, допускаемых при проведении ОКР, в том числе этапа сертификации по требованиям безопасности информации.

1. Отсутствие действующих сертификатов соответствия требованиям безопасности информации на составные компоненты изделия

Поскольку на этапе выбора и обоснования технических решений должен проводиться анализ действующих сертификатов соответствия на заимствованные компоненты, планируемые к использованию в составе изделия, разработчику необходимо учитывать следующие:

  1. А) разработчик заявляет на сертификацию изделие в целом, поэтому разработчик и будет нести ответственность за изделие в целом, в том числе и за составные компоненты, которые могут быть заимствованными. Требования о наличии сертификатов на заимствованные компоненты или о наличии документации на заимствованные компоненты в объеме, достаточном для проведения сертификационных испытаний, испытательная лаборатория будет предъявлять к Заявителю сертификационных испытаний – главному конструктору составного изделия. В этом случае целесообразно уже на этапе проектирования озадачиться тем, кто и как будет предъявлять заимствованные составные компоненты (изделия) на сертификацию. Если на заимствованные компоненты имеются сертификаты соответствия требованиям безопасности информации, то следует убедиться, что сертифицированные заимствованные изделия (компоненты) по своим характеристикам безопасности информации могут использоваться в составе целого изделия, с учетом его характеристик безопасности информации. Например, если изделие должно обрабатывать информацию ограниченного доступа, имеющую гриф «совершенно секретно», то и сертификат соответствия на заимствованное изделие также должен подтверждать, что заимствованное изделие может использоваться для обработки информации ограниченного доступа, имеющей гриф «совершенно секретно». При этом условия и ограничения эксплуатации заимствованного изделия должны быть допустимыми для условий и ограничений эксплуатации составного изделия. Другим важным фактором является срок действия сертификата соответствия на заимствованное изделие. Срок действия сертификата должен быть таковым, что планируемые сертификационные испытания составного изделия должны завершиться ранее, чем завершится срок действия сертификата на заимствованное изделие. В противном случае необходимо проведение инспекционного контроля заимствованного изделия с целью продления срока действия его сертификата соответствия требованиям безопасности информации.
  2. Б) если ТТЗ на ОКР устанавливает требования к взаимодействию с другими изделиями (автоматизированными системами), через коммутационное или иное оборудование, исторически применяемое для данных целей, но не имеющее сертификата соответствия требованиям безопасности информации, разработчику (главному конструктору) необходимо у Заказчика согласовать отдельным документом применение подобного оборудования. Только утверждающая подпись Заказчика на документе, согласующем применение оборудования, не имеющего сертификат соответствия, позволит испытательной лаборатории корректно закрыть вопрос о применении данного оборудования без сертификата.
  3. В) у разработчика (Заявителя сертификационных испытаний) в обязательном порядке должны иметься копии сертификатов соответствия на составные (заимствованные) изделия. Поскольку испытательная лаборатория только по тексту сертификата соответствия может увидеть перечень документов, содержащих условия и ограничения применения сертифицированного заимствованного изделия, то одного указания сведений о сертификате, например в формуляре, на заимствованное изделие недостаточно. В этом случае одного указания сведений о сертификате, например в формуляре, на заимствованное изделие является недостаточным. При этом если в сертификате соответствия указаны документы, содержащие условия и ограничения заимствованного изделия, то данные документы должны быть представлены испытательной лаборатории для проведения сертификационных испытаний.

2. Отсутствие документации на изделие в объеме требований системы сертификации

Согласно действующим нормативным документам, при выполнении ОКР Исполнитель утверждает у Заказчика перечень рабочей конструкторской и эксплуатационной документации, выпускаемой в рамках ОКР. Однако если ТТЗ на ОКР задается последующая сертификация изделия на соответствие требованиям безопасности информации, главному конструктору необходимо учесть следующее:

  1. А) для сертификации изделия требуются отдельные документы, наличие которых устанавливается положениями ГОСТ и иных нормативных документов в области сертификации и защиты информации, которые могут быть не указаны в перечне, согласованном Заказчиком;
  2. Б) разрабатывать отдельные документы или дополнять необходимыми сведениями имеющиеся все равно придется, поскольку часть требований безопасности является организационной и требует явного указания в виде условий и ограничений эксплуатации в документации на изделие.

Если последующая сертификация изделия планируется на соответствие руководящему документу «Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от несанкционированного доступа к информации» (Гостехкомиссия России, 1992 г.), то в указанном руководящем документе требования к перечню и содержанию конструкторской и эксплуатационной документации в части отражения вопросов безопасности информации заданы явно. Если сертификация изделия планируется на соответствие руководящему документу «Автоматизированные системы. Защита от НСД к информации. Классификация автоматизированных систем и требования по защите информации» (Гостехкомиссия России, 1992 г.), то требования к перечню и содержанию конструкторской и эксплуатационной документации в части отражения вопросов безопасности информации устанавливаются ГОСТ Р 50739-95 «Средства вычислительной техники. Защита от несанкционированного доступа к информации. Общие технические требования».

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

Программные документы «Описание программы», «Описание применения», «Пояснительная записка», разрабатываемые в соответствии с требованиями ЕСПД, могут выпускаться на комплекс программного обеспечения в целом. При этом документация на компоненты (функциональные программы) из состава комплекса программного обеспечения должна содержать общее описание их функционирования, информационного взаимодействия компонентов с другими компонентами комплекса программного обеспечения, описание входных и выходных данных. Либо перечисленные сведения для каждого компонента приводятся в документации на комплекс программного обеспечения.

Необходимость разработки «Пояснительной записки» обуславливается тем, что в соответствии с ГОСТ 19.404-79 указанный документ должен содержать алгоритмы (блок-схемы) функционирования программного обеспечения, требуемые для статического анализа программного обеспечения при выполнении контроля недекларированных возможностей, выполняемого в рамках сертификационных испытаний. Если блок-схемы (алгоритмы) работы программного обеспечения представлены в пояснительной записке этапа проектирования ОКР, то испытательная лаборатория использует пояснительную записку на ОКР, что отражается в акте отбора образца изделия для проведения сертификационных испытаний в перечне предъявляемой документации.

Существует возможность отражения в протоколе сертификационных испытаний факта того, что все требуемые ЕСПД сведения, подлежащие отражению в документах «Описание программы» и «Описание применения» разработчиком изделия в составе выпущенной конструкторской и программной документации присутствуют, хотя сами указанные документы не разрабатывались. Но в этом случае для каждого требования ЕСПД приводится ссылка на конкретный раздел и пункт раздела другого документа, содержащего необходимые сведения.

3. Отсутствие формуляра на изделие

Если подана Заявка на сертификацию изделия, то испытательной лаборатории в обязательном порядке должен быть предъявлен формуляр (паспорт), соответствующий объекту заявки. Отсутствие формуляра (паспорта) на изделие в целом, предъявление формуляра (паспорта) только на составные изделия, является причиной отрицательного результата сертификационных испытаний. Поскольку объект испытаний для проведения сертификации испытательной лабораторией принимается только в соответствии с подобным документом, из которого определяется состав и заводские номера составных изделий, дата изготовления и приемки изделия. Для проведения испытаний предъявляется формуляр (паспорт), оформленный в соответствии с требованиями ЕСКД (ЕСПД для программного изделия), с заполненным полем «Отметки об учете» титульного листа.

Количество однотипных составных изделий, устанавливаемых на стенде сертификационных испытаний, определяется испытательной лабораторией исходя из целей и задач сертификации. Например, если в состав изделия входит 5 АРМ должностного лица, у которых одинаковая техническая и программная части, для сертификационных испытаний на стенде в некоторых случаях может устанавливаться одно подобное изделие. О чем делается соответствующее пояснение в акте отбора образца.

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

4. Отсутствие документированных сведений для оформления Акта идентификации среды разработки

Не смотря на наличие требований ГОСТов к проведению ОКР, в том числе о наличии руководящих указаний по конструированию, идентификация среды разработки сертифицируемого программного обеспечения осуществляется специалистами испытательной лаборатории методом переписывания всего того, что находится на рабочем месте разработчика программного обеспечения.

Руководящие указания по конструированию должны определять перечень допустимых технических средств, на которых ведется разработка программного обеспечения, а также версию операционной системы, средств разработки, перечень библиотечных модулей.

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

Если имеются объективные причины применения не сертифицированных по требованиям безопасности информации средств разработки программного обеспечения, данный факт должен быть согласован с Заказчиком, о чем должен существовать соответствующий документ, подписанный Заказчиком.

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

В акте идентификации среды разработки также приводятся сведения о документах, в соответствии с которыми выполняется компиляция программного обеспечения (такие документы также указываются в акте отбора образца изделия для проведения сертификационных испытаний в разделе «Перечень предъявляемой документации»). Также указываются документы, содержащие значения контрольных сумм файлов исходных текстов и исполняемых модулей сертифицируемого программного обеспечения. Кроме того, указывается перечень исполняемых и дополнительных файлов из состава каждого сертифицируемого программного изделия.

5. Последовательная сертификация составных изделий, завершающаяся сертификацией изделия в целом

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

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

6. Занижение реальной стоимости работ на этапе сертификационных испытаний

Этап сертификационных испытаний включает как работы испытательной лаборатории, так и работы Заявителя (разработчика изделия).

Поскольку лаборатории сегодня самостоятельно в соответствии с действующим законодательством определяют трудоемкость и стоимость работ, не пытайтесь понять, что и сколько стоит. Лучше руководствуйтесь правилом – цена работ по проведению сертификационных испытаний по данным мировой практики составляет от 10 до 20 процентов от стоимости разработки изделия.

При расчете стоимости этапа сертификационных испытаний не забудьте об устранении Вами замечаний, выявленных в процессе сертификационных испытаний, которые могут приводить не только к корректировке РКД и эксплуатационной документации, но и к разработке новой версии программного обеспечения. Вот тут и появляется масса нюансов.

Нюанс один. Программы и методики государственных испытаний не согласованы с 8 управлением ГШ ВС РФ. Как минимум, Вы можете узнать для себя много нового в части существования ряда приказов Министра обороны, касающихся вопросов информационной безопасности, о которых Вы даже не предполагали, но, исходя из положений которых, будут разрабатываться методики сертификационных испытаний.

Нюанс два. Например, явное требование ТТЗ о соответствии определенному классу защищенности воспринималось Вами как нечто, не заслуживающее внимания, поскольку на этапе сертификации придут знающие ребята из испытательной лаборатории и порекомендуют необходимое средство защиты, которое решит все ваши проблемы сразу. Чудес не бывает, если сертификационные испытания выполняются честно, то ни одно из существующих средств защиты не позволит выполнить требования в целом, поскольку ориентированы только на уровень операционной системы, а уровня функционального программного обеспечения даже не касаются. Если в изделии используется система управления базой данных, то проблема становится еще больше. Например, СУБД «Линтер ВС» содержит более 140 рекомендаций главному конструктору, который должен их учесть при разработке собственного изделия. Подобные рекомендации имеются у операционной системы МСВС 3.0.

Нюанс три. При проведении государственных испытаний по отдельной методике проводились испытания соответствия требованиям защищенности информации от несанкционированного доступа. Прежде всего, ознакомьтесь с требованиями, указанными в руководящем документе для заданного ТТЗ класса защищенности, и ответьте на вопрос: все ли требования подлежали проверке в рамках проведения государственных испытаний. Если все требования учтены, обратите еще раз внимание на РКД и эксплуатационную документацию. Если Вы сможете ответить себе убедительно на вопрос: все ли требуемые руководящим документом описания КСЗИ НСД отражены в документации, смело снижайте стоимость сертификационных испытаний.