Рейтинги Common Criteria, разработанные для АНБ, могут быть применены для тестирования соответствия коммерческих продуктов требуемому уровню безопасности.

Вашингтон, 1964 год. Недавно убит Джон Кеннеди. Разгорается война во Вьетнаме. Майкл Джекобс ищет работу. И вот, изучив каталог вакансий, подготовленный Агентством национальной безопасности США, он выбирает себе работу, которая приведет его в созданную затем организацию Communications Security Directorate. Ключи, коды, шифры и криптоанализ — вот чем ему приходилось заниматься ежедневно, попутно уделяя внимание вопросам лингвистики и телекоммуникаций. Но за все 37 проведенных в АНБ лет Джекобс мог видеть, как меняется суть его работы в свете перехода от жестко контролируемого и созданного самостоятельно кода к распределенным вычислениям и коммерческим продуктам.

Теперь, по словам Джекобса, его организация наполовину существует в коммерческом мире, а наполовину — в мире закрытых частных систем. И чтобы убедиться, что коммерческие продукты удовлетворяют требуемому уровню безопасности, АНБ пропускает их через специальные программы тестирования. Эти программы, Common Criteria Evaluation and Validation Scheme и Cryptographic Module Validation Program, — часть инициативы National Information Assurance Partnership, реализуемой агентством совместно с Национальным институтом стандартов и технологии, производителями и пользователями.

Прежде чем получить рейтинг безопасности в соответствии с Common Criteria, продукты должны пройти тщательное тестирование. Рейтинги разработаны в помощь АНБ, но ими могут руководствоваться и представители частного сектора. А поскольку стандарты тестирования имеют международный статус, покупателям продуктов, получивших эту отметку, намного проще развертывать их в различных странах мира.

Чем различается роль вычислительных систем в 60-х годах и сейчас? Наша история связана с развитием кодирования. Можно сказать, что она началась в годы Второй мировой войны. Ядро организации составили специалисты в области разведки и ученые, начавшие создавать вычислительные системы для государственных нужд. Мы не могли рассчитывать на коммерческие технологии, создавая криптографические системы, предназначенные для решения государственных задач. Мы даже разработали свою собственную систему передачи сообщений — Automatic Digital Network. Любая государственная организация, которой требовалось защитить свои коммуникации, обращалась к нам, а у нас уже была наготове стандартная брошюра о существующих устройствах шифрования, предназначенных для голосовой связи, телетайпов, радио, телефона. Мы были монополистами.

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

К чему привели изменения в АНБ? Когда мы были монополией, то могли себе позволить тратить время на то, чтобы поддерживать системы, разработанные в единственном экземпляре. Некоторые разработки продолжались по пять лет. Государственные системы служат по два-три десятилетия. Так что у нас было время на интеграцию и тщательное тестирование продукта. При проектировании защиты мы придерживались принципа предотвращения конкретных рисков. Теперь у нас есть среда, в которой все вопросы, связанные с рисками, решаются комплексно, поскольку сейчас мы не можем себе позволить такую роскошь, как бесконечный запас времени. Так что мы вынуждены подходить к решению проблем защиты более оперативно. Значительная часть нагрузки при этом перекладывается с разработчика на клиента. Вместо того чтобы гарантировать защиту, мы предоставляем пользователю набор продуктов, сконфигурированных так, чтобы обеспечить наилучшую защиту, и при этом вынуждены предупреждать пользователей, что существуют риски, обусловленные их собственной средой, и что о защите от таких рисков они должны позаботиться сами. В тех случаях, когда мы используем коммерческие решения, мы оцениваем эти продукты с помощью программы тестирования Common Criteria.

Программа Common Criteria определяет процедуры тестирования уязвимости коммерческого программного обеспечения сертифицированными тестовыми центрами, и расходы берут на себя производители программного обеспечения. Чем это продиктовано? Сейчас задача состоит в гарантировании максимально высокой на сегодня степени защиты систем, подключаемых к общедоступным сетям, подобным Internet. Common Criteria — один из важнейших механизмов, которые используются для оценки продуктов производителей на соответствие международно признанным стандартам. Мы помогли утвердить эти стандарты, применив к ним другие наши руководства, главным образом Orange Book. И мы уже сотрудничаем с различными независимыми сертифицированными тестовыми лабораториями в рамках программы Trust Technology Assessment Program, предусматривающей тестирование продуктов на соответствие критериям Orange Book. Все эти лаборатории, кроме одной, прошли сертификацию в рамках программы Common Criteria.

Каким образом Common Criteria помогает корпоративным заказчикам? Протестировано множество продуктов. Это коммерческие межсетевые экраны, операционные системы, маршрутизаторы, системы обнаружения вторжений и т.д. Эти продукты проходят множество тестов, по результатам им присваивается определенный уровень гарантии (от 0 до 7). Чем выше число, тем более защищен продукт. Это полезная информация для всех, кто покупает коммерческие продукты.

Каким образом можно осуществить тестирование защиты коммерческого программного обеспечения, когда продукты могут работать на самых разных конфигурациях? Именно над этим мы и работаем. Это подразумевает решение следующих вопросов: каким образом вы объединяете все в систему и определяете уязвимые места; как вы количественно определяете эти недостатки; как накладываете новую систему на аппаратное и программное обеспечение; как определяете процедуры.

Мы работаем над стандартом на процедуры, чтобы начать решать проблемы системного уровня. Нам необходимо систематизировать лучшие практические решения и фундаментальные основы и выразить это в формате, аналогичном Common Criteria. Затем мы должны передать это участникам ИТ-отрасли, чтобы разделить нагрузку по тестированию уязвимых моментов на системном уровне, а не только на уровне отдельных продуктов. Я надеюсь, что в обозримом будущем в отрасли появятся решения, которые можно использовать для оценки.

С какими еще трудностями вы сталкиваетесь? Одна из самых серьезных проблем — контроль версий. Мы по-прежнему не можем убедить пользователей из госсектора строго относиться к контролю за сменой версий, поскольку они хотят работать с новейшей графикой и с самыми высокими скоростями. Предположим, мы оптимизировали новый продукт и предоставили клиенту руководство, которое, если ему следовать, гарантирует максимально возможную защиту. И вот какой-нибудь администратор нашего клиента меняет что-то, и мы никак не можем выяснить, не привело ли это к появлению нового уязвимого места.

Вы даете гарантии? Во-первых, поймите, что панацеи не существует. Вот почему нам необходимо оценивать продукты. Но вам также необходимо тщательно проанализировать свою сетевую конфигурацию, процедурные рекомендации, правила и затем технологию, если вы хотите добиться самой надежной защиты из возможных. Все это должно быть сделано на системном или сетевом уровне, а не на уровне отдельных компонентов. Затем, прежде чем добавить какой-либо из понравившихся вам компонентов к своей сети, оцените его функциональность, полезность и ценность. Администраторы вашей сети и инженеры по системной безопасности должны знать, что реализация всего этого на уровне пользователя требует междисциплинарного подхода. Но так как ни один отдельно взятый человек всех этих тонкостей не знает, мы выступаем за групповой подход, предусматривающий, к примеру, сотрудничество специалистов по шифрованию со специалистами по межсетевым экранам и сетевыми инженерами.