Защита критических инфраструктур в прицеле ученых

Продолжу тему критических инфраструктур. Брюс Шнайер дал ссылку на интересную статью "Critical infrastructure protection: The vulnerability conundrum", в которой два автора (Алан Мюррей и Тони Грубесик) попробовали обосновать немного отличную от принятой модели защиты критичных инфраструктур (АСУ ТП). Как рассуждали авторы? Они проанализировали множество исходных данных и пришли к выводу, что большинство строят защиту критичных инфраструктур из т.н. "worst case" ("самый худший вариант") сценария. Т.е. анализируются уязвимости, риски и угрозы, из них выбираются те, которые приводят к максимальному ущербу и именно против этих проблем и строится система защиты. Мюррей и Грубесик показывают, что это не совсем верный подход, т.к. возможны альтернативные сценарии развития событий, которые не будут самыми худшими, но близкими к ним. При этом защиты от них не будет никакой.

Что предложили авторы? Они попробовали обосновать выбор защитных стратегий не исходя из худшего сценария, а исходя из лучшего распределения защитных ресурсов, которые предотвращают не один, а два, три, пять и более сценариев развития негативных событий. При этом авторы доказывают, что их модель не только лучше защищает критические инфраструктуры от угроз, но и показывает, почему в последнее время происходит много инцидентов с АСУ ТП. Просто распределение защитных ресурсов в сценарии "worst case" не совпадает с тем, которое является оптимальным при борьбе сразу с несколькими сценариями развития событий.

Интересно, что сказали бы авторы, если бы узнали, что по требованиям защиты КСИИ надо защищаться от любой угрозы, вероятность осуществления которой не равна нулю. Тут ни о каком оптимальном распределении ресурсов и речи не идет. Но математический аппарат, предложенный авторами, может быть применен и тут. Правда, полученные результаты все равно придется согласовывать с ФСТЭК.

Делай, что должен, и будь, что будет!

Сразу хочу сделать замечание: я комментировать опубликованные проекты Постановлений Правительства по персданным пока не буду. Ключевые моменты я отразил, рассказывая про Форум директоров по ИБ. Дальше начинается уже глубокий анализ текста, который сейчас, наверное, не имеет смысла. Кто хочет, может посмотреть комментарии Алексея Волкова.

Я от текста тоже не в восторге, но и критиковать их, не делая попытки что-то поправить, считаю не совсем правильным. Разумеется при условии, что можно что-то поправить. Это вам не законопроект, выложенный на сайте Минэкономразвития, - там аккредитованным экспертом надо быть. Лично я внес свои предложения по изменению текста проектов постановлений. До их принятия или непринятия комментировать считаю бессмысленным. Сейчас можно что угодно говорить, но это не продуктивно. Надо вносить предложения. Если их примут, то комментировать Постановление с учетом уже внесенных правок. Если не примут, то критиковать Постановление и рассказать о сделанных предложениях, которые отвергли.

Пессимизм коллег, которые считают, что авторы постановлений хотят только собрать возражения, чтобы быть к ним готовым, когда тексты финализируют и подпишут, не разделяю. Также как и не разделяю мнение, что авторы соберут предложения и выбросят их на помойку. Тогда можно было бы вообще не собирать, а просто поставить всех перед фактом, как это было не раз в прошлом. Ну и опять же, есть у меня положительный опыт общения с авторами нормативной базы ФСБ. Если предложения здравое и не вступают в жесткую конфронтацию с позицией регулятора, то они вполне готовы их рассматривать и править текст. Я в своих предложениях старался не менять концепцию на 100% и переворачивать все с ног на голову, говоря, что все плохо и все надо менять коренным образом. В прошлогоднем протоколе Правительства, в котором предписывалось разработать эти Постановления, говорилось, что надо сохранить преемственность с уже принятыми нормативными актами. Эта задача была решена. Так что коренным образом поменять проекты не удастся, а вот убрать оттуда явные ляпы можно. Что и советую тем, кто хочет перейти от обычной критики к реальным предложениям.

Проекты новых Постановлений Правительства по ПДн опубликованы

На сайте ФСБ опубликовано два проекта Постановления Правительства по ПДн:

• Об установлении уровней защищенности персональных данных при их обработке в информационных системах персональных данных в зависимости от угроз безопасности этих данных
• О требованиях к защите персональных данных при их обработке в информационных системах персональных данных, исполнение которых обеспечивает установленные уровни защищенности персональных данных

Кладезь информации по защите АСУ ТП

Завершу эту неделю постом опять про АСУ ТП, а точнее про то, как рекомендуют защищать их в США. Информация это публичная и может быть очень полезна и отечественным организациям, применяющим АСУ ТП в своей деятельности. Документы ФСТЭК по этой тематике имеют гриф и если, по счастливой случайности, компания, использующая АСУ ТП, не попала в перечень критически важных объектов, то она остается один на один с злоумышленниками. Никаких иных отечественных документов, описывающих требования по защите АСУ ТП, у нас нет (если не считать стандарты Газпрома). Что же делать?

Рекомендую обратиться к опыту US-CERT, который ведет очень бурную деятельность в области исследований темы ИБ АСУ ТП, повышения осведомленности компаний по данной тематике, проведении тренингов и т.д. В частности US-CERT опубликовал у себя на сайте:

• модель нарушителя для АСУ ТП
• модель информационных потоков в АСУ ТП и на подступах к ней
• высокоуровневые графы атак на элементы АСУ ТП (я про этот метод уже писал; да и Cisco сама использует его у себя  внутри)
• расписание ежемесячных тренингов (длительность - неделя)
• бюллетени по уязвимостям в АСУ ТП различных вендоров
• информацию о деятельности рабочих групп по различным аспектам защиты АСУ ТП
• огромное количество документов и исследований по теме защиты АСУ ТП. Среди них и различные постеры, и пошаговые инструкции, и описания метрик для оценки защищенности АСУ ТП и многое другое.
• бесплатный инструмент для оценки защищенности Cyber Security Evaluation Tool (CSET). Где вы еще такое увидите, чтобы регулятор разработал за свой счет инструмент оценки и раздавал его бесплатно направо и налево?..
• ссылки на стандарты, сайты схожей тематики и другие материалы по теме.

И конечно же, большой раздел посвящен рекомендациям и лучшим практикам по защите АСУ ТП. Тут вам и разработка плана расследования инцидентов, и план подготовки к реагированию на инциденты, и руководство по размещению МСЭ в АСУ ТП, и рекомендации по управлению патчами в технологических сегментах, и рекомендации по защите модемных входов в АСУ ТП (например, для удаленной поддержки), и руководство по использовании Wi-Fi, и многое другое.

В целом могу только порекомендовать включить данный сайт в список чтимых и читаемых, а тем, кто имеет дело с безопасностью АСУ ТП, включить его в список "must have".

Безопасность электроэнергетики

