Cybersecurity Framework Workshop №4: маркетинг это хорошо, но не для инженеров

В течение этого года мне представилась возможность посетить ряд отраслевых мероприятий и наблюдать воочию, как эволюционирует защита от IT-угроз в промышленной области. Одним из таких мероприятий стала Четвёртая рабочая встреча Национального института стандартов и технологий (NIST) по разработке т. н. Cybersecurity Framework, то есть свода нормативов по защите критической инфраструктуры от киберугроз. «Лаборатория» принимала участие и в предшествовавших мероприятиях, главное отличие этого заключалась в наличии спонсоров — Благодаря Intel в этот раз у нас был даже коктейль-пати ;-). Само мероприятие проводилось, естественно, на должном профессиональном уровне.

Четвёртая конференция была посвящена обсуждению последней версии Cybersecurity Framework, опубликованной 28 августа 2013 года. Мои основные соображения не сильно отличаются от тех, что появились после третьей конференции:

• Cybersecurity Framework — это скорее маркетинговый толчок для новичков и напоминание для профессионалов по информационной безопасности
• Cybersecurity Framework отвечает на вопрос «что делать?», а не «как делать?».
• Представителям индустрии самим необходимо как можно скорее найти ответ на вопрос «как»
• Ну, и для защиты критической инфраструктуры необходимы технологии «белых списков» и «запрет по умолчанию«;-)

В общем и целом, в Framework в её нынешнем виде недостаёт конкретики ни для одного из 17 определенных правительством США секторов критической инфраструктуры, (включая 9 секторов, сильно зависящих от управляющих индустриальных систем — энергетика, химическая и ядерная промышленность, транспортные системы, водоснабжение, критическое производство, дамбы, оборонная промышленность, объекты коммерческой застройки).

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

Для тех, кто мало знаком с темой, Framework состоит из пяти функций, соответствующих категорий и подкатегорий; а также включает в себя профили безопасности и «уровни зрелости». Функции описывают общие задачи системы кибербезопасности: Identify, Protect, Detect, Respond, and Recover (идентифицировать, защищать, обнаруживать, реагировать и восстанавливать). Большая часть людей согласна с этим списком функций, в то время как другие считают, что сюда необходимо добавить такие понятия как улучшение/обновление. В отличие от многих других концепций, те, что посвящены безопасности, устаревают достаточно быстро: то, что ваша защита эффективна сегодня, совсем не означает, что она будет работать через год – хакеры не стоят на месте.

С категориями также все достаточно понятно. Например, в задачу «Управления активами (Asset Management) входит идентификация и управление персоналом, устройствами, системами и объектами, благодаря которым организация достигает поставленных целей в бизнесе, в том числе, их относительную важность для бизнес-целей, в поддержку эффективных решений в области рисков». Такие категории служат высокоуровневыми целями и отправной точкой в формировании и развёртывании плана в сфере кибербезопасности. К сожалению, подкатегории (их полный список приведён в документе – см. стр. 14) представляют собой смесь высокоуровневых понятий, которые позволяют видеть картину в общем, а также потенциальные цели, однако оставляет за читателем выбор методов, с другой стороны, конкретных технических средств управления безопасностью, которые для представителей многих секторов оказываются неприменимыми или недостаточными. Неудивительно, что уже две конференции подряд повторяется одно и то же: как только какая-то из рабочих групп начинает говорить о подкатегориях, работа останавливается: у большинства участников не было времени изучить весь список, и к тому же многие представители разных секторов не были удовлетворены тем, как именно составлены категории.

Теперь к хорошим новостям: NIST всё-таки одобрил подход «Лаборатории Касперского» –необходимость использования «белых списков» и принципа «запрета по умолчанию» для обеспечения защиты критической инфраструктуры:  «PR.PT-3: Реализовать и поддерживать технологии, которые устанавливают политику «всё запрещено, разрешения в порядке исключения» для запуска авторизованного программного обеспечения или организационных систем (также известный как «белые списки для приложений и сетевого трафика»). Мы считаем, что в этом есть самый что ни на есть практический смысл, и рады, что наш голос был услышан и видение принято.

В целом, однако, работу над категориями можно считать неудовлетворительной. Например, в единственном нормативе, относящемся к АСУТП (Industrial Control Systems), говорится только: «PR.PT-5: Управляйте рисками для специализированных систем, включающих операционные технологии (ICS, SCADA, DCS и PLC) в соответствии с результатами анализа рисков». Конкретнее некуда, и очень полезно для технологов! Ничего не скажешь.

