Обобщая многолетний опыт сертификации изделий по требованиям безопасности информации, сотрудниками испытательной лаборатории описывается перечень типичных ошибок, допускаемых при проведении ОКР, в том числе этапа сертификации по требованиям безопасности информации.
Поскольку на этапе выбора и обоснования технических решений должен проводиться анализ действующих сертификатов соответствия на заимствованные компоненты, планируемые к использованию в составе изделия, разработчику необходимо учитывать следующие:
Согласно действующим нормативным документам, при выполнении ОКР Исполнитель утверждает у Заказчика перечень рабочей конструкторской и эксплуатационной документации, выпускаемой в рамках ОКР. Однако если ТТЗ на ОКР задается последующая сертификация изделия на соответствие требованиям безопасности информации, главному конструктору необходимо учесть следующее:
Если последующая сертификация изделия планируется на соответствие руководящему документу «Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от несанкционированного доступа к информации» (Гостехкомиссия России, 1992 г.), то в указанном руководящем документе требования к перечню и содержанию конструкторской и эксплуатационной документации в части отражения вопросов безопасности информации заданы явно. Если сертификация изделия планируется на соответствие руководящему документу «Автоматизированные системы. Защита от НСД к информации. Классификация автоматизированных систем и требования по защите информации» (Гостехкомиссия России, 1992 г.), то требования к перечню и содержанию конструкторской и эксплуатационной документации в части отражения вопросов безопасности информации устанавливаются ГОСТ Р 50739-95 «Средства вычислительной техники. Защита от несанкционированного доступа к информации. Общие технические требования».
Поскольку требования в указанных документах к перечню и содержанию конструкторской и эксплуатационной документации идентичны, остановимся на некоторых положениях требований.
Программные документы «Описание программы», «Описание применения», «Пояснительная записка», разрабатываемые в соответствии с требованиями ЕСПД, могут выпускаться на комплекс программного обеспечения в целом. При этом документация на компоненты (функциональные программы) из состава комплекса программного обеспечения должна содержать общее описание их функционирования, информационного взаимодействия компонентов с другими компонентами комплекса программного обеспечения, описание входных и выходных данных. Либо перечисленные сведения для каждого компонента приводятся в документации на комплекс программного обеспечения.
Необходимость разработки «Пояснительной записки» обуславливается тем, что в соответствии с ГОСТ 19.404-79 указанный документ должен содержать алгоритмы (блок-схемы) функционирования программного обеспечения, требуемые для статического анализа программного обеспечения при выполнении контроля недекларированных возможностей, выполняемого в рамках сертификационных испытаний. Если блок-схемы (алгоритмы) работы программного обеспечения представлены в пояснительной записке этапа проектирования ОКР, то испытательная лаборатория использует пояснительную записку на ОКР, что отражается в акте отбора образца изделия для проведения сертификационных испытаний в перечне предъявляемой документации.
Существует возможность отражения в протоколе сертификационных испытаний факта того, что все требуемые ЕСПД сведения, подлежащие отражению в документах «Описание программы» и «Описание применения» разработчиком изделия в составе выпущенной конструкторской и программной документации присутствуют, хотя сами указанные документы не разрабатывались. Но в этом случае для каждого требования ЕСПД приводится ссылка на конкретный раздел и пункт раздела другого документа, содержащего необходимые сведения.
Если подана Заявка на сертификацию изделия, то испытательной лаборатории в обязательном порядке должен быть предъявлен формуляр (паспорт), соответствующий объекту заявки. Отсутствие формуляра (паспорта) на изделие в целом, предъявление формуляра (паспорта) только на составные изделия, является причиной отрицательного результата сертификационных испытаний. Поскольку объект испытаний для проведения сертификации испытательной лабораторией принимается только в соответствии с подобным документом, из которого определяется состав и заводские номера составных изделий, дата изготовления и приемки изделия. Для проведения испытаний предъявляется формуляр (паспорт), оформленный в соответствии с требованиями ЕСКД (ЕСПД для программного изделия), с заполненным полем «Отметки об учете» титульного листа.
Количество однотипных составных изделий, устанавливаемых на стенде сертификационных испытаний, определяется испытательной лабораторией исходя из целей и задач сертификации. Например, если в состав изделия входит 5 АРМ должностного лица, у которых одинаковая техническая и программная части, для сертификационных испытаний на стенде в некоторых случаях может устанавливаться одно подобное изделие. О чем делается соответствующее пояснение в акте отбора образца.
В формуляре (паспорте) изделия в разделе «Особые отметки» должны содержаться сведения о значениях контрольных сумм и размерах файлов программного обеспечения (исполняемых модулей и дополнительных файлов). Поскольку формуляр должен в последующем при эксплуатации храниться на рабочем месте и использоваться, в том числе, как документ, содержащий эталонные значения контрольных сумм при осуществлении контроля целостности и контроля модификации.
Не смотря на наличие требований ГОСТов к проведению ОКР, в том числе о наличии руководящих указаний по конструированию, идентификация среды разработки сертифицируемого программного обеспечения осуществляется специалистами испытательной лаборатории методом переписывания всего того, что находится на рабочем месте разработчика программного обеспечения.
Руководящие указания по конструированию должны определять перечень допустимых технических средств, на которых ведется разработка программного обеспечения, а также версию операционной системы, средств разработки, перечень библиотечных модулей.
Ситуация, когда разработчиками ведется разработка на загруженном из Интернета компиляторе с применением загруженных из Интернета библиотек, является неприемлемой. Разработка программного обеспечения должна осуществляться на сертифицированных по требованиям безопасности информации средствах разработки, которые в текущий момент имеются в наличии.
Если имеются объективные причины применения не сертифицированных по требованиям безопасности информации средств разработки программного обеспечения, данный факт должен быть согласован с Заказчиком, о чем должен существовать соответствующий документ, подписанный Заказчиком.
Если для компиляции программного обеспечения сперва требуется осуществить компиляцию самого компилятора, то подобная ситуация также является неприемлемой. Поскольку инструментальные средства контроля недекларированных возможностей поддерживают последнюю сертифицированную версию компилятора и библиотек. Если из загруженных из Интернета исходных текстов компилятора самой последней версии мы собираем средствами сертифицированного компилятора исполняемые модули, то у испытательной лаборатории возникает проблема доработки своего программного обеспечения анализа недекларированных возможностей программного обеспечения. Поскольку более поздняя версия компилятора поддерживает, как правило, дополнительные синтаксические конструкции, используемые разработчиком при написании исходных текстов собственного программного обеспечения. Хотя ситуация не является неразрешимой, если имеются финансы для выполнения дополнительных работ.
В акте идентификации среды разработки также приводятся сведения о документах, в соответствии с которыми выполняется компиляция программного обеспечения (такие документы также указываются в акте отбора образца изделия для проведения сертификационных испытаний в разделе «Перечень предъявляемой документации»). Также указываются документы, содержащие значения контрольных сумм файлов исходных текстов и исполняемых модулей сертифицируемого программного обеспечения. Кроме того, указывается перечень исполняемых и дополнительных файлов из состава каждого сертифицируемого программного изделия.
Сертификация изделия в целом предполагает и сертификацию составных изделий. Поэтому, Заявка на сертификацию изделия в целом при выписке Решения на сертификацию изделия в целом может завершиться выдачей ряда сертификатов, в том числе и на составные изделия (если это реально требуется и отдельно оговаривается в техническом заключении испытательной лаборатории по результатам сертификационных испытаний). Поэтому, наличие сертифицированных составных изделий при подаче Заявки на сертификацию изделия в целом является не обязательным условием.
Сертификация составных частей изделия в одной лаборатории при последующей сертификации изделия в целом в другой лаборатории потребует гораздо больших, в том числе моральных, затрат.
Этап сертификационных испытаний включает как работы испытательной лаборатории, так и работы Заявителя (разработчика изделия).
Поскольку лаборатории сегодня самостоятельно в соответствии с действующим законодательством определяют трудоемкость и стоимость работ, не пытайтесь понять, что и сколько стоит. Лучше руководствуйтесь правилом – цена работ по проведению сертификационных испытаний по данным мировой практики составляет от 10 до 20 процентов от стоимости разработки изделия.
При расчете стоимости этапа сертификационных испытаний не забудьте об устранении Вами замечаний, выявленных в процессе сертификационных испытаний, которые могут приводить не только к корректировке РКД и эксплуатационной документации, но и к разработке новой версии программного обеспечения. Вот тут и появляется масса нюансов.
Нюанс один. Программы и методики государственных испытаний не согласованы с 8 управлением ГШ ВС РФ. Как минимум, Вы можете узнать для себя много нового в части существования ряда приказов Министра обороны, касающихся вопросов информационной безопасности, о которых Вы даже не предполагали, но, исходя из положений которых, будут разрабатываться методики сертификационных испытаний.
Нюанс два. Например, явное требование ТТЗ о соответствии определенному классу защищенности воспринималось Вами как нечто, не заслуживающее внимания, поскольку на этапе сертификации придут знающие ребята из испытательной лаборатории и порекомендуют необходимое средство защиты, которое решит все ваши проблемы сразу. Чудес не бывает, если сертификационные испытания выполняются честно, то ни одно из существующих средств защиты не позволит выполнить требования в целом, поскольку ориентированы только на уровень операционной системы, а уровня функционального программного обеспечения даже не касаются. Если в изделии используется система управления базой данных, то проблема становится еще больше. Например, СУБД «Линтер ВС» содержит более 140 рекомендаций главному конструктору, который должен их учесть при разработке собственного изделия. Подобные рекомендации имеются у операционной системы МСВС 3.0.
Нюанс три. При проведении государственных испытаний по отдельной методике проводились испытания соответствия требованиям защищенности информации от несанкционированного доступа. Прежде всего, ознакомьтесь с требованиями, указанными в руководящем документе для заданного ТТЗ класса защищенности, и ответьте на вопрос: все ли требования подлежали проверке в рамках проведения государственных испытаний. Если все требования учтены, обратите еще раз внимание на РКД и эксплуатационную документацию. Если Вы сможете ответить себе убедительно на вопрос: все ли требуемые руководящим документом описания КСЗИ НСД отражены в документации, смело снижайте стоимость сертификационных испытаний.