Про безопасность электроэнергетики в разрезе защиты SmartGrid и АСУ ТП я уже неоднократно писал. Но тема не теряет своей актуальности, о чем говорит возрастающее число зарубежных материалов по этой теме. Например, большой исследовательский отчет Pike Research о безопасности SmartGrid, в котором не только озвучивается сумма инвестиций в это направление (18 миллиардов долларов до 2018 года), но и говорится, что 63% этих ресурсов пойдут на защиту АСУ ТП, используемых в электроэнергетике.

Но несмотря на это, информационная безопасность критически важных объектов по-прежнему находится в загоне и далеко позади злоумышленников. При наличии средств защиты АСУ ТП, они не используются. Архитектура ИБ АСУ ТП отсутствует. Превалирует заплаточный подход, скопированный из жизни корпоративных безопасников.

Многие же вообще не понимают специфики и не знают о существующих наработках в области защиты АСУ ТП. Например, в марте этого года Министерство энергетики США выпустило проект документа "Electricity SubSector Cybersecurity Risk Management Process". Документ на 89 страниц. Выглядит очень достойно - подробно расписаны все шаги управления рисками, но... не для АСУ ТП. Такое впечатление, что авторы взяли за основу NIST Special Publication (SP) 800-39 "Managing Information Security Risk" и даже не удосужились применить положения 800-39 именно к теме критических инфраструктур. В тексте указано, что обычные ИТ-системы и АСУ ТП имеют разные требования по ИБ. И стоят перед ними немного разные задачи и цели в контексте ИБ. По сути авторы приравняли обычные ИТ и АСУ ТП и написали документ про управление рисками первых, но не вторых.

Сам документ ссылается на NISTIR 7628 "Guidelines for Smart Grid Cyber Security" (часть 1, часть 2, часть 3 и часть 4) и стандарты по ИБ Североамериканской электрической корпорации (NERC). А их там, к слову, 20 стандартов. И доступны они всем и никакого грифа на них нет; в отличие от наших документов по КСИИ. Но дело не в этом. Проект документа американского Минэнерго ни слова не говорит о ISA99, основном наборе стандартов в области безопасности систем управления технологическими процессами. Напрашивается вопрос: "А авторы проекта документа вообще имели дело с АСУ ТП?" Остается надеяться, что практика опубликования проектов документов и привлечения сообщества к доработке, известная в США многие годы, даст свои плоды и эксперты донесут до Минэнерго проблему разработанного документа. Хотя как описание процесса управления общими рисками ИБ документ интересен.

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

Краткий анализ 313-го Постановления, сменившего на посту ПП-957

16 апреля закончилась эпоха 957-го Постановления Правительства "Об утверждении положений о лицензировании отдельных видов деятельности, связанных с шифровальными (криптографическими) средствами". Ему на смену пришло новое Постановление № 313 "Об утверждении Положения о лицензировании деятельности по разработке, производству, распространению шифровальных (криптографических) средств, информационных систем и телекоммуникационных систем, защищенных с использованием шифровальных (криптографических) средств, выполнению работ, оказанию услуг в области шифрования информации, ехническому обслуживанию шифровальных (криптографических) средств, информационных систем и телекоммуникационных систем, защищенных с использованием шифровальных (криптографических) средств (за исключением случая, если техническое обслуживание шифровальных (криптографических) средств, информационных систем и телекоммуникационных систем, защищенных с использованием шифровальных (криптографических) средств, осуществляется для обеспечения собственных нужд юридического лица или индивидуального предпринимателя)".

Про проект этого Постановления я уже писал, как и про заключение Минэкономразвития на него. И вот финальный текст. Какие в нем изменения? Вот краткий перечень того, за что уцепился мой взгляд:

• Расширен перечень того, что попадает в определение "шифровальные (криптографические) средства (СКЗИ)". Новых три элемента - аппаратные шифровальные средства, программные шифровальные средства и программно-аппаратные шифровальные средства. На мой взгляд это было лишним, т.к. эти три новых определения покрываются подпунктом а), вводящим определение средств шифрования. Но видимо у разработчиков были причины вносить три новых определения. Кстати, в новой редакции были растолкованы термины, ранее неопределенные, например, "ключевые документы".
• На два пункта был расширен перечень средств, на которые Положение не распространяется. В частности это "товары, содержащие шифровальные (криптографические) средства, имеющие либо функцию аутентификации, включающей в себя все аспекты контроля доступа, где нет шифрования файлов или текстов, за исключением шифрования, которое непосредственно связано с защитой паролей, персональных идентификационных номеров или подобных данных для защиты от несанкционированного доступа, либо имеющие электронную подпись" (в), "оборудование, криптографические возможности которого недоступны пользователю, специально разработанное и ограниченное для осуществления следующих функций..." (ж) и "товары, у которых криптографическая функция гарантированно заблокирована производителем" (м). А также были уточнены имеющиеся ранее исключения. Исключены из исключений контрольно-кассовые машины.
• Положение не распространяется на деятельность, связанную с электронной подписью. Т.е. теперь эта деятельность не лицензируется ФСБ. По крайней мере это вытекает из статьи 3в.
• Перечень лицензируемых работ и услуг был вынесен в приложение для облегчения понимания. Из 30 видов в проекте осталось 28. Но все равно немало.
• Жесткие требования к квалификации персонала. В зависимости от вида лицензируемых работ и услуг необходимо иметь высшее профессиональное образование по специальности, переподотовку в течение 1000 (500 или 100) аудиторных часов и иметь стаж 5 (3) года. При требования к квалификации я уже писал. Так что ничего нового. Но зато появилась ясность.Кстати, 1000 аудиторных часов - это полноценный институтский курс по информационной безопасности, читаемый в течении 5-6 лет! Где руководители будут получать такое обучение? Ни один учебный центр не в состоянии не то что появившийся спрос удовлетворить, но и вообще реализовать это требование. 1000 часов! Это к слову 125 полностью загруженных (по 8 часов) рабочих дней.

Что интересно. По замечаниям Минэкономразвития авторы поступили просто. Проигнорировали их. Например, в МЭР закономерно написали, что обязательное лицензирование можно вводить тогда, когда есть угроза жизни, здоровью... ну и т.д. И что в проекте постановления ни одна из целей, указанных в законе "О лицензировании отдельных видов деятельности", не установлена и не упомянута. Т.е. нет предмета для лицензирования вообще. Но авторы закрыли глаза на это замечание. МЭР тоже.