Очевидно, что создать универсальные «Инструменты для управления средствами защиты» (Security Controls) для разных секторов — в том числе и IT, и промышленные системы — довольно сложно, не говоря уже о более специфических секторах, у которые есть отличия в используемых технологиях и подходах к защите. Например, организации финансового сектора обычно уделяют значительное внимание защите данных, однако приведенный на конферецнии пример с Казначейством весьма показателен — информация о владельцах сберегательных облигаций является публичной, так что сохранение конфиденциальности не является задачей первого приоритета. но при этом целостность данных, о том, в чьем именно распоряжении и сколько облигаций находятся, жизненно необходима, и ее нарушение приведет к потере целых состояний, которые ведь и существуют-то только в электроном виде. Кстати, схожие приоритеты в защите (доступность и целостность важнее конфиденциальности) действуют и в промышленных системамах управления.

Как мне кажется, NIST решил оставить работу по определению конкретных наборов подкатегорий и инструментов управления средствами защитой самим отдельным секторам критической инфраструктуры. Но этот метод не слишком хорош для тех секторов, которые зависят от промышленных сетей; существуют 9 секторов, где в равной степени превалируют именно промышленные системы. При этом организации, входящие в их состав, имеют различное подчинение, а их деятельность регулируется различными нормативами – например, министерством энергетики и министерством транспорта. Так что непонятно, придётся ли каждому сектору самостоятельно производить конкретизацию понятий в Cybersecurity Framework, и означает ли это, что данный процесс придётся повторять девять раз – предполагаю, что с разными результатам.

Конкретные шаги по реализации CFW NIST тоже, похоже, собрался оставить каждому сектору в отдельности. Один из вопросов, на который последняя конференция так и не дала ответа, звучал следующим образом: «Каким образом внедрить средства безопасности в соответствии с данным Framework, или, по крайней мере, с чего следует начинать?».

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

При этом многие опасаются, что как только эти Уровни станут частью общей концепции, их начнут использовать в регулировании, для расчёта страховых выплат и так далее, даром, что они совершенно не для этого предназначены. С точки зрения регулирования, это обстоятельство приходится рассматривать всерьёз, по крайней мере, в США; для других стран это может и не оказаться сколько-нибудь серьёзной проблемой. Они смогут использовать «корневую» структуру CFW, но приводить его в жизнь по-своему.

И все же положительные результаты есть:

• Сyber Security Framework в значительной степени призван решать маркетинговые задачи: необходимо растормошить все сектора, связанные с критической инфраструктурой, включая те, в которых никаких программ по обеспечению кибербезопасности ещё нет, и заставить их начать что-то делать; в то же время, помочь получить бОльший бюджет руководителям отделов информационной безопасности тех критических объектов, у которых уже есть ясное видение проблематики и путей решения. Многие предлагают опубликовать концепцию в виде маркетинговой брошюры, чтобы не оставлять никаких разночтений в ее задаче.

Министерство национальной безопасности США собирается поддержать CFW; в частности, рассказывать о нём в ходе выступлений своих представителей на отраслевых конференциях, и, главное, предлагая всевозможные экономические поощрения тем, кто будет ее использовать и внедрять. Необходимо «продавать» эту концепцию коммерческим компаниям на всех уровнях, поскольку пока (пока!) следование CFW является сугубо добровольным делом. В кулуарах немало говорилось о том, что инженеры на оперативном уровне могут игнорировать пожелания МНБ или даже опасаться любых дополнительных рекомендаций/предписаний со стороны людей, у которых нет понимания операционных технологий.

•  Второй позитивный результат конференции заключается в том, что как только CFW начнут широко пропагандировать, этот документ сможет помочь представителям из самых разных компаний. Разным компаниям необходимо помочь найти взаимопонимание в области кибербезопасности, поскольку большинство критических инфраструктур взаимосвязаны и пользуются ресурсами друг друга, что может привести к серьёзному «эффекту домино», случись где-нибудь инцидент с кибербезопасностью. Маркетинговые усилия в этом направлении могут помочь также и многим странам, заинтересованным в защите своей критической инфраструктуры.
• Ну, и третий результат, это решение провести специальные работы по определению инструментов обеспечения безопасности и увязыванию CFW с существующими секторами и промышленными стандартами, хотя пока остаётся неясным, кто будет этим заниматься. Cyberframework может стать объединяющим звеном между стандартами и собственными концепциями безопасности, используемыми в разных секторах, что также может помочь в налаживании взаимопонимания между различными структурами на техническом уровне.

В то время, как Cybersecurity Framework может стать первоначальным импульсом для продвижения принципов кибербезопасности в область критической инфраструктуры, единственный способ реально увеличить степень защищённости заключается в том, чтобы совершить шаг 2 («С чего мне начать») и шаг 3 («Каким передовым наработкам следовать») в каждом из секторов критической инфраструктуры. Среди них есть десять промышленных секторов, в которых опыт налаживания IT-безопасности в целом куда меньше, и которые отличаются от всех остальных природой своих процессов (ориентированных на постоянную доступность, а не сохранность данных, например). Так что пока остаётся открытым вопрос, как на практике можно повысить безопасность в промышленности с учётом актуальных угроз?