Бить будут не по сертификату

infowatch — 03.10.2010 На днях мы с вами обсуждали применение старых методов регулирования для современных ИТ. Понятно, что они не годятся. Но что взамен? Жизнь сама предлагает альтернативы.

Давайте поставим себя на место руководителя небольшой страны. Необходимо обеспечить защиту государства от угроз, связанных с программным обеспечением. Есть инструмент – сертификация самого ПО и его разработчиков на соответствие каким-либо стандартам или руководящим документам. Какие угрозы мы сможем уменьшить при помощи такой сертификации?

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

Почему нельзя так делать? Этот подход действительно не работает. Доказано на практике Во-первых, в силу особенностей ПО, просто невозможно проверить всю логику исчерпывающим образом. Слишком велико число вариантов. Во-вторых, в случае, если НДВ всё-таки сработает в сертифицированной программе, сертификатор разведёт руками и скажет: "Ну, не смогла я..." И что с него возьмёшь? Деньги брать бесполезно, поскольку нет у него столько денег, чтобы покрыть все убытки. Ведь НДВ, скорее всего, будет задействована один раз, в критической ситуации, например, во время войны. Если каверза противника удалась, и ситуация разрешилась не в пользу этого государства, то деньги уже не помогут.

Давайте вспомним, сколько разного ПО было сертифицировано на НДВ. И в каждой сертифицированной программе (как и в каждой другой) потом находили ошибки и уязвимости. И находят. И ещё будут находить. А при сертификации их не обнаружили. Чем уязвимость отличается от намеренной закладки? Вопрос риторический...

Теперь попробуем применить против той же угрозы иной метод – сертификацию производителя. Каким требованиям должна удовлетворять софтодевелоперская фирма, чтоб не допустить внедрения "чёрного хода" или намеренной критической ошибки? Квалификация сотрудников, их моральная устойчивость, партийность, гражданство, место жительства, знание иностранных языков – всё это не гарантирует отсутствия инсайдеров. Разве что, проверить весь персонал на детекторе лжи, впрочем, от последующей вербовки это не защитит. Другое дело – наличие процедур многократной проверки кода несколькими людьми, заинтересованными в поиске ошибок/уязвимостей/закладок и не заинтересованными в скорейшем выпуске продукта. Есть у нас такой стандарт? Стандарта нет, а вот практика есть. Такие проверки проходит свободное ПО.

Осталось лишь обеспечить, чтобы проверки были сплошными, а не выборочными, как сейчас. И добавить заинтересованности.

Новая сертификация на НДВ, которая действительно снижает вероятность дырок, может выглядеть так. Предположим, государству нужен "свой" программный продукт, например, СУБД. Для начала берутся все СУБД с открытым кодом, затем по требованиям функциональности из них отбирается кандидат на сертификацию. И объявляется открытый конкурс. Каждый, указавший ошибку, уязвимость, слабость, способ взлома или иную подозрительную особенность кода, получает премию. Скупиться не надо, надо заинтересовать самых лучших. Если через полгода число найденных критических уязвимостей не превышает определённого "порога качества", продукт объявляется сертифицированным, а премии уменьшаются вдвое.

Один лишь недостаток вижу. При таком методе сертификатор не имеет коррупционных возможностей и не может надувать щёки. Да и не с кого ему будет требовать взяток и знаков уважения.

Оставить комментарий

Популярные посты:

• Ранее
• Архив