Замечания по отсутствию обоснования установленного количества часов также не устранено. Как и замечание по используемому контрольно-измерительному оборудованию. Требование заменить 56 бит на 64 и добавить упоминание продуктов для "mass-market", как того требовали Вассенаарские соглашения (1996 год), которые подписала и Россия. Видимо авторы, как это часто бывает, посчитали устранять эти замечания нецелесообразными ;-( А жаль.

Из занятного. Постановление называется "Об утверждении Положения о лицензировании деятельности по разработке, производству, распространению шифровальных (криптографических) средств...". Т.е. слово распространение в названии есть. А вот по тексту Постановления оно нигде больше не встречается. Нигде. На это указывало и Минэкономразвития. Но все осталось без изменения. Получается, что деятельности по распространению СКЗИ теперь выпала из лицензирования?!.. А может термин "распространение" был заменен на "передача"? Но это не очевидно. Например, разместив на сайте СКЗИ и дав возможность ее скачивать всем своим клиентам и контрагентам, я осуществляю распространение, но не передачу СКЗИ... Тут есть о чем подумать.

Безопасность мобильных платежей

Сегодня, в 12 дня в рамках MIPS открывается конференция "Безопасность платежных систем". И пригласили меня сделать доклад на тему "Мобильные платежи в контексте СТО БР ИББС". Z уж не знаю, почему пригласили меня прочитать эту тему; вроде как в ПК5 ТК122, который и отвечает за мобильный платежи, я не вхожу. Но раз уж пригласили, то надо отдуваться. Сначала я хотел прочитать что-нибудь похожее на то, что я читал на PCI DSS Russia 2012. Потом мне пришла в голову ценная мысль, что начать надо с рассказа о том, как можно получить доступ с мобильного телефона к ДБО и плавно перейти на защиту ДБО. Но по зрелому размышлению, все-таки решил я копнуть тему истинных мобильных платежей. Тем более, что году в 2007-2008 я уже выступал на эту тему на 3-х или 4-х конференциях.

Стал копать. На русском языке информации маловато, мягко скажем. Проект Постановления Правительства по защите НПС (он, кстати, ушел уже в Правительство на подпись) на этот вопрос не отвечал. СТО БР ИББС, кстати тоже. Как ни странно, но и готовящиеся детальные документы по защите НПС тоже отвечают не на все вопросы. В итоге родилась презентация, которую я и выкладываю.

Безопасность мобильных платежей

View more presentations from Alexey Lukatsky.

Угроза АСУ ТП растет

Американцы отмечают рост угроз для АСУ ТП. Это связано не только с ростом числа уязвимостей в системах, отвечающих за управление технологическими процессами, но и с ростом интереса различных хактивистских и анархистских групп. И если раньше атаки на АСУ ТП были уедом избранных, то сегодня это все больше и больше становится мейнстримом. Уже разработано немало инструментов, которые облегчают решение этой задачи. Речь идет и о специализированных поисковых системах, которые облегчают обнаружение АСУ ТП, смотрящих в Интернет, и о выпуске модулей для Metasploit, автоматизирующих поиск уязвимостей в АСУ ТП Rockwell, GE, Schneider Electric, Koyo и WAGO.

Для борьбы с этой угрозой необходима целенаправленная работа, заключающаяся в понимании той модели угроз, с которой нам придется работать, и с теми информационными потоками, которые циркулируют в АСУ ТП.

Уже после изучения данной картинки становится понятны и потенциальные точки приложения сил злоумышленников и методы их нейтрализации. Причем, тут можно выстраивать защиту не только с помощью специализированных инструментов (например, Cisco IPS for SCADA), но и собственноручно создавая сигнатуры для свободно-распространяемой IDS Snort. Например, обнаружение использование уязвимости переполнения буфера в АСУ ТП Siemens может выглядеть так:

alert tcp any any -> any 7580 (msg:”ETPRO SCADA Siemens Tecnomatix FactoryLink CSService GetFileInfo path Buffer Overflow”; flow:to_server,established; content:”LEN|00|”; depth:4; byte_test:4,>,1028,0,little; content:”|99|”; distance:8; within:1; content:”|99 00 00 00 0a 00 00 00 01 06|”; distance:0; byte_test:4,>,1024,0,big; classtype:attempted-user; reference:url,digitalbond.com/tools/quickdraw/vulnerability-rules; sid:1111676; rev:1;)

а обнаружение атаки "отказ в обслуживании" на Rockwell Automation’s RSLogix и FactoryTalk так:

alert tcp any any -> $HOME_NET $ROCKWELL_PORTS (msg:”Rockwell RNA Message Negative Header Length”; flow:to_server; content:”rna|f2|”; byte_test:1,&,0×80,3,relative,little; classtype:attempted-dos; sid:1111682; rev:1;)

Правда, в этом случае, придется не только самостоятельно изучать, как работает АСУ ТП, но регулярно отслеживать все новости об уязвимостях в системах автоматизации технологических процессов. Для этого можно использовать, например, RSS американского министерства национальной безопасности (https://www.us-cert.gov/control_systems/xml/rss.xml).

Главное, что защита АСУ ТП - это не "черный ящик". Она подчиняется тем же законам и принципам, что и обычная корпоративная безопасность. И стандарты там похожи, на ту же 27-ю серию. Надо только начать.

Революция от ФСТЭК и новости от ФСБ

Форум закончился. Прошло пару дней. Впечатления сформировались - можно ими и поделиться. Мне понравилось ;-) И не только потому, что мы были спонсором. Просто мероприятие действительно было ориентировано на аудиторию, что бывает не часто. И особенно порадовало то, что присутствовали представители ФСТЭК и ФСБ, которые не молчали как обычно и не отделывались общими фразами. Выступления Олега Залунина и Виталия Лютикова были конкретны и насыщены фактами и интересными новостями. С них и начну.

Тезисно из выступлений Олега Залунина (ФСБ):

• Проекты двух новых Постановлений Правительства уже разработаны и направлены всем заинтересованным сторонам. Головным разработчиком постановлений по уровням защищенности и требованиям по ИБ была ФСБ. ФСБ старалась сохранить преемственность с ПП-781 и "приказом трех". Выпустить новые ПП должны в мае.
• Новые понятие  "уровень защищенности" зависит от класса ИСПДН, модели угроз и модели нарушителя. Уровней будет 4.
• Классификация ИСПДн останется почти без изменений - разделение на специальные и типовые уберут и оставят просто ИСПДн. Принципы классификации (объем и категория) останутся теми же.
• Новое понятие новых Постановлений - модель нарушителя. Будет 3 категории нарушителей.
• Наличие спецкатегории ПДн не означает, что защищать их надо будет по высшему классу. С помощью использования модели нарушителя можно будет выставить не самый высокий уровень защищенности.
• Новое ПП про требования по защите ПДн делается на базе ПП-781. Ничего нового там почти не будет.
• На базе новых ПП ФСТЭК и ФСБ детализирует свои требования по защите. Новые приказы ФСБ и ФСТЭК по ПДн будут в июне/июле. Могу от себя предположить, что по линии ФСТЭК скорее всего ничего сильно не поменяется. По линии ФСБ нас ждут сюрпризы.
• Нормативки по защите трансгранички нет и пока не планируется.

Тезисно из выступлений Виталия Лютикова (ФСТЭК):

• Термин "конфиденциальная информация", который вызывает много вопросов надо было править в ФЗ "О лицензировании". Не смогли. Поэтому в ПП-79 оно осталось. Только в скобках добавили его трактовку.
• Наличие контрольно-измерительноо оборудования при получении лицензии не нужно, если вы не будете заниматься техническими каналами утечек. Об этом же говорит и опубликованный во вторник документ на сайте ФСТЭК. А вообще список документов, необходимых для выполнения работ и оказания услуг по ТЗКИ также был опубликован во вторник на сайте ФСТЭК.
• РД по антивирусам находится на регистрации в МинЮсте. В его основу положены принципы РД по IPS.
• Планируются новые РД по средствам доверенной загрузки, двухфакторной аутентификации и DLP. Скорее всего в следующем году будут, не раньше.
• От сертификации по ТУ ФСТЭК будет отходить и там, где есть разработанные РД, оценка будет вестись именно по ним, а не по ТУ. Я об этом писал уже в конце 2010-го года.
• Готовятся новые требования по защите информации для госорганов на базе документов NIST. О том, что это планируется я писал, а вот о том, что речь идет о документах NIST, которые взяты за основу, я услышал впервые. Скорее всего будут взяты за основу документы 800-й серии, разработанные во исполнение американского закона FISMA. Планируемый РД заменит действующие уже около 20 лет СТР-К и РД по АС.
• ФСТЭК хочет ввести новые требования по СУИБ и управлению инцидентами. Могу только приветствовать. Хотя эти требования (как минимум в части управления инцидентами) у ФСТЭК были еще в 2007-м году, в документах по защите ключевых систем информационной инфраструктуры.
• Меняется подход к обновлению сертифицированного ПО. Будет примерно тоже, что сейчас прописано в РД по IPS.
• Будет меняться ГОСТ по АС в защищенном исполнении.
• Решение о получении лицензии ФСТЭК на ТЗКИ для собственных нужд принимается юрлицом самостоятельно.После новости о замене СТР-К это была вторая "бомба" от ФСТЭК. Правда, непонятно, насколько официальный ответ на такой запрос будет повторять данную позицию. Я могу ее трактовать примерно так: если вы спросите у ФСТЭК, то вам скажут, что лицензия нужна. А если не спросите, то и не парьтесь. Тут скорее нужно опять писать официальные запросы регулятору.
• Сертификация СЗИ ПДн обязательна для всех. Основание - ПП-330.ФСТЭК в недоумении по поводу грифа "ДСП" на ПП-330. По их словам это МинОбороны начудило и ФСТЭК сама имеет от этого кучу проблем, т.к. приъодится делать выписки, писать разъяснения и т.д.
• Аттестация ИСПДн для госучреждений является обязательной, а для коммерческих структур - на усмотрение оператора ПДн
• По поводу ненасыщенности рынка сертифицированных средств защиты информации была приведена статистика. В 2011 выдано 1.5 миллиона голограмм на сертифифированные СЗИ. В этом году, только за первый квартал, было выдано уже 500 тысяч защитных знаков. Цифры немаленькие.

Жаль, что не было представителей РКН - они бы дополнили рассказ о регуляторике и смогли бы поделиться своими планами, кои есть.По остальным заметкам направляю всех в Twitter (прямая ссылка на заметки только о мероприятии) - ничего действительно стратегического там не было.

В остальном могу отметить большое количество докладов от потребителей, а не от производителей и интеграторов. Последние малость портили картину. Либо голимой рекламой (такая была от Аванпоста), либо непониманием тенденций и попыткой придумать несуществующие тенденции под собственные поделки. Ну а кто-то пытался рассказать о каких-то интересных темах (риски, метрики, KPI), но не имея реального опыта, не мог поделиться практическим опытом. Вообще я сделал интересное наблюдение. Если какую-то тему рассказывает интегратор, то это означает только одно - потребителю эта тема либо неинтересна, либо он только приглядывается к теме и сам ее у себя не реализовывал. Ярким примером была тема, связанная с аутсорсингом ИБ. Эта тема сначала докладывалась одним из интеграторов (не совсем удачно). А потом я ее пытался поднять на секции по защите ЦОДов, где я хотел понять, кто-то арендует ЦОДы или нет. Оказалось, что нет ;-)

