Третьей темой конференции ФСТЭК (после КИИ и сертификации) стало доверие или, согласно ГОСТ 15408, основание для уверенности в том, что объект оценки отвечает конкретным функциональным требованиям безопасности. О том, какие усилия предпринимает ФСТЭК для этого, рассказал начальник отдела организации и проведения работ по сертификации средств защиты информации и аттестации объектов информатизации Костенко Михаил Евгеньевич.
У регулятора достаточно много различных документов, говорящих о доверии, - от профилей защиты информации и РД на НДВ до ГОСТов 54581/2/3, 15408, 18045 и 56939. Все они направлены на то, чтобы удостовериться не только в функциональных возможностях того или иного решения, но и в том, что реализованы они качественно, а разработчик в состоянии поддерживать свое творение в течение всего жизненного цикла продукта.
Поэтому среди элементов доверия, на которые обращает внимания ФСТЭК, есть и действия, которые должны выполняться разработчиком, и свидетельства, доказывающие их исполнение, и действия самого оценщика.
Правильная оценка уровня доверия дает уверенность в том, что функциональные требования безопасности реализованы корректно. Поэтому во всех последних профилях защиты ФСТЭК наращивает требования по обеспечению доверия. Начав с РД на системы обнаружения вторжений и антивирусы эти требования по нарастающей попадают в РД на DLP, межсетевые экраны, операционные системы, СУБД и др.
Однако достаточно сложно становится поддерживать множество разрозненных документов, в которых еще и разные наборы требований к доверию. Поэтому сейчас ФСТЭК завершает работы по унификации соответствующих требований, которые можно было бы:
Соответственно сейчас на подходе у ФСТЭК находится два документа. Первый - давно обещанная методика поиска уязвимостей и недекларированных возможностей. От старого РД по НДВ будут отказываться - по сути он и так сейчас используется только в тех случаях, когда на средство защиты нет профиля, а требования сертификации присутствует. Учитывая, что требования по отсутствию НДВ уже включены во все профили защиты, то необходимость в таком РД постепенно исчезает. А вот методика поиска НДВ и уязвимостей нужна.
Про методику рассказ подхватил начальник лаборатории ГНИИ ПТЗИ Алексей Сердечный, который подробно описал не только структуру нового документа:
но и методы выявления уязвимостей и недекларированных возможностей, а также их применимость в тех или иных ситуациях, в том числе и учитывая потенциал нарушителя.
Опираясь на методику по поиску уязвимостей, ГОСТы по уязвимостям, по безопасной разработке, требования по обновлению, ФСТЭК готовит второй документ "Требования по безопасности информации, устанавливающие уровни доверия к программному обеспчеению и оборудованию, используемому в государственных органах и организациях" (обратите внимание, и к оборудованию).
В новых документах наконец-то найдут свое отражение требования, которые уже требуются при сертификации, например, межсетевых экранов, и которые могут представлять некоторую проблему для разработчиков, использующих не свое железо.
Кроме этого, некоторые требования вообще непонятно как выполнять, что отчасти и привело к снижению числа сертифицированных МСЭ, о чем я писал на прошлой неделе. Например, в случае наличия подсистемы Secure Boot или специальных ASIC (а это норма для иностранных аппаратных средств защиты), они предотвращают проверку этих подсистем или некоторых защищенных областей внутри них. Как выполнить существующие и формализуемые требования, не совсем понятно :-(
Вообще ФСТЭК стала больше уделять внимания именно аппаратной начинке сертифицируемых средств защиты, что тоже еще аукнется на первых порах. Испытательные лаборатории не знают многих навороченных штук, которые сегодня внедряются для повышения доверия к средствам защиты и контроля отсутствия вмешательства на этапах поставки и эксплуатации оборудования. При наличии формальных требованиях о верификации неверифицируемых в принципе компонентов (или доверять заявлениям вендора) будут возникать ситуации либо с невозможностью сертификации того или иного продукта, либо с обманом со стороны испытательной лаборатории, которая не захочет терять контракт на и так стагнирующем рынке сертификации.
В целом, надо признать, что ФСТЭК движется в правильном направлении с усилением требований к доверию и оценке соответствия средств защиты, с одним "но". Рынок отечественных решений по ИБ еще не готов к полноценному замещению всей номенклатуры средств защиты, которая представлена преимущественно иностранными вендорами, которые, в свою очередь, уже не могут выполнять все новые требования, которые начинает предъявлять регулятор. Вспоминая известное изречение вождя мирового пролетариата про условия возникновения революционной ситуации ("низы не могут, а верхи не хотят"), мы сейчас находимся в схожем положении - иностранцы не могут, а свои вендоры не хотят. Чем ответит потребитель?
ЗЫ. В заключение хотелось бы раскрыть цитату, вынесенную в заголовок заметки. Ее произнес Дмитрий Шевцов, когда рассказывал о том, как производится сегодня оценка доверия применительно к некоторым иностранным продуктам, производители которых допускают сотрудников испытательных лабораторий к исходному коду только в исподнем, чтобы те не унесли чужую интеллектуальную собственность.
У регулятора достаточно много различных документов, говорящих о доверии, - от профилей защиты информации и РД на НДВ до ГОСТов 54581/2/3, 15408, 18045 и 56939. Все они направлены на то, чтобы удостовериться не только в функциональных возможностях того или иного решения, но и в том, что реализованы они качественно, а разработчик в состоянии поддерживать свое творение в течение всего жизненного цикла продукта.
Поэтому среди элементов доверия, на которые обращает внимания ФСТЭК, есть и действия, которые должны выполняться разработчиком, и свидетельства, доказывающие их исполнение, и действия самого оценщика.
Правильная оценка уровня доверия дает уверенность в том, что функциональные требования безопасности реализованы корректно. Поэтому во всех последних профилях защиты ФСТЭК наращивает требования по обеспечению доверия. Начав с РД на системы обнаружения вторжений и антивирусы эти требования по нарастающей попадают в РД на DLP, межсетевые экраны, операционные системы, СУБД и др.
Однако достаточно сложно становится поддерживать множество разрозненных документов, в которых еще и разные наборы требований к доверию. Поэтому сейчас ФСТЭК завершает работы по унификации соответствующих требований, которые можно было бы:
- поместить в один документ
- использовать для всех типов средств защиты - существующих и планируемых.
Соответственно сейчас на подходе у ФСТЭК находится два документа. Первый - давно обещанная методика поиска уязвимостей и недекларированных возможностей. От старого РД по НДВ будут отказываться - по сути он и так сейчас используется только в тех случаях, когда на средство защиты нет профиля, а требования сертификации присутствует. Учитывая, что требования по отсутствию НДВ уже включены во все профили защиты, то необходимость в таком РД постепенно исчезает. А вот методика поиска НДВ и уязвимостей нужна.
Про методику рассказ подхватил начальник лаборатории ГНИИ ПТЗИ Алексей Сердечный, который подробно описал не только структуру нового документа:
но и методы выявления уязвимостей и недекларированных возможностей, а также их применимость в тех или иных ситуациях, в том числе и учитывая потенциал нарушителя.
Опираясь на методику по поиску уязвимостей, ГОСТы по уязвимостям, по безопасной разработке, требования по обновлению, ФСТЭК готовит второй документ "Требования по безопасности информации, устанавливающие уровни доверия к программному обеспчеению и оборудованию, используемому в государственных органах и организациях" (обратите внимание, и к оборудованию).
В новых документах наконец-то найдут свое отражение требования, которые уже требуются при сертификации, например, межсетевых экранов, и которые могут представлять некоторую проблему для разработчиков, использующих не свое железо.
Кроме этого, некоторые требования вообще непонятно как выполнять, что отчасти и привело к снижению числа сертифицированных МСЭ, о чем я писал на прошлой неделе. Например, в случае наличия подсистемы Secure Boot или специальных ASIC (а это норма для иностранных аппаратных средств защиты), они предотвращают проверку этих подсистем или некоторых защищенных областей внутри них. Как выполнить существующие и формализуемые требования, не совсем понятно :-(
Вообще ФСТЭК стала больше уделять внимания именно аппаратной начинке сертифицируемых средств защиты, что тоже еще аукнется на первых порах. Испытательные лаборатории не знают многих навороченных штук, которые сегодня внедряются для повышения доверия к средствам защиты и контроля отсутствия вмешательства на этапах поставки и эксплуатации оборудования. При наличии формальных требованиях о верификации неверифицируемых в принципе компонентов (или доверять заявлениям вендора) будут возникать ситуации либо с невозможностью сертификации того или иного продукта, либо с обманом со стороны испытательной лаборатории, которая не захочет терять контракт на и так стагнирующем рынке сертификации.
В целом, надо признать, что ФСТЭК движется в правильном направлении с усилением требований к доверию и оценке соответствия средств защиты, с одним "но". Рынок отечественных решений по ИБ еще не готов к полноценному замещению всей номенклатуры средств защиты, которая представлена преимущественно иностранными вендорами, которые, в свою очередь, уже не могут выполнять все новые требования, которые начинает предъявлять регулятор. Вспоминая известное изречение вождя мирового пролетариата про условия возникновения революционной ситуации ("низы не могут, а верхи не хотят"), мы сейчас находимся в схожем положении - иностранцы не могут, а свои вендоры не хотят. Чем ответит потребитель?
ЗЫ. В заключение хотелось бы раскрыть цитату, вынесенную в заголовок заметки. Ее произнес Дмитрий Шевцов, когда рассказывал о том, как производится сегодня оценка доверия применительно к некоторым иностранным продуктам, производители которых допускают сотрудников испытательных лабораторий к исходному коду только в исподнем, чтобы те не унесли чужую интеллектуальную собственность.