Вот примерно такое впечатление от мероприятия. Собственно я участвую в мероприятии, как минимум, 4-й раз, а может и пятый, и могу сказать, что все разы у меня впечатления только положительные.

Как меня развели или об очередном творении в моей библиотеке

Предыстория... Наткнулся на Озоне на книжку "Экономика защиты информации" некоего Шепитько Г.Е.

Анонс меня привлек. Рецензии тоже. Там и про то, что ее все практики ИБ должны прочесть, и про возможность общаться с бизнесом после прочтения книжки, и про многое другое. Потом, правда, я обнаружил, что все рецензии даны в течение всего одной недели мая 2011 года. Содержание весомое.

Начал читать. Вообще автор местами просто удивлял. Начиная от предложения использовать методы страхования информационных рисков, опираясь на статистику, которой в нашей сфере просто нет. А как вам практическое задание по теме экономики защиты информации: "Период работы гражданина до пенсии составляет 40 лет, возраст его дожится после пенсии - 20 лет, причем размер пенсии не превышает 50% от его средней зарплаты. Сколько процентов от зарплаты он должен накапливать на банковском счету, чтобы получать 50% надбавку к пенсии при таком способе самофинансирования пенсии?" И причем тут защита информации спрашивается?

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

Потом автор начинает вычислять интенсивность инцидентов. Ну тут я вновь умолкаю. "Теорема 2. При воздействии пуассоновского потока инцидентов внутренних преднамеренных нарушителей с переменным ресурсом поведения автономной линейной системы защиты первого порядка с переменными параметрами описывается вторым уравнением безопасности вида <две строки непонятных мне букв греческого и латинского алфавитов, цифр, знаков препинания и еще чего-то>". Дальше две практических задачки. Первая - "Системный администратор вуза получает ежемесячно 15 тысяч рублей. Чему равен его вклад в годовую чистую прибыль такого учреждения по оказанию образовательных услуг?". Вторая - "Оператор ввода информации на ПК стоимостью 10 тысяч рублей получает такую же месячную зарплату. Какова стоимость нового информационного ресурса созданного им в течение месяца?".

Третий раздел труда Шепитько Г.Е. посвящен категорированию объектов информатизации. Зачем-то он полез в тему персданных. Мало того, что он вводит новый гриф "персонально" и перевирает ФЗ-152, т.к. он еще накрутил там столько формул. Я, например, узнал, что то, что в "приказе трех" по классификации определялось как 3 значения объема ПДн (до 1000, от 1000 до 100000, и больше 100000 субъектов), на самом деле является "логарифмической интервальной шкалой измерений количества субъектов персональных данных". И если в обычной жизни я просто беру одно из трех значений данного показателя, то автор даже предлагает особую формулу для расчета этого значения (результаты, правда, получаются те же). А еще я не вкурил, зачем нужно рассчитывать зависимость значения категории объема ПДн Xнпд от их объема Vнпд по формуле Xнпд=3,5 - 0,217 * lnVнпд.

Потом идет много-много формул и таблиц расчета нелинейных скалярных показателей категорирования степени защиты ПДн. Я так и не вкурил. Видимо моего диплома прикладного математика не хватает для оценки глубины исследования. Но вывод, сделанный автором, меня зацепил. Оказывается, причин слабости защиты ПДн (выведено на основе формул) всего 4:

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

Практическое задание в этом разделе такое: "В ИТ-подразделении коммерческого вуза находятся 4 компьютерных класса по 25 компьютеров каждый. Срок службы компьютеров - более трех лет, поэтому наблюдается ежемесячно более трех мелких компьютерных нарушений с ущербом не более 3 тыс.руб. Определите категорию важности такого объекта информатизации, содержашего коммерческую тайну".

В разделе про оценку рисков и эффективности системы защиты я узнал, что для оценки эффективности защиты недостаточно знания только экономического риска. Необходимо принять во внимание дополнительную "социальную нагрузку" на нее со стороны общества для одобрения им уровня допустимого риска в соответствии с ФЗ "О техническом регулировании". Также я узнал, что интенсивность потока допущенных инцидентов ИБ можно оценить по модели Остроградлского-Ланчестера-Осипова, разработанной в Генеральном штабе русской армии еще в 1905 году.

Дальше автор, попутно опустив Эйнштейна и назвав его "известный из газет А.Эйнштейн", утверждает, что вероятности ущерба от последствий инцидентов ИБ описываются логарифмически нормальным распределением. И на этом сей опус завершается. Из заданий этого раздела: "Оцените стоимость базы паспортных данных предпринимателей московского региона, если их количество не превышает 1 миллиона человек".

Потом обратил внимание на то, что на каждой странице от руки написан экземпляр книги. Вдумайтесь только. На каждой странице и от руки.

Я решил было посмотреть выходные данные, ан нет. Нет их. Тираж определить невозможно. Мне сразу подумалось, что речь идет о печати под заказ. Заказали книжку - напечатали; не заказали - не напечатали. Ну а как еще объяснить от руки подписанные номера экземпляров? Дальше больше. На первой странице предупреждение о контроле каждого экземпляра и ссылка на отмененный закон об авторских правах.

Но и это не все. В книгу был вложен вот такой листочек! Я его даже не буду комментировать - просто читайте и ужасайтесь.

ЗЫ. Не рассматривайте заметку, как рекламу книги!

ЗЗЫ. И ведь не первое апреля вроде. Но ржал наш офис, когда я читал выдержки, в течение пары часов. Массу удовольствия доставило это чтиво.

ЗЗЗЫ. Данное пособие планируется к включению в государственный образовательный стандарт третьего поколения. Мне жаль студентов, которые будут учиться по этой х..не.

ЗЗЗЗЫ. На форзаце висит гриф "Для внутреннего пользования". Хорошо что не для наружного применения.

ЗЗЗЗЗЫ. Книга посвящена светлой памяти резидента русской разведки Полежаева А.П., награжденного "За выдающийся вклад в информатизацию мирового сообщества". Билл Гейтс или Стив Джоббс отдыхают.

Все ли метрики нужны? Все ли метрики важны?

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

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

Разумеется, это не значит, что их не надо измерять и применять на практике. Просто надо четко понимать, что эти примеры - не более чем низкоуровневые метрики для оценки эффективности продуктов. Это полезно, чтобы знать, насколько хорош тот или иной продукт, но совсем недостаточно, чтобы демонстрировать эти метрики бизнесу.

Как считать риски?

Вчера, на форуме директоров по ИБ опять подняли тему оценки рисков. Традиционно. И опять ни к чему не пришли. Зрители в зале пытались получить серебряную пулю в виде конкретных рекомендаций, а выступающие отговаривались общими фразами про классическую формулу "риск = вероятность * ущерб". На вопрос про оценку ущерба ответ был предсказуем - "экспертная оценка". На вопрос о вероятности - экспертная оценка или база инцидентов. В итоге все остались недовольны. Одни - ответом. Другие - вопросом ;-)

Я к теме оценки рисков не обращался уже года два. Мне казалось я все сказал еще на InfoSecurity 2008. Но видимо придется тезисно повторить. Как было сказано в одной статье: "Анализ рисков, оценка их вероятности и тяжести последствий похожа на посещение игроками Лас-Вегаса - зал общий, а система игры у каждого своя". И действительно. Методов оценки вероятности существует большое пяти (я знаю семь). Методов оценки ущерба - больше трех десятков. Методик оценки рисков вообще под полсотни. А результат все равно никого не устраивает. Особенно бизнес, которому результат такой оценки пытаются втюхать.

За 2 года ситуация совсем не изменилась. Оценка рисков как была больше исскуством, чем наукой, так и осталась. Если не сказать больше. Оценка рисков ИБ сегодня - это шаманство. Резюме было подведено давно, в стандарте ISO 13335, в котором было сказано, что лучшая методика оценки рисков та, которая устраивает все стороны - и того, кто считает риски, и того, кому их демонстрируют. А уж какая она, совсем неважно. В прошлом ноябре, на конференции "Ведомостей", мне понравилось выступление Виталия Задорожного, директора по операционным рискам Вымпелкома. На вопрос о том, как он общается с руководством, он ответил просто - есть три сценария. Либо надо показать, что дает ИБ бизнесу (это всегда под вопросом). Либо риски от невыполнения требований должны быть катастрофическими. Либо руководство должно доверять своему CRO/CSO/CISO. И вот в последнем случае мнение оценщика и есть та самая методика оценки, которая устраивает всех.

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

Мои презентации с форума директоров по ИБ

Вчера, на первом дне межотраслевого форума директоров по ИБ я делал две презентации. Первая была посвящена тенденциям, на которые стоит обратить внимание руководителей ИБ в ближайший год-полтора.

Security trends for Russian CISO in 2012-2013

View more PowerPoint from Alexey Lukatsky

Вторая презентация была вводной к секции по безопасности ЦОДов, которую я вел.

Data Centers Security

View more presentations from Alexey Lukatsky.

Общие впечатления от форума с акцентом на наиболее интересные выступления (а там было, что послушать; особенно из уст ФСТЭК и ФСБ) опубликую уже завтра.

ЗЫ. Тем, кому не терпится - смотрите мой Twitter. Там вы найдете и заметки вчерашнего дня и заметки дня сегодняшнего.

TIBCO покупает LogLogic

3 апреля американская TIBCO объявила о намерении приобрести производителя решений по управления логами LogLogic. Детали сделки не раскрываются, как и причина приобретения. TIBCO раньit не была замечена в этом сегменте рынка.

Руководство NIST по дизайну криптографических ключевых систем

NIST выпустил Special Publication 800-130 "A Framework for Designing Cryptographic Key Management Systems", посвященный, как это видно из названия, вопросам дизайн ключевых систем для СКЗИ. 111 страниц достойнейшего чтива; и чтива публичного, не скрытого никакими грифами и ограничениями. Генерация ключей, активация ключей, регистрация владельцев ключей, деактивация ключей, перевыпуск ключей, отзыв ключей, блокирование ключей, уничтожение ключей, восстановление ключей, архивирование ключей, ввод ключей в криптографические модули и т.д. И это только часть раздела, посвященного криптоключам. Помимо него в документе описаны вопросы анализа защищенности, Disaster Recovery, тестирования и оценки качества, защиты ключей, совместимости, ролей и ответственности, политики использования и т.д.

ЗЫ. Кстати, криптографических ключей в документе описывается 21 тип! Я и не знал, что их столько бывает.

Проверьте свои сайты. Быстро!

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

Нашлось тоже немало. Политики информационной безопасности, подробные описания систем защиты, схемы сетей с указанием всей адресации, отчеты, коммерческие предложения, списки цен, результаты тестирования продуктов (не всегда положительные), анализы рынка, проекты документов, файлы паролей, конфиги (с открытыми паролями)... Прошелся и по тематике персональных данных. Причем двояко. Сначала просто поискал различные ПДн на сайтах - нашел выше крыши. Причем явно такие ПДн находятся на сайте незаконно - видимо кто-то выложил файл на сайт, а служба ИТ/ИБ то ли не проставила прав доступа на разделы сайта, то ли забыла установить запрет на индексацию... Но итог очевиден - персональных данных полно. Также как и полно документов, регламентирующих вопросы обработки и защиты ПДн. И это не политика в области обработки ПДн, которая должна быть разработана по ст.18.1 ФЗ-152. Речь идет именно о внутренних нормативных актах, которые не должны светиться наружу. Причем доходит до смешного. Общался с некоторыми коллегами на конференциях. Спрашиваю - "разработали вы нормативку по ПДн?". Отвечают утвердительно. "Можете показать?". "Нет. Конфиденциальная информация". Ввожу их сайты в Google - получаю полный набор документов, которые они скрывали ;-)

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

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

Что могу посоветовать сделать прямо сейчас. Введите в Google следующий поисковый запрос: "filetype:doc site:"адрес своего сайта"" (в Google вводить все без кавычек). Этот запрос выдаст все файлы формата DOC, которые доступны извне. Можете сузить запрос и перед filetype ввести ключевое слово или фразу. Тогда будут найдены все файлы Word, содержащие искомый запрос. Кстати, учитываете, что расширения DOC и DOCX в Google - это разные результаты в поисковой выдаче. Можно попробовать и такой запрос "filetype:dat passwd" (не забудьте использовать оператор site с указанием своего домена). Он может выдать вам очень интересный результат. А вообще с помощью Google у себя на сайте можно много чего поискать - пароли, реестры, ключи, сертификаты и т.д. Главное, правильно составить запрос, используя стандартные функции Google.

Ну а что делать, если вы у себя нашли какие-нибудь дыры, открытые всем, я думаю, вы знаете.

Сертификация специалистов по ИБ. Какая правильная?

Вопрос, вынесенный в заголовок, возникает, сколько я себя помню, регулярно. То на bankir.ru, то на professional.ru, то на Linkedin (одна из самых последних), а то и просто в частных беседах. Те, кто не имеет пока блях на груди, спрашивают у "гуру": "Ну какая же сертификация самая-самая?!" Гуру, почесывая в затылке, как правило отвечают - CISSP, CISM или CISA. А потом начинается флейм ;-) Так какая же правильная? Универсального ответа, к счастью, нет. Также как и нет ответа на вопрос "Кто такой настоящий безопасник?" Каждый сам принимает для себя итоговое решение. Но помочь его принять помогут следующие вопросы, которые задайте сами себе:

• Что вам интересно сейчас? Пентестить? Писать код? Администрировать СУБД DB2? Копаться в Linux? Проводить аудиты на соответствие СТО БР ИББС? Быть начальником? Ответ на этот вопрос сразу направит вас в нужное русло. Кому-то подойдет CEH. Кому-то MCSE Security. Кому-то GIAC GCUX. Кому-то CCIE Security. А кто-то упрется рогом и пойдет учить 10 доменов CISSP. Каждому свое.
• Что вам может быть интересно лет через 3-5? Может у вас есть какие-то устремления и мечты? Я вот когда-то хотел стать первым в России инструктором ISS. И стал им ;-) А потом от ISS я ушел и этот сертификат стал бесполезным ;-( Так что учитывайте этот момент. Ничто не вечно под луной.
• Зачем вам бляха на грудь? Наверное, это самый главный вопрос, который надо задать. Тут ответов не так уж и много. В 2003-м году я написал статью для PCWeek "Нужен ли в России CISSP?" Прошло 9 лет, а вопрос так и висит в воздухе. Причин я тогда назвал 6 - подтверждение собственной квалификации, рост зарплаты, карьерный рост, обязательное требование работодателя, хвастовство и желание быть в "касте избранных". Сегодня я бы добавил седьмую причину (она часто называлась в дискуссии на Linkedin) - систематизация знаний. Не буду комментировать. Я считаю, что за исключением обязательного требования работодателя, всего остального можно достичь и без бляхи.

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

Каждый выбирает для себя...

А вы знаете, что делает ваш компьютер, пока вы спите?

Посмотрите на ваш рабочий компьютер... Что вы видите? Монитор, клавиатура, системный блок, считыватель CD, USB-порты... А внутри? Процессор, материнская плата, жесткий диск, контроллер, память... Деталей много. А знаете ли вы, как они работают? Уверены? А если подумать? В 2008-м году я написал статью "Материнская безопасность" о закладках на уровне процессора ПК. Примерно в тоже время об этом написал Шнайер, а ComputerWorld повторил это уже на русском языке. На какое-то время тема заглохла и не поднималась ни в прессе, ни среди специалистов. Но вот в конце 2011 года в журнале "Хакер" была опубликована подробная статья о том, что в чипсетах Intel, поставляемых с заводов в Китае, содержатся вполне конкретные закладки (в "канадских" вариантах таких чипсетов никаких закладок не обнаружено).

По словам автора, эту тему он раскопал еще в 2007-м году (в США тема закладок в Intel'овских процессорах поднималась еще в 95-м году на симпозиуме IEEE) и доложил о ней своему работодателю (Kraftway), в Intel, в ФСБ, в Газпром. Везде рассказ о закладке выслушали, но оставили без внимания. РД по анализу BIOS появился в ФСБ только в 2010-м году (кстати, помните высказывания бывшего сотрудника ФАПСИ о BIOS/NetBIOS?) В феврале краткий пересказ статьи из Хакера был сделан на банковской конференции в Магнитогорске Сергеем Груздевым (слайды 12-17). А 30-го марта Счетная Палата США (GAO) опубликовала отчет "IT Supply Chain. Natonal Security - Related Agencies Need to Better Address Risks", в котором подробно описала риски, которые возникают в американских федеральных структурах в связи с поставкой запчастей к компьютерной технике из стран, за пределами США.

Достаточно интерсное исследование, которое показывает, что американцы сталкиваются регулярно с такими рисками, как:

• инсталляция ПО и железа, содержащего закладки
• инсталляция контрафактного ПО и железа
• инсталляция ПО и железа, содержащего непреднамеренные уязвимости
• и т.д.

Об этом стали задумываться (по крайней мере на словах) и у нас. В частности после падения "Фобос-Грунт" стали поговаривать о том, что возможной причиной стало именно использование китайского контрафакта на космическом аппарате. А вице-премьер Рогозин даже заявил, что России надо создавать собственную элементную базу. Правда, ничего конкретного он не предложил. Также как ничего конкретного не предлагают и в ФСБ (хотя, что они-то могут предложить...).

А пока, вместо того, чтобы заняться реальной работой, у нас пытаются только все запрещать путем выпуска различных приказов о том, что считать продукцией отечественного производства. А ведь можно было начать с малого - провести аналогичное GAO исследование и вынести на обсуждение план реагирования на растущую угрозу. Вот у американцев такой план есть - его начали реализовывать еще при Буше младшем в 2008-м году. Но конца и края этому процессу пока не видно. У нас же в России пока тишина и ничего адекватного данной угрозе пока нет ;-(

35 стратегий защиты от любителей кенгуру

Я уже не раз хвалил австралийское Министерство Обороны и их центр по обеспечению безопасности в киберпространстве. Прошлым летом выпустили они замечательный документ под названием "Стратегии для отражения целенаправленных кибератак". В этом двухстраничном документе нашли отражение все ключевые стратегии обнаружения и отражения вторжений в киберпространстве. В простой и понятной табличной форме перечислены в порядке приоритета элементарные рекомендации, среди которых:

• пачьте приложения
• минимизируйте число пользователей с административными правами
• используйте белые списки приложений (замкнутую программную среду)
• сегментируйте сеть
• усильте защиту пользовательских ОС
• контролируйте USB и иные периферийные устройства
• используйте сетевые системы обнаружения вторжений
• и т.д.

Хочу заметить, что стратегии даны в повелительной форме. Не просто "Сегментация сети", а "сегментируйте сеть", т.е. дано указание, что делать. Как учат отцы тайм-менеджмента именно такая форма считается самой правильной при формировании списков дел. Но на этом плюсы австралийского документа не заканчивается. В таблице помимо конкретного указания также дана их оценка по различным критериям:

• Общая эффективность
• Сопротивление со стороны пользователей. Офигенный критерий, которого я раньше что-то не встречал при оценке механизмов и средств защиты. А ведь он напрямую влияет на эффективность защитных мероприятий. Одно дело в прозрачном режиме поставить патч на Adobe Reader и совсем другое дело внедрить ограничения на типы вложений, которые могут пересылать пользователи по e-mail. В одном случае сопротивление будет минимальным, а во втором - вполне ожидаемо максимальным. И по каждой из 35-ти стратегий указаны свои значения данного показателя.
• Стоимость приобретения (CapEx)
• Стоимость поддержки (OpEx)
• Фокус на обнаружении или предотвращении
• На каком из трех этапов атаки помогает данная мера.

Достойнейший документ, но... его одного, конечно, недостаточно. Стратегия на то и стратегия, что за ней должны скрываться вполне конкретные рекомендации по ее реализации. На специальном сайте выложены подробные описания, как эти 35 стратегий воплотить в жизнь. При этом, что интересно. Это не "отлитый в граните" манускрипт, а регулярно обновляемый документ. Например, на сайте выложено сравнение различий между версией 2010-го и 2011-го годов.

В общем могу рекомендовать этот документ для практического применения.

15 причин утечек персональных данных

Ондрей Криль (Ondreо Krehel) из американской Loews Corp. опубликовал на днях интересную заметку, в которой перечисляет 15 самых распространенных "худших практик", приводящим к самым серьезным утечкам персональных данных. Он отнес к ним:

1. Отсутствие шифрования важной информации, особенно персональных данных.
2. Хранение ненужных данных, например, учетных записей уволенных сотрудников.
3. Использование конфиденциальной информации в тестовых целях, например, при передаче СУБД на тестирование разработчикам.
4. Неправильное удаление резервных копий и дампов, которые в случае небезопасного удаления легко восстанавливаются.
5. Неограниченные полномочия для администратора СУБД, который имеет расширенные привилегии и в других частях корпоративной сети.
6. Отсутствие надлежащего контроля доступа к СУБД извне.
7. Большое количество пользователей с расширенными административными привилегиями в СУБД.
8. Некорректные настройки правил доступа к таблицам СУБД.
9. Незащищенные пароли.
10. Пробелы в аутентификации, например, когда отдельным приложениям организуется доступ к данным в обход общих правил аутентификации.
11. Небезопасное резервное копирование, которое приводит к тому, что данные открыты для свободного доступа из Интернет.
12. Уязвимые СУБД, интегрированные с Интернет-порталами (XSS, SQL Injection и т.п.).
13. Уязвимость систем, на которых крутятся конфиденциальные данные.
14. Отсутствие мониторинга узлов с важными данными на предмет вторжений и иных действий злоумышленников.
15. Внедрение межсетевых экранов, "непонимающих" прикладные протоколы для СУБД или Web.

Вот такой список. Хотя я бы его, наверное, переименовал все-таки. Это не 15 причин утечек ПДн, а 15 технических ошибок, которые допускаются при внедрении и защите систем управления базами данных. Все-таки организационные, юридические, психологические причины в этом списке отсутствуют. А без них картина будет неполной.

О комплексе неполноценности Microsoft

Прошлая неделя прошла под знаком травли маководов. Эксперты обнаружили ботнет на 500 с лишним тысяч ПК с ОС MacOS. И началось... Особо преуспели фанаты Windows, которые наконец-то смогли оторваться на владельцах якобы невзламываемой ОС. Мне это напоминает известный конфликт виндусятников и линуксоидов, который не продолжается уже десятилетия и с завидным постоянством всплывает на многих ресурсах, конференциях, статьях и т.п. Хотя надо понимать, что сравнивать Windows и Linux, Windows и MacOS - это все равно, что сравнивать Volkswagen и Toyota. За каждым из этих наименований скрываются различные автомобильные бренды (за тем же VW скрываются помимо родного VW еще и Audi, Lamborghini, Bentley и т.д.). А ведь есть еще и водитель, от мастерства которого зависит надежность авто. Ну да я не к тому. Об этом я уже писал достаточно подробно.

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

В чем до недавнего времени было отличие Windows и MacOS? В возможностях по исследованию? Нет. В ресурсах, которые были у исследователей? Нет. В желании ломать? Тоже нет. Разница была только в одном - в популярности. Windows была гораздо популярней, чем все остальные платформы. Не просто вместе взятых, а лидировала с большим отрывом, занимая чуть ли не 95-97% всего рынка настольных ОС. Поэтому и продукцию Apple ломать было неинтересно. Денег на этом было не заработать. Но вот ситуация стала меняться. В 2010-м году по оценкам экспертов продукция Apple впервые перевалила 10% и достигла значения в 12% (см. слайд 13). Вот тут-то и переступил переломный момент. Все эксперты отметили рост числа уязвимостей для платформ MacOS, например, Frost & Sullivan.

И вспомнил я, что читал 4 года назад интересное исследование "Games, Metrics, and Emerging Threats" Адама О'Доннелла, который задался тем же вопросом, задав его в чуть более глобальной форме: "Когда злоумышленник сменит цель X на цель Y?" В качестве примера он как раз взял Windows и MacOS. В 2005-м году для винды существовало 250 тысяч сэмплов вредоносного ПО; в 2006-м - уже 500 тысяч. Для MacOS же их было меньше 100. Адам предложил, что дело не в том, что маководы более интеллигенты, и не в том, что Mac сложнее атаковать. Он высказал гипотезу, что популярность MacOS была настолько мала, что для авторов вредоносного ПО эта платформа была просто неинтересна. Дальше он применил теорию игр, а точнее дилемму заключенного, о которой я уже писал. Вывод О'Доннела оказался прост - чтобы злоумышленники заинтересовались MacOS и стали заниматься монетизацией вредоносного ПО для нее, ее популярность должна превысить некий порог. И этот порог составляет... 12-16%. А как мы видели абзацем ранее, этот Рубикон был перейден в 2010-м году. Поэтому сейчас мы видим такой рост интереса в кредоносному ПО для MacOS.

Кстати, на этом исследование О'Доннела не заканчивается. Он пишет, что специалистам по ИБ надо задуматься и в отношении других технологий, рост популярности которых заставит обратить на них внимание и злоумышленников. На самом деле я упростил пересказ исследования О'Доннела. В его формулах присутствует не только популярность, но и ценность атакуемой технологии, а также эффективность защитных механизмов. На основе этих трех критериев О'Доннел и сравнивает социальные сети, SMS, e-mail, Twitter и т.д.

К чему я это все написал?.. Не для того, чтобы защитить яблочников. И не для того, чтобы наехать на виндусятников. Среди безопасников не должно быть ни тех, ни других. Есть объект защиты, который надо защищать. Все. А какой это объект не так уж и важно. Взломать можно любой. Это только вопрос времени, желания, ресурсов и... популярности. Помните это!

Новая версия курса по персданным

Новое в версии 4.5:

• Почему госорганы не включают в план проверок
• Передача ПДн в рамках цессии по мнению РКН
• Количество согласий субъектов
• Про подготовку списка/описания процессов
• Новая версия «письма шести»
• Обновление раздела по лицензировании ТЗКИ и СКЗИ
• Взгляд юристов на новое ПП-79
• Новости ФСТЭК в части изменения нормативной базы
• Роль МВД при проверках по персданным
• Мнение РКН по обезличиванию
• Грубые нарушения регуляторов при проверках
• Типовые ошибки РКН при проведении проверок
• Изменения ст.5 ФЗ «О техническом регулировании»
• О квалификации сотрудников отделов по защите информации

Кодекс деловой этики оператора связи

В США каждый десятый компьютер входит в состав ботнета. В России такая же статистика по данным МВД. Это проблема и проблема серьезная. Если с ней не бороться на всех уровнях - пользователи, корпорации, операторы связи, государство, правоохранительные органы, то будет еще хуже. Хороший пример подали в США, где Online Trust Alliance (OTA) вместес Федеральной комиссией по связи предложили операторам связи (по желанию) принять, утвержденный пару недель назад кодекс деловой этики в области борьбы с ботнетаии (U.S. Anti-Bot Code of Conduct for Internet Service Providers (ISPs), также известный как ABCs for ISPs).

Кодекс концентрируется на 5 аспектах, по которым принявшие его операторы связи должны что-то делать:

• Обучение. Активности, связанные с обучением абонентов, повышением их осведомленности, подсказках и т.п.
• Обнаружение. Активности, связанные с идентификацией ботнетов и отдельных ботов в своих сетях, а также в сетях абонентов.
• Уведомление. Активности, связанные с уведомлением абонентов о том, что они стали жертвой ботнетов.
• Лечение. Активности, связанные с подсказками зараженным абонентам, что им делать дальше, а также помощь в лечении.
• Взаимодействие. Активности, связанные с обменом с другими операторами связи сведений о ботнетах.

Надо заметить, что эти 5 аспектов очень похожи на шаги в управлении инцидентами.

Помимо Кодекса на сайте OTA даны очень полезные ссылки на различные ресурсы, помогающие бороться с ботнетами. Там и Microsoft, и Secunia, и PayPal, и Министерство национальной безопасности США, и IETF, и MAAWG, и еще порядка двух десятков сугубо практических, а не теоретизирующих ресурсов и бесплатных инструментов.

Собственно нашим операторам связи и Интернет-провайдерам стоит если не разработать такой же Кодекс (нечто аналогичное у нас есть по борьбе с нелегальным контентном и детской порнографией), то повесить у себя на сайте все эти ссылки, а также вывесить простые инструкции для пользователей, как, например, это сделано на http://www.staysafeonline.org/.

Ответ на загадку

Увы, так никто правильного ответа и не дал. Правильный ответ - Федеральная служба безопасности при Президенте Российской Федерации ;-)

Почему в актах указаны именно такие моменты, не всегда присущие полномочиям ФСБ в части проверок по теме ПДн? Ответ был буквально следующий: "для ФСБ такого рода проверки в новинку, поэтому то что знали то и проверяли" ;-)

Загадка по ПДн: угадайте, кто это?

Отсутствие "единства измерений" при проверках по теме ПДн давно стала притчей воязыцех. Если посмотреть акты проверок, судебные решения, ответы регуляторов, то складывается впечатление, что каждый регулятор "кто во что горазд". И это несмотря на то, что по идее их полномочия достаточно четко определяет и ФЗ-152 и ФЗ-294. Но не тут-то было. Т.к. через меня проходит энное количество различных актов проверок, то выбрал я несколько и решил загадать читателям блога загадку. Угадайте, кто из регуляторов мог составить такие фрагменты из актов проверок?

Итак фрагменты следующие:

1.  "В нарушение п.6.1.7 РС БР ИББС 2.3-2010 не предоставлены инструкции (руководства) на кажду. ИСПДн, которые готовятся разработчиком ИСПДн в составе эксплуатационной документации на ИСПДн и определяют порядок действий администратора информационной безопасности ИСПДн и персонала, занятого в процессе обработки персональных данных".
2. "Расположение и площадь помещений, в которых установлены СКЗИ соответствуют требованиям ФЗ "О санитарно-эпидемиологическом благополучии населения" от 1999 года и "Положения о государственном санитарно-эпидемиологическом нормировании".
3. "В нарушение п.5 Постановления Правительства РФ №512 "Об утверждении требований к материальным носителям биометрических персональных данных и технологиям хранения таких данных вне информационных систем персональных данных" от 06.07.2008 в ОАО КБ "название банка" не утвержден порядок передачи материальных носителей биометрических персональных данных уполномоченным лицам".
4. "Техническая укрепленность помещений, в которых установлены СКЗИ, соответствует требованиям МВД № 78.36.003-2002".
5. "Система защиты конфиденциальной информации проводится в соответствии с "СТР-К", утвержденных 30.08.2002".
6. "ООО КБ "название банка" при проведении самооценки не учтены требования п.6.13 СТО БР ИББС 1.2-2010, предусматривающего определенные значения группового показателя М9 по наименьшему значению оценок входящих в него частных показателей".

Сразу скажу, что ответ неочевиден. И напомню, что регуляторов у нас по теме персданных пять ;-) Это РКН, ФСТЭК, ФСБ, МВД и ЦБ.

ЗЫ. Ответ будет дан вечером в 17.55 по московскому времени ;-)